How to Fix DNS_PROBE_FINISHED_NXDOMAIN

DNS Beginner 8 min read Published July 2025

DNS_PROBE_FINISHED_NXDOMAIN is the Chrome error message you see when the browser asks a DNS resolver for the IP address behind a hostname and receives an NXDOMAIN response — literally "non-existent domain." Before Chrome can open any TCP connection it must first translate the human-readable name (like example.com) into a numeric IP address. When the resolver reports that the name does not exist, Chrome stops and displays this error instead of loading the page.

The failure almost never points to a Chrome bug. It sits at the intersection of your operating system's DNS cache, your router, your ISP's recursive resolver, and the authoritative name servers that actually own the domain. That is why the same site may load fine on your phone's cellular data but fail on your laptop's Wi-Fi, or work in one browser but not another. The six steps below walk through the causes in the order you are most likely to hit them, from a simple stale cache all the way to an expired domain.

What Is DNS_PROBE_FINISHED_NXDOMAIN?

Every URL contains a hostname. Computers on the internet find each other by IP address, not by name, so the hostname has to be translated first. This translation is DNS resolution, and it works like a chain of lookups:

  1. Browser cache. Chrome checks its own internal DNS cache. If it recently resolved the name, it reuses the IP and stops here.
  2. OS cache. The operating system's resolver cache is checked next. Windows, macOS, and Linux all keep recent answers to avoid repeated network round-trips.
  3. Router cache. The request goes to your home or office router, which often runs its own caching forwarder.
  4. Recursive resolver. The router forwards the query to a recursive DNS server — usually your ISP's, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1.
  5. Authoritative servers. The recursive resolver walks the DNS hierarchy: the root servers, then the TLD servers (e.g. .com), then the domain's authoritative name servers, which finally return the A or AAAA record with the IP address.

If any link in that chain returns NXDOMAIN — a cache holds a poisoned or stale negative entry, the resolver is unreachable, the authoritative server reports the name as absent, or the domain simply has no DNS records — resolution fails and Chrome raises DNS_PROBE_FINISHED_NXDOMAIN. The full message usually reads "This site can't be reached. example.com's server IP address could not be found."

Common Causes

The table below maps each root cause to its most recognizable symptom and the fix that resolves it. Use it to triage quickly before working through the full step-by-step guide.

Cause Symptom Fix
Stale or poisoned DNS cache One device fails; others load the site fine Flush the OS and browser DNS cache
ISP resolver is down or slow Every site is slow or fails on one network Switch to 8.8.8.8 or 1.1.1.1
Corrupted browser cache / HSTS Only Chrome fails; other browsers work Clear cache, cookies, and HSTS entries
Stale hosts file entry Only one specific domain breaks, on one machine Remove the override line from the hosts file
VPN or dead proxy intercepting DNS Sites work when the VPN is off Disable the VPN and clear proxy settings
Domain expired or missing DNS records The site fails for everyone, everywhere Renew the domain; add correct A/CNAME records

Step-by-Step Fix Guide

Work through these six steps in order. Each one targets a different layer of the DNS resolution chain, so even if an earlier step does not fix the problem, it narrows down the cause for the next one.

Step 1: Flush the DNS Cache

The fastest fix. If a cached entry holds a negative NXDOMAIN answer (a "negative cache" entry), every subsequent request reuses that bad answer until the cache expires. Clear it manually so the resolver is forced to fetch a fresh record.

# Windows (Command Prompt or PowerShell)
ipconfig /flushdns

# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
# or, on newer systems:
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

After flushing, fully quit Chrome (not just closing the tab) and reopen it so the browser's own internal cache is also dropped. Retry the site. If it loads, a stale cache was the culprit.

Step 2: Change DNS Servers

If flushing the cache did not help, the problem may be upstream: your ISP's recursive resolver could be down, hijacking NXDOMAIN responses, or simply unreliable. Switching to a fast public resolver bypasses it entirely.

