DNS_PROBE_FINISHED_NXDOMAIN: find out if it’s you or the site, then fix it
Test record
- Tested on
- MacBook on home Wi-Fi (router DNS), and our DigitalOcean droplet (Ubuntu 24.04). Our domain on Cloudflare Free.
- Versions
- Chrome 155.0.8059.85 on macOS 27.0.1, dig 9.10.6 and 9.18.39, systemd-resolved 255
Short answer
Chrome shows this when your DNS works but gave no address for this one name. Open the same address on mobile data. If it fails there too, the problem is the site's DNS: a missing record, wrong nameservers, a leftover DNSSEC record or a lapsed domain. If it loads there, look on your side: a DNS filter, Chrome's secure DNS setting or a cached answer.
On this page
Chrome shows this error when it can’t get an address for a website’s name. The code sounds like the website doesn’t exist, but that’s often not what happened. We set up six different DNS failures and tested them from our own Mac and server, and Chrome gave five of them this exact label. Find the root first, then pull the weed. A one-minute test on your phone tells you which side the problem is on, and each cause below has its own fix.
What you’ll see
A grey Chrome page that says This site can’t be reached, then Check if there is a typo in example.com, and under that the code DNS_PROBE_FINISHED_NXDOMAIN.

What the error really means
When a lookup fails, Chrome runs a quick check of its own. It asks your DNS service for the address of google.com, and asks Google Public DNS (8.8.8.8) too. The code you see depends only on that check, not on what went wrong with the site’s name:
DNS_PROBE_FINISHED_NXDOMAIN
Your DNS service works, but it gave no address for this one name. Look at the address you typed, the site’s DNS, or a filter in your DNS service.DNS_PROBE_FINISHED_BAD_CONFIG
Your DNS service failed, but Google Public DNS worked. Look at the DNS settings on your device or router.DNS_PROBE_FINISHED_BAD_SECURE_CONFIG
Chrome’s “Use secure DNS” provider failed, but Google Public DNS worked. Look at Chrome’s secure DNS setting.DNS_PROBE_FINISHED_NO_INTERNET
Your DNS service didn’t work, and Google Public DNS couldn’t be reached. Look at your connection.DNS_PROBE_FINISHED_INCONCLUSIVE
Both answered, but with errors. This is often a Wi-Fi sign-in page or a strict firewall. Sign in to the Wi-Fi, or try another network.
So NXDOMAIN really means “your DNS works, and this name didn’t”. That’s still a useful clue. It tells you to stop fiddling with your connection and look at the name instead. This logic is in Chrome’s source code, linked under Sources.
How we reproduced it
On 22 October 2026 we broke DNS on purpose in six ways and opened each address in a fresh Chrome 155 profile. Every lookup was read-only, and nothing on our live site changed.
Chrome’s codes are shortened in this table, so NXDOMAIN means DNS_PROBE_FINISHED_NXDOMAIN.
| What we set up | What DNS answered, and what Chrome showed |
|---|---|
| A subdomain with no record on our Cloudflare zone | DNS: NXDOMAIN, from Cloudflare Chrome: NXDOMAIN |
| A .net domain nobody has registered | DNS: NXDOMAIN, from the .net registry Chrome: NXDOMAIN |
| A name that exists but has no address (it only holds a TXT record) | DNS: No error, but no address Chrome: NXDOMAIN |
| A domain with broken DNSSEC, looked up through Cloudflare’s DNS | DNS: SERVFAIL Chrome: NXDOMAIN |
| A real, working site, with Chrome’s secure DNS set to Quad9, which blocks it | DNS: NXDOMAIN, made up by the filter Chrome: NXDOMAIN |
| Chrome’s secure DNS pointed at a server that doesn’t exist | DNS: No answer Chrome: BAD_SECURE_CONFIG |
Two things surprised us.
Broken DNSSEC depends on who’s asking. Our home router doesn’t check DNSSEC, so it returned an address and Chrome tried to connect. Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9) all refused with SERVFAIL. So a site can work for its owner and still fail for every visitor who uses one of those services.
And a filter’s “no such name” looks exactly like the real thing in Chrome. The site Quad9 blocked loaded its address normally through Cloudflare’s DNS.

