What Does the DNS_PROBE_FINISHED_NXDOMAIN Error Mean, and How Do You Fix It?

You type a URL, hit Enter, and instead of a page Chrome shows "This site can't be reached" with a small code underneath: DNS_PROBE_FINISHED_NXDOMAIN. It looks cryptic, but it's actually one of the most specific errors a browser can give you. It means the browser asked a DNS resolver for the domain's IP address and the resolver answered, definitively, that the name does not exist. That's different from a timeout or a server outage, and it narrows the list of possible causes a lot. If you want the protocol-level background on that response code, the post on NXDOMAIN, SERVFAIL, and REFUSED responses covers it in depth.

This article focuses on the browser error itself: what Chrome is actually telling you, how to work out whether the problem is on your device or on the domain's side, and the fixes that work for each case — for visitors and for site owners whose own domain suddenly shows this error.

What the Error Actually Means

The code breaks down into three parts:

• DNS_PROBE — Chrome hit a DNS failure while loading the page and ran a quick diagnostic "probe" to classify what went wrong.
• FINISHED — the probe completed and reached a conclusion.
• NXDOMAIN — the conclusion is that the resolver returned the NXDOMAIN response code, short for "non-existent domain."

In other words, the network is working, a DNS resolver is reachable, and that resolver said "there is no such name." Compare it with its sibling codes:

Chrome error code	What the probe concluded	Typical cause
DNS_PROBE_FINISHED_NXDOMAIN	Resolver says the name does not exist	Typo, expired domain, missing record, stale cache, hosts file, filtering
DNS_PROBE_FINISHED_NO_INTERNET	No network connectivity at all	Wi-Fi down, cable unplugged, router offline
DNS_PROBE_FINISHED_BAD_CONFIG	DNS settings on the device look broken	Invalid or unreachable DNS server configured
DNS_PROBE_POSSIBLE	Probe couldn't finish classifying	Intermittent network or resolver issues

Other browsers report the same underlying condition with friendlier wording. Firefox says "Hmm. We're having trouble finding that site," Safari says it "can't find the server," and Edge, being Chromium-based, shows the same DNS_PROBE_FINISHED_NXDOMAIN code as Chrome.

Why NXDOMAIN isn't always the truth

An NXDOMAIN answer is only as trustworthy as the resolver that gave it. Several things can produce one even when the domain is perfectly healthy for everyone else:

1. A cached negative answer. Resolvers and operating systems remember "this name doesn't exist" for a period defined by the zone's SOA record. If you visited a site just before its DNS record was created, you can keep getting NXDOMAIN after it's fixed. This is negative caching, and it's a very common cause after a site launch.
2. A filtering resolver. Pi-hole, corporate DNS firewalls, parental-control services, and security-focused resolvers often block domains by returning NXDOMAIN. From the browser's point of view, a blocked domain and a non-existent one look identical.
3. A local override. Entries in the hosts file, VPN split-DNS rules, or browser extensions can intercept a lookup before it ever reaches public DNS.

So the first job is always to figure out whose NXDOMAIN you're looking at.

Step 1: Work Out Whether the Problem Is You or the Domain

The quickest test is to ask a different resolver the same question. If a public resolver finds the domain and yours doesn't, the problem is local. If every resolver says NXDOMAIN, the problem is with the domain itself.

On macOS or Linux:

# Ask your configured resolver
dig example.com A +short

# Ask Cloudflare and Google directly, bypassing your local settings
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

# See the full response, including the status line
dig @1.1.1.1 example.com A

The +short output gives you just the IP address (or nothing). The full output contains a header line like status: NXDOMAIN or status: NOERROR, which is the part that matters. Note that NOERROR with an empty answer section is a different situation — the name exists but has no record of the type you asked for.

On Windows, use PowerShell:

# Your configured resolver
Resolve-DnsName example.com -Type A

# A specific public resolver
Resolve-DnsName example.com -Type A -Server 1.1.1.1

If you'd rather script the comparison, here's a small Python check using dnspython (pip install dnspython) that queries several resolvers and reports each verdict:

import dns.exception
import dns.resolver

DOMAIN = "example.com"
RESOLVERS = {
    "system": None,
    "Cloudflare": "1.1.1.1",
    "Google": "8.8.8.8",
    "Quad9": "9.9.9.9",
}