The two most popular choices are Google Public DNS and Cloudflare DNS:

On Windows, go to Settings > Network & Internet > adapter properties > IPv4 properties and set the preferred and alternate DNS servers manually. On macOS, use System Settings > Network > Details > DNS. On Linux, edit /etc/resolv.conf or your NetworkManager DNS settings. On a router, changing the DNS server there fixes every device on the network at once.

Step 3: Clear Chrome Cache and Cookies

Chrome keeps its own DNS cache and an HSTS list that forces certain domains to HTTPS. A corrupted entry here can break a single site in Chrome while every other browser on the same machine works fine. Clear the browsing data to reset these.

# Open Chrome's internal DNS page directly
chrome://net-internals/#dns

# Then click "Clear host cache"
# Also clear the socket pool at chrome://net-internals/#sockets

For a deeper reset, go to Chrome > Settings > Privacy and security > Clear browsing data, select Cookies and other site data and Cached images and files, and clear them for the affected site or all time. This removes stale HSTS pins and service-worker registrations that can also interfere with resolution. If the site loads in an Incognito window but not in your normal profile, a cached entry or extension is almost certainly to blame.

Step 4: Check the hosts File

The operating system's hosts file overrides real DNS. A leftover entry from old testing, a migration, or even malware can pin a domain to a dead IP, and no amount of cache flushing or server switching will fix it because the file is consulted before any DNS query is sent.

# Windows path
C:\Windows\System32\drivers\etc\hosts

# Linux and macOS path
/etc/hosts

Open the file with administrator privileges and look for any line mentioning the domain that fails to load. A typical override looks like 127.0.0.1 example.com. Comment it out by adding a # at the start of the line, save the file, and reload the page. Remember to flush the DNS cache afterward so the old override is not still cached.

Step 5: Disable VPN and Proxy

A VPN routes your DNS queries through an encrypted tunnel. If the VPN client crashes, the tunnel endpoint dies, or the VPN's internal DNS server fails, your queries go nowhere and every site reports DNS_PROBE_FINISHED_NXDOMAIN. The same is true for a stale manual proxy left behind by a VPN that did not clean up after itself.

Turn the VPN off completely and test. On Windows, check Settings > Network & Internet > Proxy and disable any manual proxy. On macOS, check System Settings > Network > Details > Proxies. In Chrome, review installed extensions for anything that forces a proxy or secure DNS setting, then disable it. If the site loads with the VPN off, the VPN configuration is the problem — update the client or switch its DNS setting to a public resolver.

Step 6: Check Domain DNS Records

If the first five steps fail and the site breaks for everyone (test on a different network or with a friend), the problem is on the domain side. The domain may have expired, its authoritative name servers may be down, or it may simply have no A or CNAME records configured. Use dig and nslookup to interrogate the DNS hierarchy directly.

# Query the A record using the default resolver
dig example.com A +short

# Query a specific authoritative server
dig @ns1.example.com example.com A

# Trace the full resolution path from the root
dig +trace example.com

# nslookup (available on Windows and Linux)
nslookup example.com
nslookup example.com 8.8.8.8

If dig returns NXDOMAIN, the domain does not exist in DNS — check whether it has expired at the registrar. If it returns SERVFAIL, the authoritative servers are misconfigured or unreachable. If it returns NOERROR but no answer, the domain exists but has no A/AAAA record; add the correct records in your DNS provider's dashboard and wait for propagation.

DNS Diagnostic Commands

The snippets below show the most common DNS diagnostic commands you will touch while debugging DNS_PROBE_FINISHED_NXDOMAIN. Use them as a reference when applying the fixes above.

dig — inspect records and trace the resolution chain:

# Full answer with TTL and authoritative section
dig example.com

# Check nameservers for the domain
dig example.com NS +short

# Verify a CNAME chain
dig www.example.com CNAME