How we tested: Rahul ran every command in this guide on 22 October 2026, on his Mac (macOS 27, home Wi-Fi) and on our DigitalOcean server (Ubuntu 24.04), and saved the output. The outputs below are real, trimmed for length.
Which fix applies to you
Start with a one-minute test. Turn off Wi-Fi on your phone and open the same address on mobile data.
- If it loads on your phone, the problem is on your side: your DNS service, Chrome’s settings or a cached answer. Go to Fixes on your device or network.
- If it fails on your phone too and it’s your site, go to Fixes for site owners on Cloudflare.
- If it fails on your phone too and it isn’t your site, check the spelling once more. If it’s right, the site’s DNS is broken or the domain has lapsed. Nothing on your device will fix that, so try again later or tell the owner.
- If no site loads at all, that’s a different problem. See Related errors.
If your phone uses a “Private DNS” or ad-blocking app, it isn’t a clean second opinion. Use a friend’s phone or a different network instead.
Fixes on your device or network
1. Check Chrome’s secure DNS setting
Chrome can ignore your computer’s DNS and use its own provider. Open chrome://settings/security and find Use secure DNS. If Select DNS provider shows a filtering service (CleanBrowsing (Family Filter), or a custom address such as Quad9 or NextDNS), it may be blocking the site.
Switch it to OS default (when available) or Cloudflare (1.1.1.1) and reload the page. In our test, the same site failed with Quad9 and resolved with Cloudflare.
2. Check whether your DNS service filters sites
DNS filters live in ad-blocking DNS apps, router parental controls, some VPNs and some “secure” DNS services. Some of them, Quad9 among them, answer “no such name” for anything on their block list. Others answer with a dummy address, which gives a different Chrome error. To check, ask your normal DNS and then ask Cloudflare’s. This works on Windows, Mac and Linux:
nslookup example.com
nslookup example.com 1.1.1.1
If the first says it can’t find the name and the second gives an address, your DNS service is filtering. Here’s the same check against Quad9, with a site it blocks:
$ nslookup isitblocked.org 9.9.9.9
** server can't find isitblocked.org: NXDOMAIN
$ nslookup isitblocked.org 1.1.1.1
Non-authoritative answer:
Name: isitblocked.org
Address: 74.208.236.124
Fix it by allow-listing the site in your filter, or by turning the filter off for a moment to confirm. If you use dig, there’s one more clue: Quad9’s made-up answer had no ra flag and an empty AUTHORITY section. A genuine NXDOMAIN from the same server had both.
3. Clear cached “no such name” answers
A “no such name” answer gets remembered, sometimes in three places: Chrome, your computer and your router. If the site was broken a few minutes ago and is fixed now, clear them:
- In Chrome, open
chrome://net-internals/#dnsand click Clear host cache. - On Windows, run
ipconfig /flushdnsin Command Prompt. Microsoft’s docs say this discards cached “negative” answers. We didn’t test this one on Windows. - On Linux with systemd-resolved, run
resolvectl flush-caches. We ran it on Ubuntu 24.04. - On a Mac, restart it. That clears the system cache.
- Restart your router as well, because many routers keep their own DNS cache.
Your internet provider’s DNS (or 1.1.1.1, or 8.8.8.8) keeps its own copy too. You can’t clear that, but it expires on its own. On our Cloudflare zone, that took up to 30 minutes (see step 5 for owners).
Fixes for site owners on Cloudflare
Run these checks in order. Each takes about a minute. Replace example.com with your domain, and YOUR-NS with one of the two Cloudflare nameservers shown on your domain’s Overview page in the Cloudflare dashboard (ours is nicole). The commands use dig, which comes with macOS and most Linux systems. On Windows, use nslookup www.example.com YOUR-NS.ns.cloudflare.com for step 1, and nslookup -type=ns example.com a.gtld-servers.net for step 2. For step 2, read the lines under “Authoritative answers can be found from”. We ran both on macOS, not on Windows.
1. Ask Cloudflare directly whether the record exists
dig @YOUR-NS.ns.cloudflare.com www.example.com A +norec
This skips every cache and asks the server that’s in charge of your domain. Here’s what a missing record looked like on ours:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41517
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; AUTHORITY SECTION:
techweed.net. 1800 IN SOA nicole.ns.cloudflare.com. dns.cloudflare.com. 2417966091 10000 2400 604800 1800
- If you see
status: NXDOMAINwith theaaflag, Cloudflare has no record with that name. Add it on the DNS Records page of your Cloudflare dashboard. This is easy to hit after moving to Cloudflare, because its import scan only checks a list of common names, so a custom subdomain can get left behind. - If you see
status: NOERRORand an ANSWER section, the record is fine. Go to step 2.
2. Check your nameservers at the registry
Your registrar tells the registry (for example, the .com or .net registry) which nameservers to send visitors to. Ask the registry what it has. For .com and .net:
dig @a.gtld-servers.net example.com NS +norec
For other endings, use dig +trace example.com NS and read the last section. You should see exactly your two Cloudflare nameservers and nothing else, like ours:
;; AUTHORITY SECTION:
techweed.net. 172800 IN NS nicole.ns.cloudflare.com.
techweed.net. 172800 IN NS piers.ns.cloudflare.com.
If you see your old host’s nameservers, the change at your registrar hasn’t been published yet. Check that you saved it. Then ask the registrar how long its changes take to go live, because some are much slower than others. If the Cloudflare names don’t match the ones on your Overview page, copy them across exactly.
3. Check for a leftover DNSSEC record
If DNSSEC was on with your old DNS host, your registrar may still hold its DS record. Cloudflare’s keys won’t match it, so every resolver that checks DNSSEC will refuse your domain. First see whether a DS record exists:
dig DS example.com +short
An empty result means DNSSEC is off, so skip to step 4. If something comes back, ask a resolver that checks DNSSEC:
dig @1.1.1.1 example.com A
Here’s what broken DNSSEC looked like in our test. The second line, an “Extended DNS Error”, says why. Our server’s dig 9.18 printed it; the older dig 9.10 that comes with macOS didn’t:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5067
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)
To fix it, delete the old DS record at your registrar. Cloudflare’s own troubleshooting docs give the same fix. If you want DNSSEC, turn it on in Cloudflare afterwards and add the new DS record it gives you. Cloudflare says to allow up to 24 hours for the old DS record to drop out of caches, so some visitors may keep failing for a while.
4. Check the domain hasn’t expired or been put on hold
When a domain lapses, the registry can take it out of DNS, and then every visitor gets NXDOMAIN. Look it up at lookup.icann.org, or from a terminal:
curl -sL https://rdap.org/domain/example.com | grep -oE '"status":\[[^]]*\]|"eventAction":"expiration","eventDate":"[^"]*"'
Ours came back healthy:
"status":["client transfer prohibited"]
"eventAction":"expiration","eventDate":"2027-11-19T21:49:22Z"
Watch for client hold, server hold or redemption period, or an expiry date in the past. ICANN says a domain on hold “will not resolve”. Renew it, or contact your registrar. Then turn on auto-renew.
5. Wait out the cached “no such name”
If someone looked up the name before you created the record, DNS services may keep repeating the old “no such name”. RFC 2308 caps that at the smaller of two numbers in your zone’s SOA record. On our Cloudflare zone, both were 1,800 seconds. That’s up to 30 minutes. To see the figure for your own zone, run this and read the last number:
$ dig example.com SOA +short
nicole.ns.cloudflare.com. dns.cloudflare.com. 2417966091 10000 2400 604800 1800
We watched this happen. We asked Google Public DNS for a missing name twice, 20 seconds apart. The second answer came from its cache, with the time left counting down from 1,800 to 1,780. Step 1 already proves your fix is live at Cloudflare. After that, it’s just waiting.
Check it’s fixed
- Ask Cloudflare again with
dig @YOUR-NS.ns.cloudflare.com www.example.com A +norec. It should now showstatus: NOERRORand an ANSWER section. - Then ask public DNS.
nslookup www.example.com 1.1.1.1andnslookup www.example.com 8.8.8.8should both return an address. If one still can’t find it, wait for the cache time from step 5. - Clear Chrome’s host cache at
chrome://net-internals/#dnsand reload the page. - Finally, load it on a second network, such as your phone on mobile data.
Undo
- If you changed Chrome’s secure DNS, set it back to the provider you had.
- If you added a record, delete it on the DNS Records page in Cloudflare.
- If you removed a DS record, don’t put the old one back, because it belongs to your old DNS host. Turn on DNSSEC in Cloudflare and add the new DS record instead.
- Clearing caches needs no undo.
What didn’t work
Switching to Google or Cloudflare DNS when the record was missing. Cloudflare’s own server, 1.1.1.1 and 8.8.8.8 all gave the same NXDOMAIN. Changing your DNS only helps when your DNS is the one getting it wrong.
Switching to 8.8.8.8 with broken DNSSEC. This made it worse. Our router, which doesn’t check DNSSEC, returned an address. 8.8.8.8, 1.1.1.1 and 9.9.9.9 all returned SERVFAIL.
Flushing caches while the record was still missing. The next lookup got the same NXDOMAIN straight from Cloudflare.
The older version of this guide suggested resetting chrome://flags, running netsh winsock reset and clearing cookies. We didn’t re-run those, and removed them, because none of them changes which DNS server you ask or what it answers.
Related errors
DNS_PROBE_FINISHED_BAD_CONFIG
Your DNS service failed while Google Public DNS worked, so the problem is your device’s or router’s DNS settings, not the site. Restart the router first. Then check your device’s network settings: if the DNS servers listed there aren’t ones you chose, set DNS back to automatic. To confirm the diagnosis, try 1.1.1.1 for a few minutes. We didn’t reproduce this one, because it needs your computer’s network settings changed.
DNS_PROBE_FINISHED_BAD_SECURE_CONFIG
Chrome’s secure DNS provider failed. We reproduced this by pointing it at a server that doesn’t exist. Fix it with step 1 under Fixes on your device or network.
DNS_PROBE_FINISHED_NO_INTERNET and ERR_INTERNET_DISCONNECTED
NO_INTERNET means Chrome couldn’t reach any DNS server at all. ERR_INTERNET_DISCONNECTED means your computer told Chrome there’s no network, so Chrome didn’t even try. Check Wi-Fi or the cable, airplane mode, and any VPN “kill switch”. If other apps are offline too, restart the router. We didn’t reproduce these two.
“DNS lookup failed” on Windows 10
Older versions of Chrome used this wording for a failed name lookup. Current Chrome shows one of the codes above instead, so start with Which fix applies to you.
Sources
- Chromium source: how Chrome picks the code (dns_probe_service_factory.cc,
EvaluateResults) and what it checks (dns_probe_runner.cc) - RFC 2308, section 5: how long “no such name” answers are cached
- RFC 8914: Extended DNS Errors, including 9 (DNSKEY Missing)
- Cloudflare docs: nameserver troubleshooting (DS records, exact nameservers), zone stuck in Pending Nameserver Update and DNS records quick scan
- ICANN: EPP status codes (clientHold, serverHold, redemptionPeriod)
- Quad9 FAQ: blocked domains get an NXDOMAIN answer
- Microsoft Learn: ipconfig (/flushdns)
- Our test log from 22 October 2026 (every command, its raw output and the Chrome screenshots), kept with this guide
Changelog
22 Oct 2026: rewritten from scratch after testing every step on Chrome 155. Merged in three older posts: “DNS lookup failed” on Windows 10, ERR_INTERNET_DISCONNECTED and DNS_PROBE_FINISHED_BAD_CONFIG. Removed the 2018 advice (resetting chrome://flags, netsh winsock reset, clearing cookies), because none of it changes a DNS answer. First published 28 Feb 2018.