# DNS_PROBE_FINISHED_NXDOMAIN: fixes for visitors and site owners

> DNS_PROBE_FINISHED_NXDOMAIN means the DNS lookup came back with "no such name", so the browser had no address to connect to. Here are the visitor fixes in order, then how site owners find the expired domain or missing record behind it.

Updated 2026-10-08 · Best practices · HTML version: https://getreport.app/guides/dns-probe-finished-nxdomain

DNS_PROBE_FINISHED_NXDOMAIN is Chrome's message when the DNS lookup for the address you typed came back with "this name does not exist", so the browser never had an IP address to connect to. The page reads "This site can't be reached" with "example.com's server IP address could not be found". NXDOMAIN is not a timeout or a slow server: a name server answered, and the answer was no. Most of the time a visitor can get past it in a few minutes; when the same error hits everyone, the domain's DNS is the cause and only the owner can fix it. This guide gives the visitor fixes in order, then the owner-side diagnosis with the exact commands. For how name resolution works end to end, start with [what DNS is and how a lookup travels](https://getreport.app/guides/what-is-dns).

## Quick answer

- **Check the address first.** NXDOMAIN very often means a typo, a made-up subdomain, or a domain that genuinely does not exist any more.
- **Visitor**: flush your DNS cache (`ipconfig /flushdns` on Windows), clear Chrome's host cache at `chrome://net-internals/#dns`, and switch your DNS server to `1.1.1.1` or `8.8.8.8`. Then check your hosts file and pause VPN or antivirus DNS filtering.
- **Owner**: run `whois` to see whether the domain expired, then `dig +short yourdomain.com A` and the same for `www`. An expired domain, changed name servers, or a missing A record for the exact host name are the usual causes.
- `dig` tells you which one: `status: NXDOMAIN` means the name does not exist; `status: NOERROR` with no answer means the name exists but has no address record.
- If your visitors see the error but you don't, your own machine is answering from cache or a hosts file; test against `1.1.1.1` and the authoritative name servers directly.

## What DNS_PROBE_FINISHED_NXDOMAIN means

Before any page loads, the browser asks a DNS resolver (usually your router's or your internet provider's) to turn the host name into an IP address. The resolver walks down from the root servers to the name servers responsible for the domain and asks them. NXDOMAIN ("non-existent domain", the term RFC 2308 uses for DNS's Name Error response) is those servers' way of saying the name you asked about does not exist at all. The resolver passes that answer back, and Chrome shows DNS_PROBE_FINISHED_NXDOMAIN because there is no address to connect to.

![Diagram: the browser asks its DNS resolver for example.com, the resolver asks the domain's authoritative name servers, they answer "no such name" (NXDOMAIN), and the browser shows DNS_PROBE_FINISHED_NXDOMAIN](https://getreport.app/guides/img/dns-probe-finished-nxdomain/diagram.svg "NXDOMAIN is an answer, not a timeout: a name server replied that the name does not exist.")

That makes it different from its neighbours. ERR_NAME_NOT_RESOLVED is Chrome's broader "I could not get an address" error, often when no resolver answered at all. ERR_CONNECTION_REFUSED and ERR_CONNECTION_TIMED_OUT mean DNS worked and the server itself did not answer. And certificate errors such as ["Your connection is not private"](https://getreport.app/guides/your-connection-is-not-private) or [ERR_SSL_PROTOCOL_ERROR](https://getreport.app/guides/err-ssl-protocol-error) mean DNS and the connection worked and HTTPS failed afterwards. Firefox shows the same NXDOMAIN failure as "Hmm. We're having trouble finding that site", and Safari as "Safari can't find the server".

Because the "does not exist" answer can be cached (by Chrome, by your operating system, by your router and by the resolver) the error can outlive its cause. That is why the visitor fixes below are mostly about clearing caches, and why an owner's fix takes a little while to reach everyone.

## If you're a visitor: fixes in order

Work down the list and stop when the page loads.

1. **Check the address for typos.** Read the domain in the address bar character by character: `gooogle.com`, `example.co` instead of `.com`, or a subdomain that never existed (`shop.example.com` when the shop lives at `example.com/shop`) all produce NXDOMAIN honestly. Search for the site's name instead of typing the address, and compare.

2. **Flush your system's DNS cache.** On Windows, open Command Prompt and run:

   ```
   ipconfig /flushdns
   ```

   On macOS, open Terminal and run:

   ```
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   ```

   The macOS command is the same from Big Sur through macOS 26 Tahoe; it prints nothing when it works.

3. **Clear Chrome's own host cache.** Chrome keeps a separate DNS cache. Paste `chrome://net-internals/#dns` into the address bar and click **Clear host cache**, then reload the page. (Edge: `edge://net-internals/#dns`.)

4. **Switch your DNS server to a public resolver.** If your provider's or router's resolver is giving stale or broken answers, Cloudflare's `1.1.1.1` or Google's `8.8.8.8` usually isn't.

   - **Windows 11**: Settings → Network & internet → Wi-Fi (or Ethernet) → your connection's properties → **DNS server assignment** → Edit → Manual → turn on IPv4 → Preferred DNS `1.1.1.1`, Alternate `8.8.8.8` → Save.
   - **macOS**: System Settings → Network → select your connection → Details… → DNS → click **+** and add `1.1.1.1` and `8.8.8.8` → OK.

   If the site loads after the switch, your old resolver was the problem; keep the new one or reboot the router and switch back later.

5. **Reboot the router.** Routers run their own small DNS cache and hand themselves out as the resolver to every device on the network. Power it off for 30 seconds and back on. If the error appears on every device in the house, this and step 4 are the likely fixes.

6. **Look for hosts-file leftovers.** The hosts file overrides DNS, and old development entries or "website blocker" tools leave lines behind that break real sites. Open `C:\Windows\System32\drivers\etc\hosts` (Windows, as administrator) or `/etc/hosts` (macOS and Linux, with `sudo`) and delete any line naming the domain, then save and flush the cache again.

7. **Pause VPNs and DNS-filtering software.** VPNs route DNS through their own resolvers, and antivirus suites, parental controls and ad blockers such as Pi-hole answer NXDOMAIN on purpose for names they block: sometimes wrongly. Disconnect the VPN or pause the filter; if the site then loads, add an exception or report the false positive to the filter's list.

If the site still fails on your phone over mobile data (a different device on a different network with different DNS) the domain itself is broken, and nothing on your side will fix it. Tell the owner if you can reach them another way.

## If you own the site: find the cause

Visitors telling you your site "does not exist" means the problem sits in your domain's DNS, not on your server. Check these in order; the first two cover most real cases.

**Did the domain expire?** Run `whois yourdomain.com` (or use your registrar's lookup) and read two lines: **Registry Expiry Date** and **Domain Status**. An expired domain is pulled from DNS even though whois still lists it, and a status of `clientHold` or `serverHold` means the registry has taken it out of the zone; the classic reasons being missed renewal or failed email verification of your contact details. Renewing, paying, or completing verification usually brings DNS back within hours. If the domain slipped into its redemption period, recovery still works at most registrars but costs a restore fee.

**Did the name servers change?** `dig NS yourdomain.com +short` shows which name servers the world is told to ask. If you recently moved registrar or DNS host and the output still names the old provider (or names the new one while your records only exist at the old one) lookups land on servers that answer "no such name". The fix is at the registrar: set the NS entries to your current DNS host's servers, and make sure that host actually has your zone with all its records.

**Is the record missing for this exact host name?** DNS is literal: `www.yourdomain.com` and `yourdomain.com` are two different names, and each needs its own A (IPv4) or AAAA (IPv6) record, or a CNAME pointing somewhere that has one. A site that works at the apex but returns NXDOMAIN for `www` (or the reverse) is missing one of the pair. Add the missing record at your DNS host and have one redirect to the other.

**Is something linking a name that never existed?** A newsletter, ad, or menu item linking `blog.yourdomain.com` when your blog lives at `yourdomain.com/blog` sends every clicker into NXDOMAIN. Search your own pages and campaigns for the host name visitors report. Either create the subdomain and redirect it, or fix the links.

**Did you just migrate?** After a registrar or DNS-host move, two things commonly go wrong: the new zone was created without some records (subdomains are the usual victims), and old NS data stays cached for up to the TTL of the delegation, often 24-48 hours. Compare the old and new zone record by record. If the move is part of a bigger change, [changing your domain without losing SEO](https://getreport.app/guides/domain-change-seo) walks through the redirect and Search Console side.

A rebuilt zone loses email records as often as it loses subdomains, and nobody notices until mail bounces. Once the site resolves again, check the email side of the zone in one run:

> **Free tool:** [DMARC checker: free SPF, DKIM and MX record check](https://getreport.app/tools/email-dns-check): Free DMARC checker that also tests SPF, DKIM and MX. See what is missing or broken and get the exact DNS records to add. No sign-up, results in seconds.

The check reads your domain's live MX, SPF, DKIM, DMARC and related records from DNS (the same lookup your visitors' resolvers do) so a record that was dropped in the move shows up as missing, with the exact record to paste back into your DNS host.

## Diagnose NXDOMAIN with dig and nslookup

`dig` (macOS and Linux; on Windows it ships with tools like BIND, or use `nslookup`) shows you exactly what a resolver sees. Ask a public resolver first:

```bash
dig @1.1.1.1 www.example.com A
```

Read the `status:` field in the header line:

- **`status: NXDOMAIN`**: the name does not exist at all: no record of any type. The domain is expired or on hold, the delegation points at servers without your zone, or the host name was never created.
- **`status: NOERROR` with `ANSWER: 0`**: the name exists but has no A record. Something is defined there (maybe only a TXT or MX record), but nothing that gives a browser an address. Add the A or AAAA record; nothing needs un-expiring.
- **`status: NOERROR` with answers**: DNS is fine from here; your visitor's resolver, cache or filter is the problem.

With `nslookup` on Windows the NXDOMAIN case reads `*** dns.google can't find www.example.com: Non-existent domain`:

```
nslookup www.example.com 8.8.8.8
```

Then ask your authoritative name servers directly, bypassing every cache. Get their names, then query one of them:

```bash
dig NS example.com +short
dig @ns1.your-dns-host.com www.example.com A
```

The combinations tell you where the problem lives:

| Public resolver says | Authoritative server says | Where the problem is |
| --- | --- | --- |
| NXDOMAIN | NXDOMAIN | The record really is missing: add it at your DNS host |
| NXDOMAIN | A record returned | The delegation is wrong or stale: fix the NS entries at the registrar, or wait out the old cache |
| A record returned | - | DNS works; the complaining visitor has a local cache, hosts entry or filter |

## How long until the fix reaches visitors?

Resolvers cache "does not exist" answers too, so NXDOMAIN lingers after you fix the record. RFC 2308 ties this negative cache to your zone's SOA record; in practice most resolvers hold a cached NXDOMAIN for a few minutes up to an hour. New visitors whose resolvers never asked are fine immediately. You can hurry the big public resolvers along: Cloudflare has a purge page at one.one.one.one/purge-cache and Google at dns.google/cache. Name-server changes are slower, since the old delegation can stay cached for 24-48 hours.

Verify the way a stranger would: `dig @1.1.1.1 yourdomain.com A` and `dig @8.8.8.8 www.yourdomain.com A` both returning your IP, plus the page loading on a phone over mobile data.

## Questions people ask

### What does DNS_PROBE_FINISHED_NXDOMAIN mean?

It means the DNS lookup for the address got the answer "this name does not exist": NXDOMAIN is the DNS term for that response (RFC 2308). The browser could not even start connecting, because there was no IP address to connect to. Either the name really does not exist (typo, expired domain, missing record) or a cache, hosts file or DNS filter on the visitor's side is answering wrongly.

### How do I fix DNS_PROBE_FINISHED_NXDOMAIN on Windows?

Open Command Prompt and run `ipconfig /flushdns`, then clear Chrome's own cache at `chrome://net-internals/#dns` with the Clear host cache button. If the error stays, switch DNS servers: Settings → Network & internet → your connection → DNS server assignment → Edit → Manual → `1.1.1.1` preferred, `8.8.8.8` alternate. Finally check `C:\Windows\System32\drivers\etc\hosts` for an old line naming the site.

### Why does my site show NXDOMAIN for visitors but work for me?

Because you and they are asking different resolvers. Your machine may be answering from its own cache, a hosts-file entry from development, or a resolver that still holds the record, while their resolvers get the current (broken) answer. Test like a stranger: `dig @1.1.1.1 yourdomain.com A` from any machine, or load the site on a phone over mobile data. If that fails, the domain's DNS needs fixing even though it "works" at your desk.

### Is NXDOMAIN caused by my internet provider?

Sometimes. Your provider's resolver can serve a stale cached answer, and some providers' filtering (or a country-level block) answers NXDOMAIN for names they refuse to resolve. The test takes a minute: switch your DNS server to `1.1.1.1` or `8.8.8.8` and reload. If the site appears, the provider's resolver was the cause and you can simply keep the public one. If it still fails, the domain itself is the problem.

### How long does NXDOMAIN take to clear after fixing DNS?

Usually minutes, not days. Resolvers cache a "does not exist" answer only for the negative TTL your zone's SOA record allows (RFC 2308), which is commonly between five minutes and an hour. Visitors whose resolver never cached the bad answer see the fix immediately. You can purge Cloudflare's and Google's public resolvers yourself at one.one.one.one/purge-cache and dns.google/cache. Only name-server changes at the registrar take longer: up to 24-48 hours of cached delegation.

### Does DNS_PROBE_FINISHED_NXDOMAIN mean the website is down?

No: it means the website's name could not be found, which is a different failure. The server may be running fine while the domain has expired, lost a DNS record or moved name servers; equally, the name may resolve perfectly for everyone else while your device's cache or DNS filter is wrong. A down server produces errors like ERR_CONNECTION_REFUSED or a timeout instead, because DNS answered and the connection then failed.