ERR_NAME_NOT_RESOLVED means the DNS lookup failed to produce an address: the browser asked for the site's IP and the resolution process broke down before delivering one. Chrome shows it alongside the phrase "this site can't be reached, the server's DNS address could not be found," and the operative word is found, not refused.
This error is the sibling of DNS_PROBE_FINISHED_NXDOMAIN, and telling them apart is genuinely useful. NXDOMAIN is a completed lookup that returned a confident negative: the authoritative servers answered that the name does not exist. NAME_NOT_RESOLVED is a lookup that did not complete properly: the resolver could not be reached, returned an error, or the whole resolution path failed in a way that produced no usable answer. One is a clear no; the other is a shrug. This article covers what breaks a lookup, the device and network fixes in order, and the shorter server-side list for domain owners, with the full NXDOMAIN treatment living in its own guide at how to fix DNS_PROBE_FINISHED_NXDOMAIN.
What breaks a lookup
A DNS lookup has more moving parts than its reputation suggests. The device sends the question to a configured resolver, the resolver chases the answer through the DNS hierarchy, and the answer travels back. NAME_NOT_RESOLVED appears when any link in that chain fails to hold: the device cannot reach its resolver because the network is half-connected, the resolver itself is down or overloaded, an encrypted DNS setting points at a provider that is not answering, a router is handing out a dead DNS server address, or a captive portal is intercepting lookups until you sign in on its page.
Modern browsers added one more link to the chain. Chrome's Secure DNS, which encrypts lookups with DNS-over-HTTPS, replaces the operating system's resolver with a provider of its own, and when that provider is unreachable, sites fail to resolve even though the rest of the machine's networking is fine. It is the first thing to test on a device where this error appeared suddenly and everywhere.
Fixes on the device and network
Toggle Chrome's Secure DNS. In Chrome's Privacy and Security settings, turn Secure DNS off and reload the page. If the site resolves, the DoH provider was the broken link; either leave the feature off or point it at a provider that answers, such as Cloudflare or Google.
Confirm you are actually online. Wi-Fi bars are not connectivity. Hotel and airport networks intercept DNS until the captive portal is satisfied, so open a plain HTTP page or the portal's login address first; every lookup fails until the portal lets you through.
Flush the caches. Run ipconfig /flushdns on Windows, the dscacheutil and mDNSResponder pair on macOS, or resolvectl flush-caches on Linux, and clear Chrome's host cache at chrome://net-internals/#dns. Failed lookups get cached like successful ones, and a cached failure keeps hurting after its cause is gone.
Set a known-good resolver. Change the connection's DNS to 1.1.1.1 or 8.8.8.8 directly on the device. If resolution returns instantly, the previous resolver, usually the ISP's or the router's, was the failure, and you can keep the replacement permanently.
Restart the router and check its DNS settings. Routers commonly proxy DNS for the whole network, so a wedged router breaks resolution for every device at once. Power cycle it, and if the error returns, log into it and replace whatever DNS servers it distributes with public ones.
Disable the VPN and check parental controls. VPNs carry their own resolvers, and filtering software blocks lookups by design. Turn each off briefly to test; on Android specifically, review the Private DNS setting, which is the system-wide cousin of Chrome's Secure DNS and fails the same way.
When it is your domain
If your own site throws this error for visitors while others load fine for them, investigate the nameserver layer rather than individual records. Nameservers that are unreachable, misconfigured, or timing out produce failed lookups rather than clean negative answers, so start with dig +trace on the domain and watch where the walk stalls. Confirm the registrar lists the correct nameserver hostnames with no typos, confirm those servers actually answer queries from the outside world, and check DNSSEC, because a broken signature chain makes validating resolvers discard your answers, which reaches users as resolution failure. If you recently changed DNS providers, remember the old nameservers keep receiving queries until the delegation change ages out of caches, and if the old provider has already deleted your zone, the visitors still routed there get failures while everyone else is fine, a split-brain period that external, multi-location checking is built to reveal.
Common mistakes in fixing ERR_NAME_NOT_RESOLVED
Treating it as identical to NXDOMAIN. The fixes overlap, but the meaning differs: NXDOMAIN blames the name, NAME_NOT_RESOLVED blames the lookup. Diagnosing the wrong one wastes the first half hour.
Skipping the captive portal check. On travel Wi-Fi this error is the portal, ninety times out of a hundred. Open the login page before touching a single setting.
Changing the resolver on one device and concluding network-wide. If the router distributes a broken DNS server, every other device stays broken. Fix the router's setting, not just the laptop's.
Forgetting the browser has its own DNS path. Secure DNS means Chrome can fail while the terminal resolves happily. When command-line lookups work and the browser does not, the browser's DoH setting is the suspect.
Testing your domain only from your own resolver. Your resolver's cache can carry you for hours after your nameservers break. Query several public resolvers, or check from multiple regions, before trusting that all is well.
FAQ
What is the difference between ERR_NAME_NOT_RESOLVED and DNS_PROBE_FINISHED_NXDOMAIN?
NXDOMAIN is a completed lookup whose answer was that the domain does not exist. NAME_NOT_RESOLVED is a lookup that failed to complete, no usable answer at all. The first points at the domain's records; the second points at the resolution path, the resolver, the router, the VPN, or encrypted DNS settings.
Why does this error appear on Android specifically?
Android's Private DNS feature routes lookups through an encrypted provider, and when that provider is unreachable, all resolution fails. Set Private DNS to automatic or off, retest, then try switching Wi-Fi to mobile data to isolate the network.
Why do all websites fail at once with this error?
Because the broken component sits in the shared path: your resolver, your router's DNS, a VPN, or a captive portal. Per-site failures point at that site's DNS; everything failing points at yours.
Can the website owner cause ERR_NAME_NOT_RESOLVED?
Yes, through unreachable or misconfigured nameservers, broken DNSSEC, or a botched provider migration. If multiple people on different networks see it for one domain, the domain's DNS layer is the place to look.
Closing thought
ERR_NAME_NOT_RESOLVED is the lookup itself failing, so the repair is a walk along the resolution path: browser's own DNS setting, captive portal, caches, resolver, router, VPN, in that order, with each step testable in under a minute. Owners walk the mirror-image path, from registrar delegation to nameserver health to DNSSEC, ideally viewed from outside their own caches.
DNS failures are uniquely deceptive for site owners because the people closest to the site are the last to see them. Odown resolves and connects to your site from 17 locations worldwide on every check, so a nameserver that stops answering, or a migration that breaks resolution for half the planet, becomes an alert in minutes instead of a mystery assembled from customer complaints. The companion deep-dive on running lookups by hand lives at DNS lookup.
