How to Fix DNS_PROBE_FINISHED_NXDOMAIN: Domain and Browser Troubleshooting Steps

Overview

Here is the short version: NXDOMAIN usually means “this domain or record does not exist from the resolver’s point of view.” In practice, that can mean one of several things:

• The domain name was typed incorrectly.
• The DNS cache on your computer or browser is stale.
• Your network is using a resolver with outdated or broken cache.
• The domain has incorrect nameservers.
• The DNS records were deleted, not published correctly, or added in the wrong zone.
• The domain registration expired or DNS service was disconnected.
• A recent migration or DNS update has not fully propagated yet.

The fastest way to approach this error is to answer one question first: Is the problem only happening for me, or for everyone?

If only one browser, one device, or one network has the issue, start with local troubleshooting. If the domain fails everywhere, check the domain configuration itself.

A practical sequence looks like this:

1. Confirm the exact domain you are testing.
2. Try a different browser, device, or network.
3. Flush browser, system, and router DNS cache if needed.
4. Check whether the domain resolves publicly.
5. Verify registrar status, nameservers, and DNS zone records.
6. Confirm hosting target records are correct.
7. Wait if you recently changed DNS and the rest of the setup is correct.

This is different from HTTP errors like 404 or 500. Those happen after the browser reaches the server. NXDOMAIN happens before that point, while the browser is still trying to find where the domain lives on the internet. If the domain resolves but pages fail after that, a guide like How to Fix the WordPress 404 Error: Permalinks, .htaccess, and Server Checks may be more relevant.

Checklist by scenario

Use the checklist that matches your situation. Start with the smallest possible test before changing settings.

Scenario 1: You are a visitor and only this site is failing

1. Check for typos. Re-enter the domain carefully. Look for missing letters, wrong TLDs like .com instead of .net, or accidental spaces copied from a document or message.
2. Test the bare domain and the www version. Try both example.com and www.example.com. Sometimes only one hostname is configured.
3. Open the site in another browser. If it works elsewhere, clear the original browser’s cache and retry.
4. Use private/incognito mode. This quickly bypasses some browser caching and extension interference.
5. Disable DNS or privacy extensions temporarily. Ad blockers, security tools, VPN browser extensions, and custom DNS plugins can change resolution behavior.
6. Restart the browser. Simple, but often useful after DNS cache issues.
7. Restart your device. This can clear temporary resolver and network state.
8. Try another network. Switch from office Wi-Fi to mobile data, or from home Wi-Fi to a hotspot. If the site works on another network, the issue is likely your local resolver or router.

Scenario 2: You are a visitor and multiple sites are failing with DNS errors

1. Check whether your internet connection is actually working. If only some domains fail while apps still connect, DNS is still a likely cause.
2. Restart your router. Home and small office routers sometimes hold stale DNS state longer than expected.
3. Flush your local DNS cache. The exact command depends on your operating system, so use the one appropriate for your device and version.
4. Renew your network settings if needed. Reconnect to Wi-Fi, disable and re-enable the network adapter, or restart the device.
5. Test with a different DNS resolver. If your network is using a misbehaving ISP resolver, switching to a known public resolver can help confirm the cause. Make the change carefully and document the old setting first.
6. Check for VPN or secure DNS conflicts. Corporate VPNs, endpoint protection tools, and encrypted DNS settings can create inconsistent results across apps and browsers.

Scenario 3: You own the domain and the site stopped resolving after a DNS or hosting change

1. Confirm the domain is active at the registrar. Make sure it is not expired, on hold, or using parked nameservers unexpectedly.
2. Check the nameservers first. If nameservers are wrong, nothing in the zone editor matters until that is fixed.
3. Verify you are editing the correct DNS zone. This is a very common problem after moving DNS from a registrar to a hosting provider or CDN.
4. Inspect the required records. For the root domain, confirm the A or AAAA record points to the correct destination. For subdomains, confirm the CNAME or other appropriate record is correct.
5. Check whether records were accidentally removed. A missing root A record or missing www record can produce NXDOMAIN for one hostname while the other still works.
6. Look for conflicts. A hostname should not usually have both a conflicting CNAME and other record types at the same name.
7. Review recent migrations. If you just changed hosting, compare the old and new DNS targets carefully. During migration, this often pairs with broader operational tasks, so review a process like How to Migrate a WordPress Site to a New Host Without Downtime.
8. Wait for propagation if the setup is now correct. DNS changes can take time to appear consistently across networks.

Scenario 4: Only one hostname fails, such as www, a subdomain, or mail-related records

1. Identify exactly which hostname is failing. Root domain, www, blog subdomain, shop subdomain, and API subdomain can all have separate records.
2. Check the record for that hostname only. For example, www.example.com may need a CNAME pointing to the root or to a platform target.
3. Compare working and non-working hostnames. If the root domain resolves but www returns NXDOMAIN, the fix is usually missing or incorrect www DNS.
4. Check whether the subdomain exists in the right zone. If you use delegated subdomains or third-party DNS providers, make sure you did not add the record in the wrong control panel.
5. Review architecture decisions. If you are uncertain whether a section of your site should be a subdomain or subdirectory, see Subdomain vs Subdirectory for SEO and Site Structure: When to Use Each.

Scenario 5: The domain resolves for some people but not others

