What It Means and How to Diagnose It
Every request starts with a DNS lookup. Chrome hands the hostname to a resolver, gets back an A or AAAA record, then opens a connection to that address. If the lookup returns nothing usable, there is no address to connect to and Chrome stops.
The keyword here is name. This fails before any connection exists, which is why there is no "Proceed anyway" link and why site downtime is not the explanation. A server that is down still resolves. You will also see the sibling error DNS_PROBE_FINISHED_NXDOMAIN, which is the same failure with a confirmed "this domain does not exist" answer.
Two commands tell you which half of this guide you need. First, query the domain against a public resolver, bypassing whatever your system normally uses:
dig @1.1.1.1 example.com +short
# or
nslookup example.com 1.1.1.1An IP means the domain is fine and the problem is yours. NXDOMAIN means the domain does not exist in DNS, either never configured, lapsed, or deleted. SERVFAIL points at DNSSEC or a broken authoritative nameserver.
Then run nslookup example.com with no resolver specified. If the public one answers and your default does not, your DNS is the fault. That comparison saves you from ten fixes that were never going to help.
Fixes on Your Own Device
Flush the DNS cache
Your OS and Chrome both cache lookups, including failures. A domain that recently changed IPs stays broken until the cache clears.
Run ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, or sudo resolvectl flush-caches on Linux. Then open chrome://net-internals/#dns and click Clear host cache, since Chrome keeps its own resolver cache separate from the system.
Change your DNS resolver
Routers hand out the ISP's resolver by default, and those go stale, get overloaded, or filter domains without telling you.
Set your adapter's DNS to 1.1.1.1 and 1.0.0.1, or 8.8.8.8 and 8.8.4.4. Google's setup guide covers every OS and router if you need the exact steps. Do it on the device rather than the router, so you can tell whether the router was the problem.
Check secure DNS in Chrome
Chrome ships with DNS over HTTPS enabled where the resolver supports it. That means Chrome can be resolving through a different server than the rest of your system, which is why a domain sometimes works in ping and fails in the browser.
Open chrome://settings/security, find "Use secure DNS", and toggle it off to test. If the site loads, that DoH provider was the one failing. Point it at Cloudflare instead of leaving secure DNS off for good.
Look for a sinkhole before you blame the network
Pi-hole, AdGuard Home, NextDNS, and browser-level blocking all work by answering DNS queries with nothing on purpose. A sinkholed domain produces exactly this error.
The tell is that it hits one domain, usually carrying ads or telemetry, while everything else is fine. Check the query log on whatever is doing the filtering first.
Clear stale hosts file entries
The hosts file overrides DNS entirely, so a line left over from local development points a real domain at an address that no longer answers. Remove the entry from C:\Windows\System32\drivers\etc\hosts or /etc/hosts, then flush the cache.
Rule out preloading, VPNs, and extensions
Chrome prefetches DNS for links it expects you to click, and on flaky connections those failures get cached and served back to you. Switch off "Preload pages" under chrome://settings/performance.
Security software with DNS filtering, VPN clients that push their own resolver, and privacy extensions all intercept lookups. Test in incognito with extensions disabled and any VPN disconnected.
Also Read: How to Use a Proxy With Docker
Fixing It on Android, iPhone, and Routers
On Android, the setting people miss is Private DNS. Under Settings, Network & internet, Private DNS, it is often pointed at a hostname that stops resolving on mobile data or restricted Wi-Fi. Set it to Off or Automatic, then clear Chrome's storage and update Android System WebView from the Play Store.
On iPhone and iPad, check Settings, General, VPN & Device Management for a configuration profile you no longer need, since profiles can install a DNS proxy that handles every lookup silently. Then set DNS manually to 1.1.1.1 under your Wi-Fi network's Configure DNS. Toggling airplane mode clears the system resolver cache.
On the router, a reboot fixes more of these than it should, because consumer routers run a small DNS forwarder that leaks memory and starts dropping queries. If the error hits every device at once, restart it, then set the WAN DNS servers manually instead of taking what the ISP hands over.
Fixing It as the Site Owner
If a public resolver returned NXDOMAIN, the problem is yours. These are the causes in rough order of frequency.
Missing A or AAAA record. The zone exists but the hostname has no address record, usually after a migration or a typo. Confirm with dig example.com A +short.
Domain expired or on hold. Registrars pull nameservers the moment a domain lapses. Run whois example.com and look for clientHold or a past expiry date.
Nameservers not updated. The registrar still points at the old provider while the records live elsewhere. dig example.com NS tells you who is actually authoritative.
DNSSEC failure. A mismatched DS record makes validating resolvers refuse the answer, which is why the site loads for some visitors and not others. Test with dig example.com +dnssec and remove the DS record if the zone is no longer signed.
Propagation. New records inherit the TTL of the old entry, so a 24 hour TTL means up to 24 hours of mixed results.
Subdomain gaps. example.com resolving does not mean www.example.com does. Each hostname needs its own record or a wildcard covering it.
When the Error Only Appears Through a Proxy
If the site loads directly and breaks the moment your proxy is on, the cause is usually where the hostname gets resolved, not the proxy itself.
With an HTTP proxy, the client sends the hostname in a CONNECT request and the proxy resolves it. With SOCKS5 the scheme decides. socks5:// resolves locally and sends the proxy an IP. socks5h:// sends the hostname and lets the proxy resolve it. If your local DNS cannot resolve the target, the first form fails with a name resolution error while the second works.
import requests
proxies = {
"http": "socks5h://user:pass@proxy.host:1080",
"https": "socks5h://user:pass@proxy.host:1080",
}
r = requests.get("https://example.com", proxies=proxies, timeout=10)That h is the whole fix in most scraping setups. It matters for anonymity too, since resolving locally leaks every domain you visit to your own resolver even though the traffic goes through the proxy.
Two other cases produce the same error. Inside Docker or WSL, the container's resolver is not your host's, so a name that works on the host fails until you set --dns or fix /etc/resolv.conf. And free proxy lists routinely run dead or hijacked resolvers, which is why the same scraper works on one IP and fails on the next with no pattern.
curl -v -x socks5h://user:pass@proxy.host:1080 https://example.comProxyon resolves hostnames at the exit node, so targets that are geo-restricted or unresolvable from your network still work. Residential proxies start at $2.25/GB and datacenter proxies at $1.50/IP on pay-as-you-go pricing.
Also Read: UDP Proxy Explained
FAQ Section
What does ERR_NAME_NOT_RESOLVED mean?
DNS could not turn the domain name into an IP address. The browser never reached the server, so it is a lookup failure, not a connection or certificate problem.
What is the difference between ERR_NAME_NOT_RESOLVED and DNS_PROBE_FINISHED_NXDOMAIN?
Same class of failure. NXDOMAIN means a resolver explicitly confirmed the domain does not exist, while ERR_NAME_NOT_RESOLVED also covers timeouts and empty answers.
Why do I get it on only one website?
That points at the domain or at something filtering it. Query it against 1.1.1.1. If that works, check for a Pi-hole, a hosts file entry, or a DNS-filtering extension.
Why do I get it on every website?
That points at your resolver or your network. Flush the DNS cache, switch to a public resolver, restart the router.
Can a VPN or proxy cause it?
Yes. VPNs push their own resolver, and SOCKS5 proxies fail this way when the hostname is resolved locally. Use socks5h:// rather than socks5://.
Does ERR_NAME_NOT_RESOLVED affect SEO?
On your own site, yes. Googlebot cannot resolve the domain either, so crawling stops and pages drop out of the index.
How long does DNS propagation take?
Up to the TTL of the previous record, commonly a few hours and as much as 48. Lower the TTL before a planned change, not after.
Final Thoughts
Diagnose before you fix. One
nslookup example.com 1.1.1.1tells you whether you are chasing your own cache or a broken zone, and that answer decides which half of this guide applies. Most client-side cases come down to a stale cache, a bad resolver, or something quietly sinkholing the domain. If it only breaks with your proxy on, check the scheme, becausesocks5://resolves on your machine andsocks5h://resolves at the exit.