for label, server in RESOLVERS.items():
    resolver = dns.resolver.Resolver(configure=server is None)
    if server:
        resolver.nameservers = [server]
    resolver.lifetime = 4
    try:
        answer = resolver.resolve(DOMAIN, "A")
        ips = ", ".join(r.address for r in answer)
        print(f"{label:<11} OK        {ips}")
    except dns.resolver.NXDOMAIN:
        print(f"{label:<11} NXDOMAIN  name does not exist")
    except dns.resolver.NoAnswer:
        print(f"{label:<11} NOANSWER  name exists, no A record")
    except dns.resolver.NoNameservers:
        print(f"{label:<11} SERVFAIL  no server could answer")
    except dns.exception.Timeout:
        print(f"{label:<11} TIMEOUT")

The script builds a fresh resolver for each target — configure=True reads your system settings, configure=False starts empty so you can point it at a specific server — and maps each dnspython exception to the DNS outcome it represents. If only the "system" line says NXDOMAIN, skip to the device fixes below. If every line says NXDOMAIN, jump to the domain-owner section.

Step 2: Fixes When the Problem Is on Your Device

Work through these roughly in order. Most people are fixed by the first three.

Check the address for typos

It sounds obvious, but a single wrong character (exmaple.com, a missing hyphen, .co instead of .com) is the single most common cause of a genuine NXDOMAIN. Retype the address rather than relying on autocomplete, which can keep suggesting a mistyped version you visited earlier.

Clear Chrome's internal DNS cache

Chrome keeps its own host cache separate from the operating system's. Open chrome://net-internals/#dns and click Clear host cache, then visit chrome://net-internals/#sockets and click Flush socket pools. Edge has the same pages under edge://net-internals/. The full walkthrough for every browser is in the guide on clearing the DNS cache in Chrome, Firefox, and Edge.

Flush the operating system's DNS cache

If the browser cache wasn't it, the OS resolver cache might be holding a stale negative answer:

# Windows (run as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
sudo resolvectl flush-caches

Each command discards cached answers so the next lookup goes back out to the resolver. More detail, including other Linux setups, is in how to flush the DNS cache.

Check the hosts file

A hosts file entry overrides DNS entirely, and some malware, ad blockers, and old development setups add lines that break real domains. Look for the domain in C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on macOS and Linux:

grep -i "example.com" /etc/hosts

Select-String -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Pattern "example.com"

If you find a line you didn't add on purpose, remove it. See what the hosts file is and how it overrides DNS for how precedence works.

Turn off VPNs, proxies, and filtering extensions

VPN clients often install their own DNS resolver, and some corporate VPNs resolve only internal names correctly while returning NXDOMAIN for others. Disconnect the VPN, disable DNS-related browser extensions, and test again. If you run Pi-hole or a filtering resolver, check its query log — a blocked domain will show up there.

Check Chrome's Secure DNS setting

Chrome can send lookups over DNS over HTTPS to a provider you choose, independently of your system settings. Go to Settings → Privacy and security → Security → Use secure DNS. If it's set to a custom or filtering provider, switch it to your current service provider or a mainstream resolver and retry. This is a frequent source of "it works in Firefox but not Chrome" reports.

Switch to a different DNS resolver

If your ISP's resolver is the one returning NXDOMAIN (and public resolvers aren't), changing your device or router to Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9) bypasses it. Step-by-step instructions for each platform are in how to change DNS settings on Windows, Mac, iPhone, and Android.

Renew your network configuration (Windows)

As a last resort on Windows, renewing the DHCP lease and resetting the network stack clears out corrupted settings:

ipconfig /release
ipconfig /renew
ipconfig /flushdns
netsh winsock reset
netsh int ip reset

These commands drop and re-request your IP and DNS assignment, then reset Winsock and TCP/IP configuration to defaults. A reboot is required after the two netsh commands.

Step 3: Fixes When the Domain Itself Returns NXDOMAIN

If every resolver agrees the domain doesn't exist and you own the site, the problem is in the domain's registration or DNS configuration. These are the usual suspects.

The domain has expired or been suspended

When a registration lapses, the registrar typically removes the domain's nameservers from the TLD zone, which makes the whole domain return NXDOMAIN. Registrars and registries can also place a domain on hold for unpaid invoices, failed contact verification, or abuse complaints. Check the status codes:

