Chrome shows "This site can't be reached" with the code DNS_PROBE_FINISHED_NXDOMAIN when a DNS lookup comes back saying the name doesn't exist. NXDOMAIN is the actual DNS response code for "no such domain", so the browser isn't guessing. The only question is whether that answer is true everywhere or just on your machine, and a two-minute check tells you which.
Before touching any settings, look the domain up from somewhere other than your own computer. Our DNS lookup tool queries from our servers, so it's unaffected by your cache, your router or your ISP.
From a terminal you can compare your normal resolver with a public one:
nslookup example.com
nslookup example.com 1.1.1.1Or with dig, where the header line tells you the result directly:
dig example.com
dig @8.8.8.8 example.comLook for status: NXDOMAIN versus status: NOERROR. If your default resolver says NXDOMAIN and 8.8.8.8 says NOERROR with an answer, you've located the problem without guessing.
Also check the spelling, character by character. A typo is the single most common cause of a correct NXDOMAIN, and exmaple.com looks fine at a glance.
Work through these roughly in order. Test after each one so you know which fixed it.
Clear Chrome's own cache. Chrome keeps a host cache separate from the operating system. Go to chrome://net-internals/#dns and click "Clear host cache". Then reload the page.
Flush the operating system's DNS cache. A stale negative answer can sit there after the domain starts working:
# Windows (Command Prompt as administrator)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux with systemd-resolved
resolvectl flush-cachesCheck the hosts file. It overrides DNS entirely, and old entries from development work or "ad-blocking" hosts lists can break a domain. On Windows it's C:\Windows\System32\drivers\etc\hosts, and on macOS and Linux it's /etc/hosts. Remove or comment out any line mentioning the domain.
Turn off the VPN, proxy or filtering software. Corporate VPNs often use their own DNS, which may not know about public domains, or may deliberately return NXDOMAIN for blocked ones. The same goes for DNS-based ad blockers (Pi-hole and similar) and some antivirus "web protection" features. Disable them briefly to test.
Check Chrome's secure DNS setting. At chrome://settings/security, "Use secure DNS" can send lookups to a different provider than the rest of your system. If only Chrome fails, try switching that setting between your current provider and a named one like Cloudflare or Google, and see if the result changes.
Try a different resolver. If your ISP's resolver is the one returning NXDOMAIN, switching to a public resolver usually fixes it. We have a separate guide on changing your DNS server, including what you give up by doing so.
Reset the network stack on Windows. If lookups fail for many sites, not just one, this clears out a lot of accumulated breakage. Run as administrator and restart afterwards:
ipconfig /release
ipconfig /renew
netsh winsock resetWhen the domain fails from everywhere, the answer is coming from its authoritative name servers, or the domain has vanished from the registry. Check these in order.
Has the domain expired? Look it up with our WHOIS tool and check the expiry date and the status codes. Registries use clientHold and serverHold to pull a domain out of DNS, and ICANN's own description of both is that the domain is not activated in the DNS. Unpaid renewals, failed verification of the registrant's email address, and abuse complaints can all trigger a hold. Renewing or completing verification usually restores it, though it can take a few hours to reappear.
Are the name servers right? Run:
dig NS example.comIf the domain was recently moved between DNS providers, the registrar might still point at the old provider, where the zone has been deleted. The old provider then answers NXDOMAIN for everything. Update the name servers at the registrar so they match the provider holding your records.
Does the specific record exist? A very common one: example.com works but www.example.com doesn't, because nobody created a record for www. NXDOMAIN applies to the exact name queried. Add an A record or a CNAME for the missing name. Check subdomains like shop. or app. the same way.
Are the name servers disagreeing? If one authoritative server has the record and another doesn't, some visitors get an answer and others get NXDOMAIN. Query each name server directly:
dig @ns1.example.net www.example.com
dig @ns2.example.net www.example.comEvery listed name server should give the same answer.
NXDOMAIN answers are cached, just like successful ones. Under RFC 2308 the negative answer is cached for the smaller of two values in your zone's SOA record: the SOA record's own TTL and its "minimum" field. If that's set to an hour, a resolver that saw NXDOMAIN just before your fix can keep repeating it for up to an hour.
So the order matters. If you look up a new subdomain before creating it, you've just taught your resolver it doesn't exist. Create the record first, then test. And test with a resolver that hasn't cached the failure, or with our DNS propagation checker, which queries several public resolvers at once so you can see which ones have caught up.
Chrome has several DNS_PROBE_ codes, and they aren't interchangeable. NXDOMAIN specifically means a resolver answered and said the name doesn't exist. A resolver that can't be reached at all, or one that fails validation (a broken DNSSEC setup returns SERVFAIL rather than NXDOMAIN, for example), is a different problem with different fixes. If dig shows status: SERVFAIL, stop looking for missing records and look at DNSSEC and the name servers themselves.
They're using different resolvers or caches. Your phone might be on mobile data while the laptop uses the office network, or the laptop has a stale cache or hosts file entry. Flush the laptop's DNS cache and check for a VPN before anything else.
Not directly. Once the record exists, cached negative answers expire on their own, within the negative caching time set in the SOA record. Keeping that value modest, an hour or so, limits how long mistakes linger.
Sometimes. Some filtering resolvers, school and workplace networks among them, return NXDOMAIN for blocked domains instead of a block page. If the domain resolves through a public resolver but not on that network, filtering is the likely reason.
Usually not. Browser history and cookies are separate from the DNS cache. Use the host cache page in Chrome and flush the system cache instead.
0 comments
No comments yet. Be the first.