ERR_NAME_NOT_RESOLVED: What It Means and How to Fix It

ERR_NAME_NOT_RESOLVED is Chromium's name for a failure that happened before any connection existed. In Chromium's network error list it is error -105, the host name could not be resolved. Your browser asked the system to turn a hostname into an IP address, and the answer came back with no address in it. So there was nothing to connect to: it never opened a socket, never sent a packet toward the site, and never learned whether that site is up, down, or refusing you. The error describes a lookup, not a website.

That one fact reorders every fix list you will read elsewhere. Reloading retries nothing at the site, because nothing reached it. Checking whether the site is down answers a question the error never asked. The lab behind this guide records it exactly: a request to a name guaranteed never to resolve failed with ENOTFOUND underneath, and no connection was attempted.

Chrome sometimes shows DNS_PROBE_FINISHED_NXDOMAIN instead, the narrower case. NXDOMAIN, the Name Error response code described in RFC 9499, is an authoritative statement that the name does not exist. ERR_NAME_NOT_RESOLVED is the wider bucket, covering a resolver that failed, refused, or never answered; Chromium files that case separately as ERR_NAME_RESOLUTION_FAILED, error -137.

One line of on-screen text is worth naming, because people search for it. Under the code, Chrome prints suggestions that begin with checking the connection and checking the proxy, firewall, and DNS configuration. That is generic text attached to a family of network errors, not tests Chrome ran. If other sites load, your connection is fine.

Two questions separate every cause: does the name have an address, and can you reach the host without using a name. Substitute your own hostname.

# 1. Ask the resolver this machine is actually using.
nslookup shop.example.com

# 2. Ask a second resolver: does the name exist anywhere?
nslookup shop.example.com 1.1.1.1

# On macOS or Linux, ask for each address family separately.
dig +short shop.example.com A
dig +short shop.example.com AAAA

# 3. Skip DNS: pin an address step 2 returned, then connect.
curl -sSI --resolve shop.example.com:443:203.0.113.10 https://shop.example.com/

Step three is the one nobody else tells you to run, and --resolve is the right form of it: you supply the address while the request still carries the real hostname, so virtual hosting and TLS behave normally.

The lab for this guide records that split as four checks on Node v24.14.0, built around a name in the .invalid top-level domain that RFC 2606 reserves so it can never exist:

PASS  reserved .invalid name -> ENOTFOUND (no address, ever)  (outcome=ENOTFOUND)
PASS  fetch to the unresolvable name -> ENOTFOUND underneath (no connect attempted)  (cause=ENOTFOUND)
PASS  localhost resolves (contrast: resolution succeeds)  (address=::1)
PASS  IP literal connects with no DNS involved (the DNS-vs-connectivity test)  (outcome=response)

checks passed: 4/4

Read those four lines as your template. The name had no address, a fact about DNS and not about any server, and the client never attempted a connection, exactly as your browser did not. A name that does exist resolved in the same run, and an address with no name still reached a live service: that pair is the DNS-versus-connectivity test.

One caveat: nslookup and dig ask your machine's resolver. Software configured to use a proxy may hand the hostname to the proxy instead, so a name can fail in one application and resolve fine in your shell. The proxy server guide traces which side resolves what.

Ranked honestly, the most frequent cause is the least technical: the name does not exist. A typo is invisible to you and total to a resolver, which does no spell checking and no guessing. A lapsed domain stops resolving the day its records are withdrawn. A staging host or a retired API name disappears the moment its record is deleted, while the parent domain keeps working and makes the failure look like a partial outage.

The lab's first check is that case in pure form. A name in the reserved .invalid top-level domain can never exist, and the lookup returned ENOTFOUND. Say the consequence plainly, because most pages about this error imply the opposite: no browser setting, cache flush, resolver change, router reboot, or reinstall invents an address for a name that has none. If the second resolver also comes back empty and the name fails from a phone on mobile data, this is your case, and the fix is the correct spelling or it belongs to whoever owns the domain.

One variant catches experienced people: internal hostnames resolve only on the network or VPN that carries their private zone, so away from it the name genuinely has no public address and the error is correct rather than broken. Container and service-discovery names behave the same way.

Chrome does not ask the operating system every time. It keeps its own in-process host cache and can perform its own encrypted lookups, so Chrome and the rest of your machine can hold different answers for the same name at once. That is the whole explanation for the most reported symptom here: the site loads in Firefox, the name resolves at the command line, and Chrome alone refuses.

So clear both caches, not one. The system resolver cache goes first:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches

None of those touch Chrome's copy. For that, open chrome://net-internals/#dns and clear the host cache, then chrome://net-internals/#sockets and flush the socket pools, because a pooled connection can outlive a cleared cache. Clearing one side and not the other is why a name keeps failing after a flush that looked successful.

Secure DNS is the second Chrome-only cause and now the more common one. The setting at chrome://settings/security can send lookups to a DNS-over-HTTPS provider of Chrome's own instead of the resolver your network handed out. One unreachable from the network you just joined, or one that knows nothing about your employer's internal names, breaks Chrome and nothing else. Set it to your system resolver and Chrome asks what the rest of the machine asks.

