
DNS_PROBE_FINISHED_NXDOMAIN means Chrome asked DNS for the site's IP address, got "non-existent domain" back, and then confirmed your resolver itself works. Check the spelling, flush the DNS cache, review Chrome's "Use secure DNS" setting and try 1.1.1.1 or 8.8.8.8. If the error appears on every network, the domain's own DNS is broken.
What does the DNS_PROBE_FINISHED_NXDOMAIN error mean?
NXDOMAIN (Non-Existent Domain) is a DNS response code that says: "no such domain exists in this zone." Your browser tried to turn the hostname into an IP, and the DNS answer it received said the name does not exist. This is not a connection failure with the site — the request never even reached the server.
The "DNS_PROBE_FINISHED" part is Chrome-specific. When a lookup fails, Chrome (and every Chromium browser, including Edge, Brave and Opera) runs a quick probe against a name it knows should resolve. The label on the error page is the probe's verdict:
| Error on the page | What Chrome concluded | Where to look first |
|---|---|---|
DNS_PROBE_FINISHED_NXDOMAIN | DNS works, but this particular name has no answer | Spelling, cache, secure DNS setting, the domain's records |
DNS_PROBE_FINISHED_NO_INTERNET | The probe itself failed — no working network path | Wi-Fi, cable, router, adapter |
DNS_PROBE_FINISHED_BAD_CONFIG | The system DNS configuration is unusable | DNS server addresses in network settings |
DNS_PROBE_FINISHED_BAD_SECURE_CONFIG | The DNS-over-HTTPS provider set in Chrome is failing | Chrome's "Use secure DNS" setting |
ERR_NAME_NOT_RESOLVED | The lookup failed; no probe verdict shown | Same checks as NXDOMAIN |
NXDOMAIN is a name-resolution problem, not a server-availability one. The site can be perfectly healthy, but if DNS returns no IP, the browser has nowhere to connect.
Other browsers report the same condition in their own words: Firefox says "Hmm. We're having trouble finding that site," and Safari says "Safari Can't Find the Server." The fixes below apply to all of them.
How do I fix the DNS_PROBE_FINISHED_NXDOMAIN error?
Work from the cheapest check to the most invasive one. Most cases end in the first three steps.
- Check the address for typos.
exmaple.cominstead ofexample.comis the single most common cause. Also check the ending:.covs.com, a stray dot, a missingwww. - Test from another network. Open the site on your phone over mobile data. Works? The problem is your network/resolver, not the domain's DNS records.
- Flush the DNS cache in the operating system and in the browser (commands in the table below).
- Check Chrome's secure DNS setting — a custom DNS-over-HTTPS provider that filters or fails will produce NXDOMAIN for names that exist.
- Switch the system resolver to a public one to rule out your ISP or router.
- Try another browser and an incognito window to rule out extensions, especially ad blockers and "privacy" add-ons that intercept requests.
- Reset the network stack if nothing else helped (Windows commands below).
- Query the domain directly with
digornslookup. If every public resolver returns NXDOMAIN, only the domain owner can fix it.
Check DNS with dig and nslookup
The dig command shows exactly what the resolver returns. Look at the status: field in the header, not only at the answer section:
dig example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; ANSWER SECTION:
example.com. 300 IN A 203.0.113.10 # sample output
# If you see "status: NXDOMAIN" the name does not exist:
dig example.com +short # empty = domain does not resolve
# Query a specific resolver (Cloudflare, then Google):
dig @1.1.1.1 example.com +short
dig @8.8.8.8 example.com +short
# Follow the delegation from the root down:
dig +trace example.com
# Windows / alternative:
nslookup example.com
nslookup example.com 8.8.8.8
If dig @1.1.1.1 returns an IP but your system resolver does not, the problem is your local cache or your ISP's DNS. In nslookup the same NXDOMAIN answer reads *** ... can't find example.com: Non-existent domain.
Not every empty answer is NXDOMAIN, and the difference points to different fixes:
| dig status | Meaning | Typical cause |
|---|---|---|
NXDOMAIN | The name does not exist at all | Typo, expired or held domain, broken delegation, missing subdomain record, DNS filter |
NOERROR with no answer | The name exists, but not with this record type | Only AAAA or MX is set, no A record for the host you asked about |
SERVFAIL | The resolver could not get a trustworthy answer | DNSSEC validation failure, unreachable nameservers, lame delegation |
REFUSED | The server will not answer this query for you | Querying a nameserver that does not host the zone or refuses recursion |
For a SERVFAIL, repeat the query with dig +cd example.com (checking disabled). If an answer appears only with +cd, the domain has a DNSSEC problem rather than a missing record.
Flush the DNS cache
| System | Command | Effect |
|---|---|---|
| Windows | ipconfig /flushdns | Clears the Windows resolver cache |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder | Resets mDNSResponder |
| Linux (systemd) | sudo resolvectl flush-caches (older releases: sudo systemd-resolve --flush-caches) | Clears systemd-resolved |
| Chrome | chrome://net-internals/#dns → Clear host cache | Resets the browser's internal DNS cache |
| Edge | edge://net-internals/#dns → Clear host cache | Same page, Edge build of Chromium |
| Firefox | about:networking#dns → Clear DNS Cache | Resets Firefox's own DNS cache |
After clearing the host cache in Chrome or Edge, also open chrome://net-internals/#sockets (or the edge:// equivalent) and click "Flush socket pools", then restart the browser. Full per-platform steps are in our guide to flushing the DNS cache.
How do I fix a DNS error in Chrome?
Chrome can resolve names on its own, bypassing the operating system, through DNS over HTTPS. That is why the error sometimes appears only in Chrome while nslookup works fine.
- Open
chrome://settings/security(Settings → Privacy and security → Security). - Find Use secure DNS. If it is set to a custom provider or a filtering service, switch it to "With your current service provider" or to a well-known provider such as Cloudflare or Google.
- Reload the page. If it opens, the previous DoH provider was failing or deliberately blocking that name.
- Clear the host cache at
chrome://net-internals/#dnsand disable extensions one by one (chrome://extensions).
On a managed work or school computer this setting may be locked by policy; then the organization's DNS is the thing to ask about.
DNS_PROBE_FINISHED_NXDOMAIN in Edge
Edge is built on Chromium and shows the identical error. The secure DNS switch lives under edge://settings/privacy → Security → "Use secure DNS to specify how to lookup the network address for websites". The cache page is edge://net-internals/#dns.
How can I fix the DNS_PROBE_FINISHED_NXDOMAIN error on my Mac?
- Flush the cache in Terminal:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. The command prints nothing on success. - Check which resolvers macOS is using:
scutil --dns | grep nameserver. - Open System Settings → Network → your connection (Wi-Fi or Ethernet) → Details → DNS. Remove stale entries left by old routers or software and add 1.1.1.1 or 8.8.8.8.
- Look for configuration or network extensions (security suites, content filters) under System Settings → General → Login Items & Extensions or in the network's Filters section; they can answer DNS on their own.
- If the name fails only in Safari, check whether iCloud Private Relay is on for this network — it resolves names differently for Safari — and test once with it off to isolate the cause.
Remember that dig and nslookup on macOS query DNS servers directly and skip the system cache, while browsers go through mDNSResponder. A clean dig result with a failing browser usually means a stale cache or a local filter.
DNS_PROBE_FINISHED_NXDOMAIN on Android and mobile
On phones the usual suspect is Private DNS, Android's system-wide DNS-over-TLS setting. If it points at a hostname that is down, mistyped or filtering, every app gets NXDOMAIN-style failures.
- Open Settings → Network & internet (on some phones: Connections → More connection settings) → Private DNS.
- Set it to Automatic, or enter a known provider hostname such as
one.one.one.oneordns.google. Menu names vary by manufacturer. - Toggle airplane mode on and off to drop cached lookups, or restart the phone.
- In Chrome for Android, clear cached data: Settings → Privacy and security → Delete browsing data.
- Switch between Wi-Fi and mobile data. If only one of them fails, that network's DNS (often the router) is the cause.
On an iPhone the equivalent checks are Settings → Wi-Fi → (i) → Configure DNS, and any installed DNS profile under Settings → General → VPN & Device Management.
Switch your DNS resolver
If your ISP resolver is failing, switch to a public one:
- Cloudflare: 1.1.1.1 and 1.0.0.1
- Google: 8.8.8.8 and 8.8.4.4
- Quad9: 9.9.9.9
On Windows: Network settings → Adapter properties → IPv4 → set DNS manually. On macOS: System Settings → Network → DNS. Changing DNS on the router instead fixes every device on the network at once.
Reset the network stack on Windows
When flushing and switching resolvers change nothing, reset Winsock and TCP/IP from an elevated Command Prompt, then reboot:
ipconfig /flushdns
ipconfig /release
ipconfig /renew
netsh winsock reset
netsh int ip reset
Also check the hosts file at C:\Windows\System32\drivers\etc\hosts (on macOS and Linux: /etc/hosts). A leftover entry does not cause NXDOMAIN itself, but it can hide whether DNS works for that name.
Why www.googleadservices.com shows DNS_PROBE_FINISHED_NXDOMAIN
www.googleadservices.com is the redirect domain Google Ads uses for ad clicks and conversion tracking. If you hit this error after clicking an ad, an ad blocker, Pi-hole or a filtering DNS service on your network is answering NXDOMAIN for that name on purpose — that is how many DNS blockers work. The target site is usually fine: open it by typing its address instead of clicking the ad. If you run the filter yourself, check its query log and allow the domain only if you want ad clicks to work. How filtering resolvers behave is covered in our AdGuard DNS article.
If you own the domain
NXDOMAIN from the owner's side usually means the A record is not configured, or the domain is expired or delegated incorrectly. Check:
- An A record exists for the apex and for
www(check your DNS records). - The NS servers match between registrar and zone.
- The domain registration has not lapsed.
- DNS propagation has completed after a record change (up to 48 hours).
A few commands make each of these checks concrete:
# Which nameservers does the registry delegate to? (.com example)
dig NS example.com @a.gtld-servers.net
# Does the zone on those nameservers actually hold the record?
dig www.example.com A @ns1.your-dns-provider.example
# Registration state: look for "clientHold", "serverHold" or "redemptionPeriod"
whois example.com
A domain in clientHold or serverHold status is removed from the zone file, so every resolver returns NXDOMAIN even though your records at the DNS host are untouched. The fix is at the registrar: renew, finish contact verification, or resolve the hold reason.
A subdomain that returns NXDOMAIN while the apex works simply has no record: shop.example.com needs its own A, AAAA or CNAME record, and a CNAME whose target no longer exists also ends in NXDOMAIN.
After changing DNS records, the old NXDOMAIN may stay cached at some resolvers until the TTL expires. Verify from several locations, not just your own machine.
That negative answer has its own lifetime: resolvers cache NXDOMAIN for a period taken from the zone's SOA record, as defined in RFC 2308. Check it with dig SOA example.com +short; the last number is the SOA minimum. Keep it modest before adding new hostnames so a premature lookup does not linger.
How to check
Local tools see your own cache and resolver. To see what the rest of the internet sees, check from outside:
- DNS lookup — every record type (A, AAAA, MX, NS, TXT, CNAME, SOA) resolved server-side, which removes your local cache from the equation.
- DNS propagation checker — queries resolvers in different regions at once, so you can tell a stale cache from a missing record.
- WHOIS lookup — expiry date and registry status codes such as
clientHold.
How enterno.io helps
The enterno.io DNS checker shows every record (A, AAAA, MX, NS, TXT, CNAME, SOA) and resolves the domain server-side, which removes your local cache from the equation. Uptime monitoring with a DNS check type every minute catches a record disappearing before visitors notice and alerts you via Telegram, Slack, email, or webhook. enterno.io diagnoses and warns — the DNS record itself is fixed by the owner at the registrar.
Related guides: ERR_NAME_NOT_RESOLVED (the same failure without the probe label) and DNS_PROBE_FINISHED_NO_INTERNET (when the probe itself fails).
FAQ
Is this my computer or the website?
Open the site over mobile data. If it works there, the issue is local (cache, resolver). If NXDOMAIN appears everywhere, the domain's DNS records are the problem.
Why does the site load on another network but not on my Wi-Fi?
Each network hands out its own resolver. If the site opens elsewhere, your router or ISP DNS is returning NXDOMAIN — set 1.1.1.1 or 8.8.8.8 on the device or the router.
How long after changing an A record?
Until the previous record's TTL expires plus propagation time — typically minutes to 48 hours. Lower the TTL in advance to speed it up.
Why does dig return an IP but the browser still errors?
The browser keeps its own DNS cache. Clear it at chrome://net-internals/#dns and restart the browser.
Can an ad blocker cause DNS_PROBE_FINISHED_NXDOMAIN?
Yes. DNS-level blockers and some extensions answer NXDOMAIN for blocked names. If only tracking or ad domains fail, the filter is working as designed.
Is DNS_PROBE_FINISHED_NXDOMAIN a virus?
Almost never. Malware that tampers with DNS usually redirects you to a wrong IP rather than returning NXDOMAIN. Check the DNS servers in your network settings and the hosts file if they look unfamiliar.
Next step: Check your domain's DNS records server-side to confirm whether the A record is being served. See also Domain not resolving: what to do and set up DNS monitoring.