# Trace the full path from root servers
dig +trace example.com

nslookup — quick interactive lookup, useful on Windows:

# Basic lookup
nslookup example.com

# Query a specific record type and server
nslookup -type=NS example.com 8.8.8.8

resolv.conf (Linux) — defines which recursive resolvers the system uses:

# /etc/resolv.conf
nameserver 1.1.1.1
nameserver 8.8.8.8
options timeout:2 attempts:3

Cloudflare DNS-over-HTTPS API — verify resolution from an external network without a VPN:

curl -s "https://1.1.1.1/dns-query?name=example.com&type=A" \
  -H "accept: application/dns-json"

Quick Reference: DNS Response Codes

DNS responses carry status codes (defined in RFC 1035 / RFC 6895). Knowing which one your resolver returns tells you exactly where the resolution chain broke.

Code Name Meaning Typical Cause
NOERROR No Error Query succeeded Domain resolves; look elsewhere if the site still fails
NXDOMAIN Non-Existent Domain The domain does not exist Domain expired, typo in the URL, or DNS not yet set up
SERVFAIL Server Failure Resolver could not complete the query Authoritative servers down, DNSSEC validation failure
REFUSED Query Refused The server refused to answer Rate limiting, ACL, or restricted recursive resolver
FORMERR Format Error The query was malformed Broken client or software bug in the resolver

FAQ

What is the difference between DNS_PROBE_FINISHED_NXDOMAIN and ERR_CONNECTION_REFUSED?

DNS_PROBE_FINISHED_NXDOMAIN happens before any connection is attempted — Chrome could not find the IP address for the hostname at all because the resolver returned an NXDOMAIN status. ERR_CONNECTION_REFUSED happens after DNS resolution succeeds: Chrome found the IP and tried to connect, but the server actively rejected the TCP connection. In short, the first is a name-lookup failure; the second is a port-level rejection.

Why does DNS_PROBE_FINISHED_NXDOMAIN affect only one device?

When a single device fails but others on the same network work, the problem is local to that device. The most likely causes are a stale DNS cache holding a negative entry, a leftover line in the hosts file, a VPN or proxy running only on that machine, or a Chrome-specific cached HSTS entry. Flushing the cache and clearing browser data usually resolves it.

How long does it take for DNS changes to propagate?

Propagation depends on the TTL (Time To Live) set on each DNS record. A low TTL of 300 seconds can update in minutes, while a default TTL of 86,400 seconds (24 hours) means some resolvers may serve the old record for a full day. You can speed things up by flushing your local cache and querying a public resolver like 1.1.1.1 directly, since public resolvers often refresh faster than ISP caches.

Can a router cause DNS_PROBE_FINISHED_NXDOMAIN?

Yes. Many home routers run their own caching DNS forwarder. If the router's cache becomes corrupted, its upstream DNS server is unreachable, or its firmware has a bug, every device behind that router can fail to resolve names. Restarting the router clears its cache, and changing the router's DNS server to 8.8.8.8 or 1.1.1.1 fixes persistent resolver problems for the whole network.

Conclusion

DNS_PROBE_FINISHED_NXDOMAIN looks alarming, but it always boils down to one fact: Chrome received an NXDOMAIN response and could not get an IP address for the hostname. By working down the resolution chain — browser cache, OS cache, router, recursive resolver, and finally the authoritative servers for the domain — you can pinpoint the exact layer that failed. In the majority of cases the fix is quick: flush the cache, switch to a public resolver like 8.8.8.8 or 1.1.1.1, or remove a stale hosts entry. When the problem persists for everyone everywhere, the domain itself is the issue, and dig or nslookup will tell you whether it is expired, misconfigured, or simply missing its DNS records.

Keep a public resolver configured as a fallback, flush your cache after any network change, and you will resolve most DNS_PROBE_FINISHED_NXDOMAIN errors in under a minute.

Related Guides