How to Fix DNS_PROBE_FINISHED_NXDOMAIN

DNS_PROBE_FINISHED_NXDOMAIN means a DNS resolver could not find the hostname your browser requested. This guide shows how to tell whether the problem is on your device, network or domain, then gives the correct fix for each case.

What the error means

DNS is the system that matches a name such as example.com to the address of the server hosting it. Your browser needs that answer before it can request a web page.

NXDOMAIN is short for “non-existent domain”. The resolver has completed the lookup and is saying that the requested name does not exist in DNS. That does not automatically mean the web server is down: the browser may have a typo, your local resolver may have a stale negative answer, or the domain may genuinely have no usable DNS delegation or record. Cloudflare’s DNS explanation describes the same distinction.

The exact fix depends on the scope of the failure:

What you observe	Most likely area to check
Only one laptop or phone fails	Device, browser or local DNS cache
Everyone on one Wi-Fi network fails	Router or internet-service-provider resolver
The domain fails on mobile data and other networks	Domain registration, nameservers or DNS records
The bare domain works but www fails	Missing or incorrect www record
It started after a domain or nameserver change	DNS propagation and cached answers

What you need before starting

You need the exact hostname that fails, access to the affected device and, if it is your website, access to the domain registrar or DNS provider. Note whether the failing address is the root domain (example.com), www (www.example.com) or another subdomain.

If you manage the domain at HostKarle, the WHOIS lookup tool can help you check the domain before you change any records. If the name is not registered yet, you can search a domain on HostKarle; the domain-search product starts from ₹709/yr (per year).

Step 1: Check whether the failure is local or global

Why this helps: it stops you from changing a working domain when the problem is only a stale answer on one device.

1. Check the spelling and extension in the address bar. Look for a missing letter, an extra hyphen, or .co.in typed as .com.
2. Open the same hostname in another browser on the same device.
3. Test it from another connection, such as mobile data instead of your home Wi-Fi. If possible, ask someone on a different network to open it.
4. From a terminal or Command Prompt, run a lookup for the exact hostname:

nslookup example.com
nslookup www.example.com

Replace both examples with the hostname that fails. If the lookup works on another network but not yours, continue with Steps 2 and 3. If every network returns that the name does not exist, skip to Step 4 because the domain owner needs to correct DNS.

What success looks like: the domain resolves on at least one independent network, or you have confirmed that the same hostname fails everywhere.

Step 2: Try the quick visitor fixes

Why this helps: a typo, VPN, browser setting or router cache can produce a name-resolution failure without any problem in the website itself.

1. Close the tab and type the address again instead of opening an old bookmark.
2. Restart the browser. If the error appears in every browser, restart the device.
3. Temporarily disconnect a VPN, proxy or DNS-filtering application, then test again. Re-enable it after the test if you need it for work or security.
4. Restart your router if every device on the same Wi-Fi connection fails but mobile data works.
5. In Chrome, open Settings → Privacy and security → Security and review Use secure DNS. Chrome says that a custom secure-DNS provider can show name-lookup errors; try the current service provider or temporarily turn the setting off for a controlled test. Its official secure-DNS instructions show the current menu path.

What success looks like: the page opens in the same browser after the address, network or DNS setting is corrected.

Step 3: Flush DNS and test another resolver

Why this helps: your device or internet provider may be holding a failed DNS answer, while another resolver already has the correct answer.

Windows

Open Command Prompt as administrator and run:

ipconfig /flushdns
nslookup example.com
nslookup example.com 8.8.8.8

The first command clears the Windows DNS client cache. The second lookup uses your normal resolver; the third asks Google Public DNS directly. Google documents 8.8.8.8 and 8.8.4.4 as its IPv4 resolver addresses. Do not change the DNS setting permanently just because one test works; first compare the results.

macOS

Open Terminal and run the following common cache-clearing command for current macOS versions, then test the name:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
dig example.com
dig example.com @8.8.8.8