whois example.com | grep -iE "status|expir"

Statuses such as clientHold or serverHold mean the domain has been pulled from DNS. clientHold is set by the registrar and is usually cleared by paying the renewal or verifying your contact email; serverHold is set by the registry and needs a support request through your registrar.

The TLD has no delegation for your nameservers

Even with a valid registration, the domain won't resolve if the TLD servers don't know which nameservers are authoritative for it. Ask a TLD server directly:

# Find the .com TLD servers, then ask one of them about your domain
dig NS com +short
dig @a.gtld-servers.net example.com NS +norecurse

A healthy response lists your nameservers in the authority section. If the TLD server itself returns NXDOMAIN, the delegation is missing — usually because nameservers were never set at the registrar or the domain isn't active yet. The guide on updating nameservers for a domain covers setting them correctly.

The nameservers don't have a zone for the domain

Delegation can point to a DNS provider where you never created the zone — common after switching providers. Query the authoritative server directly:

dig @ns1.example-dns-host.net example.com SOA +norecurse

If it answers REFUSED or returns nothing, the provider isn't serving your zone. Add the domain in that provider's dashboard or point the nameservers back to where your records actually live.

The specific hostname has no record

Sometimes example.com works but www.example.com or app.example.com returns NXDOMAIN. That simply means no record exists for that name. Add an A, AAAA, or CNAME record for it at your DNS host. Remember that a name that exists with no A record returns NOERROR with an empty answer, not NXDOMAIN — so an NXDOMAIN on a subdomain means there's nothing at all at that name (and no wildcard covering it).

Trace the full resolution path

When you can't tell where the chain breaks, dig +trace walks it from the root:

dig +trace www.example.com A

The output shows each step — root servers, the TLD servers, then your authoritative servers. The step where NXDOMAIN first appears tells you which layer is missing the data.

Wait out negative caching after you fix it

If you created a record after someone had already looked it up, their resolver may cache the NXDOMAIN for up to the zone's negative TTL (the smaller of the SOA record's TTL and its minimum field). Check yours:

dig example.com SOA +short

The last number in the output is the minimum field. If it's 3600, expect up to an hour before every resolver stops returning the old NXDOMAIN. Lowering it before a launch reduces the window next time.

Preventing the Error on Your Own Sites

A few habits keep your visitors from ever seeing this error:

1. Turn on auto-renew and keep registrar contact details current. Expiry is the most damaging cause because it takes everything down at once, including email.
2. Create records before you announce a URL. Publishing a link to a hostname that doesn't exist yet seeds negative caches across the internet.
3. Verify delegation after any provider change. Run the TLD query above and a direct query to each new nameserver before you consider a migration done.
4. Monitor resolution from outside your network. A scheduled check that alerts on NXDOMAIN catches expiry, accidental record deletion, and holds within minutes rather than when customers complain.

---

DNS_PROBE_FINISHED_NXDOMAIN FAQ

Conclusion

DNS_PROBE_FINISHED_NXDOMAIN is less mysterious once you read it literally: a resolver answered, and it said the name doesn't exist. The fix depends entirely on whose answer that was. Compare your resolver against a couple of public ones first. If they disagree, the cause is local — a typo, a stale browser or OS cache, a hosts file entry, a VPN, or a filtering resolver — and the steps above will clear it in a few minutes.

If every resolver agrees, the domain itself is the problem, and the cause is almost always one of a short list: an expired or held registration, missing delegation at the TLD, a provider that isn't serving the zone, or a hostname that was never created. Tracing the lookup with dig +trace shows exactly which layer is missing, and once it's fixed, the only remaining delay is negative caching running out.

These references are useful for digging further into NXDOMAIN and resolution failures:

1. RFC 8020: NXDOMAIN: There Really Is Nothing Underneath — clarifies what an NXDOMAIN response means for a name and everything below it.
2. RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) — defines how long resolvers may cache NXDOMAIN answers.
3. Google Chrome Help: Fix connection errors — Google's own guide to Chrome's network and DNS error messages.
4. Cloudflare Learning Center: What is DNS? — background on how resolvers and authoritative servers work together.
5. ICANN: EPP Status Codes — explains domain statuses such as clientHold and serverHold.