DNS_PROBE_FINISHED_NXDOMAIN - How to Fix It

DNS_PROBE_FINISHED_NXDOMAIN This site can't be reached Check if there is a typo in example.com.

DNS_PROBE_FINISHED_NXDOMAIN means a DNS server gave your browser a definite answer: that name does not exist. It is not a timeout and not a connection failure - the lookup completed and came back empty.

Is This You or the Site?

Do this before anything else. It takes thirty seconds and decides which half of the article you need.

Load the site on your phone with Wi-Fi turned off, using mobile data. That puts you on an entirely different network with a different DNS resolver.

For a definitive answer, query a public resolver directly and see what the internet as a whole is told:

# Windows
nslookup example.com 1.1.1.1

# macOS / Linux
dig +short A example.com @1.1.1.1

An empty response or NXDOMAIN from a public resolver means the record genuinely does not exist. Our DNS lookup tool shows the same result from outside your network, which is useful when you cannot reach a command line.

Also check the obvious: read the domain in the address bar carefully. A transposed letter produces exactly this error, and it is the single most common cause.

Visitor-Side Fixes

1. Flush the DNS cache

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux (systemd):

resolvectl flush-caches

Then clear the browser's own cache, which is separate from the operating system's. Visit chrome://net-internals/#dns (or edge://net-internals/#dns) and click Clear host cache.

2. Check the hosts file

A stale entry here overrides DNS completely and survives every cache flush.

Windows - open Notepad as administrator and read C:\Windows\System32\drivers\etc\hosts. macOS / Linux - cat /etc/hosts.

Remove or comment out any line naming the site you are trying to reach. Development tools, ad blockers and old troubleshooting sessions all leave entries behind.

3. Disconnect the VPN

VPN clients push their own DNS servers and often use split-DNS rules that resolve internal names but not public ones. Disconnect and retry. If that fixes it, the VPN's DNS configuration is the problem and its administrator needs to look at it.

4. Try a different resolver

Temporarily set your DNS to a public resolver:

# Windows, as administrator - note the interface name from: Get-NetAdapter
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses 1.1.1.1,8.8.8.8

To revert:

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses

If a public resolver works and your ISP's does not, the ISP resolver has a stale or filtered answer.

5. Restart the router

Routers cache DNS too, and consumer models cache it badly. Power-cycle for thirty seconds. Do this after the steps above, not before - it is slow and rarely the cause.

Site-Owner Fixes

If the name fails from every network, the record is missing where it matters.

1. Confirm the domain has not expired

An expired domain is pulled from the registry and every lookup returns NXDOMAIN. Check the expiry date in a WHOIS lookup before touching DNS at all - no amount of record editing helps a lapsed registration.

2. Confirm the nameservers

This catches out more people than missing records. You may be editing a zone that nothing is reading.

dig NS example.com +short

The nameservers returned must match the DNS provider whose control panel you are editing. If your registrar still points at an old host's nameservers, your new records are invisible.

3. Confirm the record exists - including the subdomain

example.com and www.example.com are separate records. A zone with an A record for the apex but nothing for www returns NXDOMAIN for www while the bare domain works perfectly.

dig +short A example.com @1.1.1.1
dig +short A www.example.com @1.1.1.1
dig +short CNAME www.example.com @1.1.1.1

Add the missing A, AAAA or CNAME record in your DNS provider.

4. Allow for propagation

A newly created record usually resolves within minutes. A changed record is held by resolvers for its TTL - often an hour, sometimes twenty-four. Lower the TTL a day before a planned change so the cutover is quick.

Verify the Fix

# The name resolves from a public resolver
dig +short A example.com @1.1.1.1

# And from your machine
nslookup example.com

A returned IP address, followed by the page loading in a fresh browser tab, is the confirmation. Check from a second network as well - a result that works only on the machine you fixed means you cleared a local cache rather than solving the underlying record problem.

Prevention

• Monitor domain expiry with a calendar reminder independent of registrar email, which lands in spam more often than anyone expects.
• Lower TTLs to five minutes a day before a planned DNS migration, then raise them again once traffic is stable.
• After any nameserver change, verify with dig NS from outside your network rather than trusting the registrar's confirmation screen.
• Create both apex and www records as a matter of routine, even when you only intend to use one - the redirect costs nothing and prevents a whole class of report.
• Keep the hosts file clean on development machines. Entries added for a one-off test are the ones that cause confusion months later.

Related Errors

If the name resolves but the page still fails, you have moved on to a different problem - a connection error means DNS worked and the server did not answer, and a certificate error means the connection was established but the identity check failed.