The cache-clear commands normally produce no success message. The useful result is the lookup: an address record from the normal resolver or from 8.8.8.8.

Linux

On a distribution using systemd-resolved, run:

sudo resolvectl flush-caches
resolvectl query example.com
resolvectl query example.com --cache=no

If your distribution uses a different DNS service, use its documented cache command. You can also compare with:

dig example.com
dig example.com @8.8.8.8

What success looks like: the cache is cleared and the public-resolver lookup returns an address while your normal resolver does not. That points to the device, router or ISP resolver rather than the website’s hosting server.

Step 4: Check the domain if you own the website

Why this helps: an expired or inactive domain cannot resolve correctly until its registration and delegation are restored.

1. Check the domain’s spelling and extension in your registrar account.
2. Check its expiry date, status and listed nameservers in the registrar dashboard or an RDAP lookup. ICANN Lookup displays registration dates, domain status and nameserver information for domains where the registry data is available.
3. Confirm that the domain is paid for and active. When a domain expires, its DNS resolution path can be interrupted, so the website and email may stop working; ICANN explains this in its guidance on renewed expired domains.
4. Check the apex domain and www separately. A record for example.com does not automatically guarantee that www.example.com has a record.

If you have just bought a domain, make sure the registration completed and that you are editing the DNS zone belonging to that domain. If the name is available rather than registered, there is no website DNS to repair yet; buying a cheap domain in India explains the registration decision separately.

What success looks like: the domain is active, the expiry date is in the future, and you know which provider controls its authoritative nameservers.

Step 5: Check nameservers and DNS records

Why this helps: the registrar delegation tells the internet where to ask for the domain’s records; the zone then needs a record for each hostname visitors use.

Run these checks, replacing example.com with your domain:

nslookup -type=ns example.com
nslookup example.com 8.8.8.8
nslookup www.example.com 1.1.1.1

For a more detailed result on macOS or Linux:

dig +short NS example.com
dig +short A example.com @8.8.8.8
dig +short A www.example.com @1.1.1.1

Check the results against the DNS provider’s instructions:

• The nameservers at the registrar must be the nameservers you intend to use. If you are pointing an existing domain to HostKarle hosting, the nameservers are ns1.fastnsdns.com and ns2.fastnsdns.com. See how to find and update HostKarle nameservers for the change process.
• The apex domain usually needs an A or AAAA record pointing to the web server, or the record arrangement specified by your DNS provider.
• www needs its own A or AAAA record, or a CNAME pointing to the intended hostname.
• Do not delete MX records while fixing a website. They control mail delivery, not the web page, and removing them can interrupt business email.
• If you use a third-party DNS service, edit the records there rather than in an old hosting panel that is no longer authoritative.

If both the apex and www return NXDOMAIN, start with nameserver delegation and the zone itself. If only www fails, inspect the www record first. If DNS returns an IP address but the page times out, the problem has moved beyond NXDOMAIN and needs hosting or network troubleshooting.

What success looks like: public resolvers return the expected nameservers and an address for every hostname you publish, including www if you use it.

Step 6: Allow propagation, then verify from more than one network

Why this helps: DNS answers are cached, so a correct change may not appear everywhere at the same moment.

After changing nameservers or records, check the result with both nslookup and dig from more than one resolver. A record’s TTL controls how long resolvers can cache it; a previously negative answer can also remain cached until its negative-cache period ends. This is why a correct change can take longer than one browser refresh.

Many record changes appear within minutes, but nameserver changes can take longer and may take up to 48 hours to be seen consistently. Keep the old DNS or hosting service available during a planned move, and do not make several unrelated DNS changes at once.

Use this verification list:

1. Query the apex domain with your normal resolver.
2. Query it with a second public resolver such as 8.8.8.8.
3. Query www and any important subdomain separately.
4. Open the site on Wi-Fi and mobile data.
5. Test HTTPS, the WordPress login, contact forms and business email after the web address resolves.