Third, extensions holding proxy or network permissions, VPN add-ons especially, can route Chrome's lookups down a path of their own. Open a guest window, which runs with no extensions: if the site loads there, the fault is that profile, not DNS.

If the name resolves somewhere but not for you, the fault is in the resolver path, in rough order of likelihood.

First, your ISP's resolver having a bad moment. Partial failures are ordinary, often hit only a subset of names, and usually clear within hours. The tell is step two: empty from your resolver, fine on a second one. Restarting the home router helps here for a real reason: it is the DNS forwarder your devices were handed, and its cache is what went bad.

Second, a resolver that answers this way deliberately. Filtering resolvers run by an ISP, a security suite, or your own network-wide blocker return NXDOMAIN or a sinkhole address for listed names. Your hosts file does the same one step earlier, since it is read before DNS: a stale line pointing a name at 0.0.0.0 breaks a site on one machine only.

Third, a VPN or corporate client that replaced your resolver. A tunnel pushes its own DNS servers so internal names resolve while it is connected, and split-tunnel or DNS-scope settings can just as easily send public names to a resolver that will not answer them. Disconnect and retest. If it fails only with the tunnel up, that setting belongs to the client, or to whoever administers a managed device. The proxy and VPN comparison covers why the two relocate resolution differently.

Fourth, a proxy set to the wrong resolution mode. Your client either resolves the hostname itself or passes it along for the proxy to resolve, which in a curl proxy URL is socks5 against socks5h. Resolving locally for a name only the proxy's network can see fails the lookup for a reachable host. The HTTP and SOCKS5 comparison explains which mode resolves where.

Fifth, filtering on a network you do not run. Schools, workplaces, hotels, and guest Wi-Fi commonly express their acceptable-use policy in the resolver, and many block queries to other resolvers as well, so even the second-resolver test times out. That combination is itself the diagnosis: the operator is withholding the name on purpose, and the browser is reporting a configured answer correctly. Treat it the way you would treat a 403. It is a decision, not a fault, and the next step is the administrator who set it. This guide does not cover changing resolvers to get a different answer on a network someone else administers.

Every network hands a phone its own resolver, which is why this error is usually network-specific there: it fails on one Wi-Fi and works on the next. When it follows the network rather than the device, you have localized it.

When it follows the device, one Android setting causes most reports. Private DNS, under Network and internet, points the whole phone at a DNS-over-TLS provider by hostname, so when the Wi-Fi you just joined cannot reach that provider, every lookup fails at once while the phone still looks connected. It survives reboots and reinstalls, which is why the error looks permanent; set it back to automatic on a phone you own and retest. On iPhone, look at the per-network Configure DNS screen, any profile installed by an employer or school, and iCloud Private Relay.

The dual-stack case is the one almost nobody names. The lab's third check resolved localhost to ::1, the IPv6 loopback, on a machine that also has 127.0.0.1: a name resolves to whichever address family is on offer, and IPv4 is not a default. Mobile networks increasingly run IPv6-only paths that depend on DNS64, specified in RFC 6147: the network's own resolver synthesizes an IPv6 answer for a destination that publishes only an A record. Replace that resolver with a public one through Private DNS and the synthesis stops, so IPv4-only sites resolve to nothing usable on cellular while working normally over Wi-Fi. The same shape appears from the other end when nameservers answer A queries but fail on AAAA: IPv6-only clients get no address while dual-stack clients never notice. The IP diagnostic shows which family your network used.

If the failing name is one you publish, resolvers got no usable answer, and there are only a few ways to produce that. Test from outside your network, because your caches are not what visitors have.

The first is a missing record. A hostname needs an A record, an AAAA record, or a CNAME, and without one your DNS provider correctly answers that there is nothing there, the “no A, AAAA or CNAME record found” message that fills support forums. Check the apex and the www host separately, and check any subdomain that shows in a hosting or CDN panel but was never written into the served zone.

The second is delegation, and it explains most reports of adding a record hours ago with nothing changing. Your registrar publishes a set of nameservers for the domain, and only the zone on those nameservers is ever queried. Records added in a panel whose nameservers are not the ones the registrar lists are real, correct, and consulted by nobody. dig +trace example.com walks the delegation down from the root and shows where queries land.

The third is negative caching, where the usual intuition is backwards. Nothing propagates. Resolvers cache, and they cache absence too: when a name does not exist, RFC 2308 has the authoritative server return the zone's SOA record so resolvers know how long to remember that, with the lifetime drawn from the SOA minimum field. A generous minimum keeps other people's resolvers calling your new hostname nonexistent for hours after you created it, and nothing makes them forget early. Lower it, and the record TTLs, a day before a launch.

One cause hides from every propagation checker: a DNSSEC mismatch, typically a DS record left at the registrar after moving providers, makes validating resolvers refuse to return an answer at all, so the name works on some resolvers and fails on others.