DNS_PROBE_FINISHED_NXDOMAIN is Chrome's wrapper around a single DNS-protocol verdict: the resolver you asked got back the answer "no such domain." NXDOMAIN literally means "non-existent domain." But the verdict is sent by a DNS server, and DNS servers can be wrong — about half the time you see this error, the domain absolutely does exist; something between you and the authoritative answer is broken.
What the error actually says ¶
When Chrome loads example.com, it asks your operating system to resolve the hostname to an IP. The OS asks a DNS resolver — your ISP's by default, or whatever you've configured. The resolver walks the DNS hierarchy (root → TLD → authoritative) and returns one of three classes of answer:
- NOERROR with answer: resolved, here's the IP. Page loads.
- NOERROR without answer (NODATA): the domain exists but doesn't have the kind of record asked for. Different error in Chrome.
- NXDOMAIN: authoritative answer says this name doesn't exist. Chrome stamps this verdict
DNS_PROBE_FINISHED_NXDOMAIN.
Other browsers express the same verdict differently. Firefox calls it "We can't connect to the server." Safari says "Safari Can't Find the Server." Edge inherits Chrome's text since they share the rendering engine. The underlying DNS verdict is identical.
Why this shows up for sites that obviously exist ¶
If you got NXDOMAIN for thisdomain-i-just-typed-randomly.com, you'd expect it. The interesting cases are when the domain you're trying to load is one you've used before, or that everyone else can reach. Six common reasons it happens anyway:
1. You mis-typed the URL
Less of a "real cause" than a worth-checking-first item. gooogle.com NXDOMAINs because nobody owns that exact spelling. Look at the URL bar carefully, particularly for transposed letters and punctuation. com vs co vs net matters.
2. Your DNS resolver has a stale negative cache
If you queried a domain shortly after it was registered (or a CNAME was recently added), your resolver may have cached the previous "doesn't exist" answer and is still serving it from cache. Negative-caching TTLs are typically much shorter than positive ones (5-15 minutes on most resolvers), so this self-corrects within minutes — but is usually faster to flush manually. Flush DNS commands for every OS.
3. Your ISP's resolver is blocking the domain
ISPs in some countries return NXDOMAIN for domains under court order, regulatory direction, or self-imposed safety lists. UK ISPs return NXDOMAIN for sites on the IWF blocklist; many EU ISPs return NXDOMAIN for sites flagged for piracy under court orders. The domain is fine; the resolver is lying. Switching your resolver to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) bypasses this block and is the standard workaround. (For court-ordered blocks where this matters legally, consult local guidance.)
4. The domain genuinely expired or was deleted
Domain registrations are annual; if a registrant doesn't renew, the registrar pulls the records and the domain goes through a redemption-grace-period (RGP) before becoming available again. During that window, NXDOMAIN is the honest answer — the domain has been removed from the zone. whois example.com shows the registration status; Status: pendingDelete or Status: redemptionPeriod means this is what's happening.
5. Your machine has a hosts-file override
Your operating system checks /etc/hosts (or C:\Windows\System32\drivers\etc\hosts on Windows) before doing a DNS lookup. If a piece of software added an entry mapping the domain to 0.0.0.0 or to a non-existent address, you'll see what looks like a DNS problem but is really a local override. Pi-hole, ad-blocking software, parental-control tools, or stale developer config from years ago are common sources.
6. The authoritative nameservers are misconfigured
If a domain owner sets up DNS poorly — for example, listing nameservers that don't have the domain's records — the resolver gets back NXDOMAIN from those nameservers and surfaces the error to you. This is on the site owner, not you, but the error you see is the same one you'd see for a typo. Less common at well-run sites, common right after a botched DNS migration.
The 60-second diagnostic ¶
Walk through the cheap checks in order; the answer reveals which of the six cases above is in play.
- Re-type the URL by hand. Skips clipboard / autocomplete bugs and weeds out simple typos.
- Try it from another network. Mobile hotspot from your phone is the fastest way to test "is this resolver the problem?" If the site loads on cellular and not on Wi-Fi, your home / corporate / ISP resolver is the culprit. Move on to step 4.
- Check from a different machine on the same network. If only your machine is affected, the issue is local — flush DNS, check hosts file. If every machine on the network is affected, the issue is upstream — the resolver, the router, or the ISP.
- Switch to public DNS. Set the system resolver to
1.1.1.1(Cloudflare) and1.0.0.1as backup, or8.8.8.8+8.8.4.4(Google). If the page loads after the change, your previous resolver was returning NXDOMAIN incorrectly — either a stale negative cache or a deliberate block. - Check the domain's actual existence.
dig example.com @1.1.1.1from a terminal queries Cloudflare's resolver directly. If it returnsstatus: NXDOMAIN, the domain genuinely doesn't exist (or the authoritative nameservers are broken). If it returns an answer, the domain exists; the issue is between you and Cloudflare's view of DNS. - Look at the hosts file. A line like
0.0.0.0 example.comin/etc/hostswill produce the same symptom. Pi-hole or similar local DNS sinkholes count too.
Why the error doesn't go away when you "refresh harder" ¶
A common Reddit answer to NXDOMAIN is to clear browser cache + cookies + restart Chrome. None of those touch DNS. Browser cache holds the rendered HTML and assets, not DNS resolution — DNS lives in the OS resolver and the network layer above it. Restarting Chrome flushes Chrome's internal DNS cache (visit chrome://net-internals/#dns for the manual flush button), which sometimes helps for case 2, but rarely for the others. The systematic fix is the diagnostic above; the "refresh harder" advice mostly works by accident when the resolver's negative-cache TTL expires between attempts.
If you're a site owner seeing your own visitors hit this ¶
Two situations:
- Right after a DNS change: propagation. Negative caches at downstream resolvers may still hold "doesn't exist" for the duration of the SOA's negative-TTL field — typically minutes to a few hours. Wait it out; nothing on your side speeds it up. Setting a short negative-TTL on your authoritative records before any change is the way to mitigate this in advance.
- Random visitors hitting NXDOMAIN long after a change: this is almost always a specific resolver returning a stale or malicious answer. Your authoritative DNS is fine; some downstream resolver isn't. Customer support is the usual triage path because there's nothing you can fix from your side.
FAQ ¶
Is NXDOMAIN the same as "site is down"?
No. "Site is down" usually means the server isn't responding (timeout, 5xx, refused connection). NXDOMAIN is one layer earlier — DNS says the name doesn't exist, so no connection is even attempted. If the domain truly doesn't resolve, the site can't be loaded; if it resolves but the server is offline, you get a different error (timeout, connection refused).
Can switching DNS to 1.1.1.1 break anything?
Rarely. The main side-effect is that DNS-based parental controls, captive portals (hotel Wi-Fi, airport Wi-Fi), and some ISP-provided "internet safety" features depend on the ISP's resolver and stop working when you switch. If you can't get past a captive portal after changing DNS, switch back temporarily, log in, then switch again. For corporate networks: don't override the corporate resolver without coordinating — internal hostnames usually only resolve on the corporate DNS.
Why does Cloudflare's 1.1.1.1 sometimes get blocked?
Some networks deliberately block 1.1.1.1 either at the DNS port (53) or HTTPS port to force users back to the network's controlled resolver. Captive portals and corporate networks do this most. If 1.1.1.1 doesn't work, try 9.9.9.9 (Quad9) or 8.8.8.8 (Google) — they're less commonly blocked.
Is there a way to avoid resolver-level censorship without changing DNS?
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the DNS query so the path between you and the resolver can't see what you're asking about. Modern browsers support DoH directly (Firefox enables it by default for Cloudflare; Chrome supports it as a setting). DoH bypasses ISP-level DNS interception even if you keep the same resolver — useful in networks where DNS over plain UDP is being intercepted.