What success looks like: the same expected record is returned from independent resolvers and the website opens from different connections.

Troubleshooting when NXDOMAIN continues

Result	Next action
Normal resolver fails, 8.8.8.8 succeeds	Flush the local cache, restart the router, or review the ISP DNS setting.
Both resolvers fail for the apex	Check expiry, nameservers and whether the DNS zone exists.
Apex succeeds, www fails	Add or correct the www A, AAAA or CNAME record.
DNS returns an IP, but the browser cannot connect	Investigate hosting, firewall, HTTPS or the network; it is no longer an NXDOMAIN-only problem.
Only a recently changed domain fails	Check the change at the registrar and allow cached answers to expire.
Website works but email stopped after the change	Restore the correct MX and related mail records before changing anything else.

Avoid repeatedly switching between DNS providers without recording the current records. Before a nameserver change, save the A, AAAA, CNAME, MX, TXT and any verification records you still need.

FAQ

Is DNS_PROBE_FINISHED_NXDOMAIN a problem with my computer?

It can be, but not always. If the site opens on mobile data or through another resolver, your device, router or ISP resolver is the likely cause. If it fails on several independent networks, check the domain registration, nameservers and records instead.

How do I fix DNS_PROBE_FINISHED_NXDOMAIN in Chrome?

Check the URL, restart Chrome, review Use secure DNS, then flush the operating-system DNS cache. Compare the result with nslookup example.com 8.8.8.8; if public DNS also returns NXDOMAIN, the fix belongs to the domain owner rather than Chrome.

Does changing DNS to 8.8.8.8 fix the website?

It can bypass a stale or incorrect resolver answer on your network, but it cannot create missing DNS records for a domain. If multiple resolvers return NXDOMAIN, correct the domain’s nameservers or zone records first.

How long does DNS_PROBE_FINISHED_NXDOMAIN take to go away after changing nameservers?

There is no single time for every domain. Record TTLs and cached negative answers affect the result, and nameserver changes can take up to 48 hours to appear consistently; verify from more than one network during that period.

Why does my domain work but www does not?

The two hostnames are separate DNS names. Add a correct www A, AAAA or CNAME record at the authoritative DNS provider, then wait for cached answers to expire and test both names independently.

DONE dns-probe-finished-nxdomain words=1900

{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Is DNS_PROBE_FINISHED_NXDOMAIN a problem with my computer?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “It can be, but not always. If the site opens on mobile data or through another resolver, your device, router or ISP resolver is the likely cause. If it fails on several independent networks, check the domain registration, nameservers and records instead.”}}, {“@type”: “Question”, “name”: “How do I fix DNS_PROBE_FINISHED_NXDOMAIN in Chrome?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Check the URL, restart Chrome, review Use secure DNS, then flush the operating-system DNS cache. Compare the result with nslookup example.com 8.8.8.8; if public DNS also returns NXDOMAIN, the fix belongs to the domain owner rather than Chrome.”}}, {“@type”: “Question”, “name”: “Does changing DNS to 8.8.8.8 fix the website?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “It can bypass a stale or incorrect resolver answer on your network, but it cannot create missing DNS records for a domain. If multiple resolvers return NXDOMAIN, correct the domain’s nameservers or zone records first.”}}, {“@type”: “Question”, “name”: “How long does DNS_PROBE_FINISHED_NXDOMAIN take to go away after changing nameservers?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “There is no single time for every domain. Record TTLs and cached negative answers affect the result, and nameserver changes can take up to 48 hours to appear consistently; verify from more than one network during that period.”}}, {“@type”: “Question”, “name”: “Why does my domain work but www does not?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “The two hostnames are separate DNS names. Add a correct www A, AAAA or CNAME record at the authoritative DNS provider, then wait for cached answers to expire and test both names independently. DONE dns-probe-finished-nxdomain words=1900”}}]}