1. Assume caching until proven otherwise. Mixed results often point to propagation or resolver cache differences.
2. Test from multiple locations. Use colleagues, another device, or another network to compare behavior.
3. Check the TTL and recent change history. If records were changed recently, some resolvers may still be serving old information.
4. Avoid making repeated changes too quickly. Rapid edits can create confusion about which record set is actually being served.
5. Document the exact current intended state. Write down the correct nameservers and records before troubleshooting further.

What to double-check

This section is the core of a reliable DNS_PROBE_FINISHED_NXDOMAIN fix process. Before you make another change, verify each of these points carefully.

1. Domain registration status

Start at the registrar. If the domain registration expired, is suspended, or is under a hold status, the rest of the DNS checks may be secondary. Make sure auto-renew settings, billing, and contact verification are all in order.

2. Nameservers

Nameservers determine where the internet looks for the domain’s DNS records. If the domain is pointing to the wrong nameservers, you may be editing a perfectly valid zone in the wrong place. This is one of the most common causes of “I added the record, but nothing changed.”

A simple rule: check nameservers before checking records.

3. The active DNS provider

Many domains can be managed from more than one interface: registrar DNS, hosting DNS, CDN DNS, managed DNS platform, or cloud provider DNS. Only one authoritative source is active at a time for a given zone. Confirm which system is authoritative before editing anything.

4. Root and www records

Make sure both expected entry points are covered:

• example.com
• www.example.com

It is common to configure one and forget the other. That leads users to think the whole site is down when only one hostname is missing.

5. Subdomain records

If only a blog, shop, API, staging site, or other subdomain fails, inspect just that hostname. Be careful with staging environments and temporary deployments. If you regularly test site changes, it helps to keep a documented workflow similar to How to Create a Staging Site for WordPress and Test Changes Safely.

6. Recent platform changes

Ask what changed in the last 24 to 72 hours:

• New hosting provider
• Registrar transfer
• CDN or proxy enabled
• SSL setup
• WordPress migration
• Subdomain added
• DNS cleanup

DNS problems often appear immediately after a legitimate infrastructure change. If you enabled HTTPS and now have browser warnings after the domain resolves again, continue with How to Set Up SSL Certificates: HTTPS Installation and Common Fixes or How to Fix Mixed Content Errors After Enabling HTTPS.

7. Browser-level behavior

If the domain resolves in one browser but not another, inspect browser settings before touching DNS. Secure DNS settings, cached host resolution, extensions, and profile-specific configuration can all matter. For deeper browser-side diagnosis, How to Use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors is useful after the domain starts resolving but site assets still fail.

8. Hosting destination

Confirm the target IP address, canonical hostname, or provider-specific DNS target from your host’s dashboard. Do not rely on memory or old notes. If you are evaluating whether the problem may actually be a hosting mismatch, compare your current setup against the requirements in How to Choose Web Hosting for a Small Website: Shared, VPS, Cloud, and Managed Options.

9. Local overrides

On developer machines and managed corporate devices, check for local host file entries, internal DNS overrides, VPN split tunneling, or endpoint security tools that change resolution behavior. These can make a domain look broken on one machine while working everywhere else.

Common mistakes

Most NXDOMAIN issues are not mysterious. They usually come from a small set of avoidable mistakes.

• Editing records in the wrong DNS panel. This happens constantly when nameservers were moved but old DNS controls are still visible.
• Forgetting the www record. The root domain works, but users visit www and get NXDOMAIN.
• Changing nameservers and records at the same time without documenting the plan. That makes rollback and diagnosis harder.
• Assuming propagation is the problem before verifying the record is correct. Waiting does not fix a typo.
• Deleting old records too early during migration. Temporary overlap is often safer than aggressive cleanup.
• Testing from only one browser or one network. You need at least one comparison point.
• Ignoring subdomains. The main site may work while API, CDN, mail, or staging hostnames fail.
• Confusing DNS errors with web server errors. If the domain resolves and then returns a page-level error, the troubleshooting path changes. For WordPress-specific failures after resolution, see WordPress White Screen of Death Fix Guide: Causes, Recovery Steps, and Prevention.

A good habit is to make one change at a time, write down what you changed, and re-test from more than one environment. DNS troubleshooting gets messy when you are guessing across multiple dashboards.

When to revisit

This is worth revisiting any time your domain setup changes, even if everything appears to be working now. A small DNS mistake can stay hidden until caches expire or traffic shifts to a different hostname.

Come back to this checklist when you:

• change hosting providers
• move DNS to a new provider
• transfer a domain to another registrar
• launch a new subdomain or staging site
• enable a CDN, proxy, or security layer
• set up SSL or redirect rules
• clean up old records after a migration
• notice users in one region reporting access problems

For a practical maintenance routine, keep a small DNS reference for each domain you manage:

1. Registrar name
2. Authoritative nameservers
3. DNS hosting platform
4. Required root and www records
5. Critical subdomains
6. Hosting destination details
7. Date of the last DNS change

That one-page record makes future NXDOMAIN troubleshooting much faster.

If you need a final action plan, use this condensed version before making any urgent DNS change:

1. Confirm whether the issue is local or global.
2. Check the exact hostname that fails.
3. Verify registration and nameservers.
4. Confirm you are editing the authoritative DNS zone.
5. Review root, www, and subdomain records.
6. Compare the intended target with your host or platform settings.
7. Test from another browser, device, and network.
8. Wait only after you know the configuration is correct.

That sequence will solve or narrow down most domain not resolving cases without unnecessary changes. And because DNS issues often show up around migrations, launches, and infrastructure cleanup, it is a checklist worth keeping bookmarked.