DNS_PROBE_FINISHED_NXDOMAIN: What It Means and How to Fix It
You typed an address, hit Enter, and Chrome threw back a gray page: DNS_PROBE_FINISHED_NXDOMAIN. No site, no content, just an error code that reads like a license plate. The good news is that this one is unusually honest about what went wrong. Decode the name and you are most of the way to the fix.
NXDOMAIN stands for Non-Existent Domain. It is the answer a DNS resolver gives when it asks “what IP address belongs to this domain?” and the system answers “there isn’t one.” The lookup completed (that is the `DNS_PROBE_FINISHED` part), but the result was: this domain does not resolve to an IP address. Chrome can’t connect to a server it can’t find.
Key Takeaways
• NXDOMAIN = “this domain doesn’t resolve to an IP.” The DNS lookup ran and came back empty.
• First question: is it just you, or everyone? That single check decides which side to fix.
• Only your device sees it → client-side: flush your DNS cache, switch your resolver to 1.1.1.1 or 8.8.8.8, check your hosts file.
• Everyone sees it → server/domain-side: missing A record, expired domain, or nameservers not set or not propagated.
• Confirm the split with `nslookup`/`dig` or an online DNS checker before you touch anything.
What does DNS_PROBE_FINISHED_NXDOMAIN actually mean?
Every domain name has to be translated into an IP address before your browser can reach it. That translation is DNS resolution. Your device asks a DNS resolver, the resolver walks the chain of nameservers responsible for the domain, and ideally it gets back an A record (the domain’s IPv4 address) or an AAAA record (IPv6).
When that walk ends with “no such record exists,” the resolver returns the NXDOMAIN status. Chrome sees the empty answer, gives up the connection, and surfaces the code you’re staring at. Firefox phrases it differently (“Hmm. We’re having trouble finding that site”), but the underlying DNS condition is identical.
So the error is not “the website is down.” A down site still resolves to an IP — you’d get a different error. NXDOMAIN means the name itself led nowhere.
Here is the diagnostic shortcut that saves the most time: NXDOMAIN literally means the domain didn’t resolve to an IP, so before you fix anything, find out WHO sees the failure. If only your device returns NXDOMAIN, the domain resolves fine for the rest of the world and the problem is local — a stale DNS cache or a misbehaving resolver. Flush DNS and switch to 1.1.1.1, done. But if *everyone* gets NXDOMAIN (confirm with `dig` from another network or an online DNS checker), the domain itself has a genuine DNS problem — a missing A record, an expired registration, or nameservers that aren’t set or haven’t propagated. That one question — *just me, or everyone?* — tells you exactly which side to work on, so you never waste an hour flushing a cache that was never the issue.
Is it just you, or is the domain broken for everyone?
Run this check before anything else.
Open a terminal and query the domain directly:
“`bash
dig example.com +short
nslookup example.com “`
Then query it again through a public resolver to bypass your own setup:
“`bash dig @1.1.1.1 example.com +short nslookup example.com 8.8.8.8 “`
Interpret the result:
- You get an IP address back (something like `93.184.216.34`) → the domain resolves fine. The failure is client-side — your device or local network. Skip to the client fixes.
- You get `NXDOMAIN` or no answer everywhere, including through 1.1.1.1 and from an online DNS checker on a different network → the domain genuinely doesn’t resolve. It’s a server/domain-side problem. Skip to those fixes.
If you can’t use a terminal, an online DNS lookup tool queries the domain from servers around the world and shows you the same answer. Same logic: an IP means it’s you, a blank means it’s the domain.
Causes and fixes at a glance
| Side | Symptom | Likely cause | Fix |
|---|---|---|---|
| Client | Only your device fails; other devices/networks load the site | Stale DNS cache | Flush DNS cache |
| Client | One ISP fails, public resolver works | Faulty ISP resolver | Switch DNS to 1.1.1.1 or 8.8.8.8 |
| Client | Only Chrome fails | Chrome host cache / extension | Clear `chrome://net-internals/#dns`, test Incognito |
| Client | Random domains fail after install | Wrong entry in hosts file | Remove bad line from hosts file |
| Client | Fails only on VPN/proxy | VPN or proxy DNS | Disable VPN/proxy, retry |
| Server | Everyone gets NXDOMAIN | No A record configured | Add an A record at your DNS host |
| Server | Was working, now dead | Domain expired | Renew the domain |
| Server | New or recently moved domain | Nameservers not set / not propagated | Set nameservers, wait for propagation |
| Server | Only one URL fails | Typo in the address | Correct the spelling |
How do you fix the client-side causes?
These apply when the domain resolves for the world but not for you.
Flush your DNS cache
Your device caches DNS answers, including stale or failed ones. Clear it:
“`bash
ipconfig /flushdns
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
sudo resolvectl flush-caches “`
Switch to a public resolver
If your ISP’s resolver is flaky or returning bad answers, point your device at Cloudflare (1.1.1.1) or Google (8.8.8.8) instead. On Windows this lives under Network Adapter → Properties → IPv4 → DNS server addresses; on macOS under System Settings → Network → DNS. Add `1.1.1.1` and `8.8.8.8` as your two entries.
Clear Chrome’s own DNS cache
Chrome keeps a separate host cache from your operating system. Visit:
“` chrome://net-internals/#dns “`
Click Clear host cache, then reload. While you’re in Chrome, try the site in an Incognito window — Incognito disables extensions by default, so if it loads there, a browser extension (often a privacy or VPN add-on) is hijacking DNS.
Restart your router
A router holds its own DNS cache and occasionally drops its upstream resolver. Power it off for 30 seconds and back on. Crude, but it clears a surprising share of “only on my home network” cases.
Check the hosts file
The hosts file overrides DNS for specific names. A bad entry (left by software, a tutorial, or malware) can map a domain to nothing or to the wrong place.
“`bash
“`
Open it and remove any line referencing the domain you can’t reach (anything not commented with `#`). Save, then flush DNS again.
Disable VPN or proxy
A VPN or proxy routes your DNS through its own servers. If those servers choke, you get NXDOMAIN only while connected. Disconnect, retry, and if the site loads, the VPN’s DNS is the culprit.
How do you fix the server/domain-side causes?
These apply when `dig` returns NXDOMAIN from multiple networks — the domain is broken for everyone, and you can only fix it if you control the domain.
No A record configured
A freshly set up domain with no A record has nothing to resolve to. Log into your DNS management panel and add an `A` record pointing the domain (and usually `www`) to your server’s IP address. Verify:
“`bash dig example.com A +short “`
The domain expired
An expired domain stops resolving entirely — registrars pull the nameserver delegation. Check the expiry with a WHOIS lookup; if it lapsed, renew it. Resolution typically returns within hours of renewal, though it can take longer.
Nameservers not set or not propagated
If you just registered or transferred the domain, its nameservers may not be set at the registrar, or the change may still be propagating. Propagation can take anywhere from minutes to 48 hours. Confirm the delegation:
“`bash dig example.com NS +short “`
If the nameservers come back wrong or empty, set them at your registrar to match your DNS host, then wait. An online DNS checker that polls many global locations shows you propagation rolling out region by region.
A typo in the URL
The dullest cause and a real one. `exmaple.com` returns NXDOMAIN because that domain genuinely doesn’t exist. Re-read the address before you debug your whole stack.
Where reliable DNS prevents NXDOMAIN for your visitors
Most server-side NXDOMAIN errors trace back to one thing: DNS that was never configured correctly, or a host whose authoritative nameservers are unreliable. If your visitors are the ones seeing NXDOMAIN, the cost is direct — they simply can’t reach you.
DarazHost hosting runs on correctly configured, reliable authoritative DNS, so your domain resolves properly worldwide and your visitors don’t hit NXDOMAIN. The control panel makes it straightforward to set A records and nameservers correctly the first time, so a new or transferred domain comes online cleanly instead of dangling unresolved. And when something does go sideways with your domain’s DNS, 24/7 support helps you trace and fix it fast — before it costs you traffic. Reliable DNS isn’t a luxury feature; it’s the difference between a domain that loads and a domain that returns an error code.
Frequently asked questions
Does DNS_PROBE_FINISHED_NXDOMAIN mean the website is down?
No. A site that’s down still has a valid IP — you’d see a connection or timeout error instead. NXDOMAIN means the domain name didn’t resolve to any IP at all, which points to a DNS or registration issue, not a crashed server.
Why does the site load on my phone but not my computer?
Because it’s a client-side problem on your computer. Your phone (especially on mobile data, which uses a different resolver) is proving the domain resolves fine. Flush your computer’s DNS cache and switch its resolver to 1.1.1.1 or 8.8.8.8.
Will flushing DNS always fix this error?
Only when the cause is a stale local cache. Flushing does nothing if the domain genuinely doesn’t resolve for everyone — that’s a server-side issue you fix at the DNS host or registrar, not on your device. Always run the “just me or everyone?” check first.
How long does DNS propagation take for a new domain?
Typically minutes to a few hours, but officially up to 48 hours for nameserver changes. During that window, the domain may return NXDOMAIN from some networks and resolve on others. Use a global DNS checker to watch propagation complete.
Is 1.1.1.1 or 8.8.8.8 better for fixing this?
Both are reliable public resolvers and either resolves the client-side cases. 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google) are commonly set together as primary and secondary, so if one is unreachable the other answers.