DNS_PROBE_FINISHED_NXDOMAIN: what it means and how to fix it

Chrome shows this one as "This site can't be reached", with "Check if there is a typo in" and the address underneath, then DNS_PROBE_FINISHED_NXDOMAIN at the bottom of the page.

That bottom line is not an error code, which is the first thing worth knowing about it. It is the result of a test Chrome ran after the page had already failed. And the result says something very specific that almost every guide to this error contradicts in its opening paragraph.

This message is a second opinion, not the original failure

Chrome keeps its network errors in a single list in the Chromium source, net_error_list.h. The failure you actually hit is in there:

// The host name could not be resolved.
NET_ERROR(NAME_NOT_RESOLVED, -105)

Search that same file for DNS_PROBE_FINISHED_NXDOMAIN and you will not find it. It is not a network error at all. It lives in a completely different file, net_error_info.h, inside an enum called DnsProbeStatus.

So the sequence is this. The navigation fails with ERR_NAME_NOT_RESOLVED. Chrome puts up an error page, and then runs its own DNS probe in the background. When the probe finishes, Chrome replaces the code on the already-visible page with the probe's verdict. If you have ever watched the text at the bottom of that page change by itself a second after it appeared, that is what you were watching.

The verdict you got has this comment against it in the source:

The DNS servers are working fine, so the domain must not exist.

Read that again next to the advice on the first page of search results. Flush your DNS cache. Switch to 8.8.8.8. Restart your router. Reset Winsock. Those are all fixes for broken DNS service, and Chrome ran a test for broken DNS service before it printed those words on your screen. It has a different code for that case, and this is not it.

What each probe result actually means

Since the message is a probe verdict, the other verdicts are worth knowing, because they tell you which problem you are being handed. These are Chrome's own descriptions from the enum, matched to what they mean in practice.

That table is the whole diagnostic shortcut. People arrive at BAD_CONFIG advice while holding an NXDOMAIN page, and then spend an afternoon changing resolvers that were never broken.

One honest qualification, because it matters later: "working fine" means your resolver answered properly and promptly. It does not mean your resolver is holding correct data. A resolver can be in perfect health and still be confidently telling you about a record that changed twenty minutes ago. That gap is where most of the genuinely confusing cases live.

Thirty seconds that decide everything

Before changing any setting, answer one question: is it one name or everything?

Open two or three unrelated sites. Then load the failing address on your phone with wifi off, over mobile data.

If every site fails, you are almost certainly looking at the wrong code and should re-read the bottom of the page, because a total DNS failure normally produces BAD_CONFIG or NO_INTERNET. If one name fails and everything else is fine, Chrome is telling you the truth and the name is the problem.

The rest of this splits along that line.

If one name fails: the name is the suspect

Start with the typo, genuinely

Chrome's suggestion on the page is to check for a typo, and it is correct far more often than its reputation suggests. A trailing character, a .cm where you meant .com, a hyphen in the wrong place. There is no shame in this one, and it costs three seconds to rule out.

Check whether the name resolves anywhere at all

This is the test that separates "my setup is broken" from "this record does not exist", and it takes one command. Ask a public resolver directly, bypassing whatever your machine normally uses:

nslookup example.com 8.8.8.8

When the name genuinely does not exist, the answer is unambiguous:

*** dns.google can't find thisnamedoesnotexist-dnsprev.com: Non-existent domain
Server:  dns.google
Address:  8.8.8.8

If a public resolver also says the name does not exist, you are done diagnosing your own machine. Nothing in your browser, your router or your network settings can create a DNS record that was never published. Either the domain has expired, the record was never made, or it was made somewhere that is not currently authoritative for the domain.

If the public resolver answers normally and your machine does not, the cause is local, and the next three sections cover where it hides.

The record exists but you are still being told it does not

This is the case people find maddening, and it has a precise cause that is written into the DNS specification.

Negative answers are cached. RFC 2308 requires an authoritative server reporting NXDOMAIN to include the zone's SOA record, specifically so the "does not exist" answer can be stored, with a lifetime "set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself". The spec is explicit that a name error "should be cached such that it can be retrieved and returned in response to another query for the same" name.

You can watch the timer arrive. Asking for a name that does not exist under .com returns an authority record with its lifetime attached:

AUTHORITY RECORDS:
->  com
    ttl = 900 (15 mins)

So the practical consequence: if anyone using your resolver looked up the name before the record existed, that resolver may keep handing out "does not exist" for the length of that timer, no matter what the record says now. The website is live. Your colleague on a different network sees it. You do not.

