Skip to main content
Fix guide

DNS_PROBE_FINISHED_NXDOMAIN: find out if it’s you or the site, then fix it

Test record

Tested 22 Oct 2026 Last verified 22 Oct 2026
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.

Chrome error page: This site can’t be reached. Check if there is a typo in isitblocked.org. DNS_PROBE_FINISHED_NXDOMAIN
Chrome 155, 22 Oct 2026. isitblocked.org is a real, working site. Chrome showed this only because its secure DNS was set to Quad9, which blocks it.

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 upWhat DNS answered, and what Chrome showed
A subdomain with no record on our Cloudflare zoneDNS: NXDOMAIN, from Cloudflare
Chrome: NXDOMAIN
A .net domain nobody has registeredDNS: 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 DNSDNS: SERVFAIL
Chrome: NXDOMAIN
A real, working site, with Chrome’s secure DNS set to Quad9, which blocks itDNS: NXDOMAIN, made up by the filter
Chrome: NXDOMAIN
Chrome’s secure DNS pointed at a server that doesn’t existDNS: 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.

Chrome error page: techweed.net’s server IP address could not be found. DNS_PROBE_FINISHED_BAD_SECURE_CONFIG
Same Chrome, with secure DNS pointed at a server that doesn't exist. This time the code changes.

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/#dns and click Clear host cache.
  • On Windows, run ipconfig /flushdns in 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: NXDOMAIN with the aa flag, 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: NOERROR and 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

  1. Ask Cloudflare again with dig @YOUR-NS.ns.cloudflare.com www.example.com A +norec. It should now show status: NOERROR and an ANSWER section.
  2. Then ask public DNS. nslookup www.example.com 1.1.1.1 and nslookup www.example.com 8.8.8.8 should both return an address. If one still can’t find it, wait for the cache time from step 5.
  3. Clear Chrome’s host cache at chrome://net-internals/#dns and reload the page.
  4. 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.

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

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.