This is also why flushing your DNS cache so often achieves nothing here. Flushing empties your machine's copy. The cached negative answer that is actually blocking you usually lives on your resolver, one hop further out, and your machine cannot clear it. Flushing DNS is still worth thirty seconds because the local copy sometimes is the problem, but when it does not help, this is why.

The fastest way to confirm: query a resolver that has never been asked for this name, like the nslookup command above. If a public resolver has the record and yours does not, you are waiting out a negative TTL, and the only real options are to wait or to use a different resolver.

Something local is overriding DNS

Two local overrides produce this error while every diagnostic tool tells you the name is fine.

A hosts file entry. A line left over from an old test overrides DNS completely and silently, and it survives every cache flush, router restart and resolver change you can throw at it. If the entry points at an address that no longer serves the site, you get failures that no amount of DNS work will fix. The Windows hosts file guide covers where it lives and how to edit it, and this is the single most common reason a developer sees this error on a domain that works perfectly for everyone else.

A DNS-level filter. Pi-hole, AdGuard Home, NextDNS and corporate DNS filtering all intercept lookups, and some answer blocked names with NXDOMAIN. Worth being accurate here: Pi-hole supports an NXDOMAIN blocking mode but defaults to NULL, which returns 0.0.0.0 instead, so a Pi-hole in its standard configuration produces a different symptom. Other filters do use NXDOMAIN as their block response. If the name resolves on mobile data and fails on your own network, check the block list before you check anything else.

Secure DNS is pointed somewhere unhelpful

Chrome can do its own encrypted DNS lookups, independently of your operating system. When that provider is unreachable or has different data, you get failures the rest of your machine does not share. Chrome has a dedicated probe result for a broken configuration here, DNS_PROBE_FINISHED_BAD_SECURE_CONFIG, so if you are seeing plain NXDOMAIN instead, Chrome does not think the secure config is the problem. It is still worth a look when a name resolves at the command line but not in Chrome, since that specific split points straight at it. The setting is under Privacy and security, then Security, as "Use secure DNS".

On Android the equivalent is Private DNS in the network settings, and it is a common cause of a phone failing on names that the laptop next to it loads fine.

If every name fails

Then the code on the page is probably not the one in this article's title, and it is worth re-reading. A genuine resolver failure gives you BAD_CONFIG. No connectivity gives you NO_INTERNET.

If you really are seeing NXDOMAIN on everything, the likeliest explanation is a filter or a VPN intercepting all DNS and answering negatively, rather than a fault in the resolver itself. Disconnect the VPN entirely, rather than just disconnecting inside its app, and retest.

When it starts right after a server move

This error has a particular habit of appearing during migrations, and the reason is structural rather than bad luck.

A migration involves a window where the name is being looked up and the record is not finished. Nameservers changed but not yet answering. A record created at the old provider while the domain already points at the new one. A subdomain that existed on the old host and nobody remembered to recreate. Every one of those produces a real NXDOMAIN, and every lookup during that window plants a cached negative answer in whatever resolver asked.

Which is the trap. The person most likely to look up the domain early, repeatedly, is you, the person doing the migration. So you end up with the most thoroughly cached "this does not exist" of anyone involved, and spend the next quarter of an hour convinced the move failed while it is working perfectly for everybody else.

The way out is to not generate the negative answer at all. DNS Previewer gives you a link that loads the site on the new server under its real hostname, with the real Host header and the real certificate, before any record changes, so you can confirm the new server is serving correctly without asking DNS a question it cannot answer yet. Previewing a site without editing the hosts file covers why the old approach causes its own version of this problem, the WordPress migration checklist covers what else to confirm before flipping, and how long DNS propagation really takes explains why the window lasts as long as it does.

The order I'd work through it

1. Read the code at the bottom of the page carefully. BAD_CONFIG and NXDOMAIN send you in opposite directions.
2. Check the address for a typo. It is free.
3. One name or everything? Load another site, then the failing one on mobile data.
4. Run nslookup thename 8.8.8.8. If a public resolver also says it does not exist, stop looking at your machine.
5. Public resolver has it and you do not: check your hosts file, then your DNS filter, then assume a cached negative answer and wait out the TTL.
6. Works at the command line but not in Chrome: look at Secure DNS, or Private DNS on Android.
7. It started when you changed servers: the record is probably incomplete, and the answer you are seeing may be one you cached yourself.

The useful thing about this error, once you know where the message comes from, is how much it has already ruled out. Chrome tested your DNS service and found it healthy before it chose those words. The question left is not whether your network is broken. It is why that one name has no address, and that is a much shorter list.