Fix DNS_PROBE_FINISHED_NXDOMAIN in Windows: Complete Troubleshooting Guide

The error code DNS_PROBE_FINISHED_NXDOMAIN is a frequent network connection error in Chromium-based browsers on Windows. When Google Chrome, Microsoft Edge, or Brave displays this page, the DNS subsystem concluded that the queried domain name does not exist.

The Protocol Anatomy of NXDOMAIN (RFC 1035 & RFC 2308)

Under RFC 1035, NXDOMAIN represents Response Code 3 (RCODE: 3), formally termed Non-Existent Domain. When a recursive resolver receives NXDOMAIN from the authoritative nameservers for a zone, it asserts authoritatively that neither an A, AAAA, CNAME, nor any other record exists for that domain label.

RFC 2308 specifies negative caching: resolvers cache that failure for the duration of the zone's SOA Minimum TTL. If you attempt to access a domain before its DNS records propagate, your computer or router caches the negative response, serving NXDOMAIN locally even after records go live globally.

The Windows Name Resolution Architecture

When an application requests a network socket, the Windows DNS Client service (Dnscache) executes resolution through a structured hierarchy:

1. Local Hosts File: Located at C:\Windows\System32\drivers\etc\hosts; overrides all network DNS lookups.
2. DNS Client Resolver Cache: The in-memory cache managed by the Dnscache service.
3. Configured Adapter Resolvers: Queries sent to DNS server addresses assigned via DHCP or static settings.
4. Link-Local Multicast Name Resolution (LLMNR): Multicast queries over UDP port 5355 for local subnet names.
5. NetBIOS Name Service (NBNS): Broadcast queries over UDP port 137 for legacy Windows networking.
6. Name Resolution Policy Table (NRPT): Directs queries for specific enterprise namespaces through VPN tunnels.

Step 1: Flush and Register the Windows DNS Resolver Cache

Clearing stale negative cache records from memory is the fastest initial fix. When you flush DNS, the Windows resolver drops all cached positive and negative resource records, forcing subsequent requests out to the upstream recursive resolver.

ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew

To inspect what Windows currently holds in memory before or after clearing, use ipconfig /displaydns. If the problematic domain is listed with a negative cache entry (Time To Live ticking down with no record data), /flushdns purges it instantly.

Step 2: Switch to Anycast Public DNS Resolvers

By default, home and office routers provide DNS server addresses via DHCP pointing back to the router itself (192.168.1.1) or local ISP nameservers. ISP resolvers frequently suffer from regional routing outages, aggressive negative caching, and restrictive content filtering that triggers false NXDOMAIN responses. Switching your network adapter to anycast public resolvers resolves this cleanly.

1. 1

   Launch Network Connections

   Press Windows Key + R, type ncpa.cpl, and hit Enter to open the network adapters panel.

2. 2

   Open Interface Properties

   Right-click your active network interface (Ethernet or Wi-Fi) and select Properties.

3. 3

   Configure IPv4 Resolvers

   Select Internet Protocol Version 4 (TCP/IPv4), click Properties, choose Use the following DNS server addresses, and enter 1.1.1.1 (Cloudflare Preferred) and 1.0.0.1 (Alternate), or 8.8.8.8 and 8.8.4.4 (Google).

4. 4

   Configure IPv6 Resolvers (Optional)

   If your network uses native IPv6, select Internet Protocol Version 6 (TCP/IPv6) and assign 2606:4700:4700::1111 and 2606:4700:4700::1001.

You can also configure DNS addresses directly from PowerShell running as Administrator:

Get-NetAdapter | Where-Object Status -eq "Up" | Set-DnsClientServerAddress -ServerAddresses ("1.1.1.1", "1.0.0.1")

Step 3: Clear Google Chrome's Internal Host Resolver Cache

Google Chrome and other Chromium browsers incorporate an internal asynchronous DNS client and maintain their own host resolver cache independent of the operating system. If Windows can resolve a domain in Command Prompt via ping or nslookup, but Chrome continues throwing DNS_PROBE_FINISHED_NXDOMAIN, Chrome's internal cache has retained the stale negative response.

• Open Google Chrome, type chrome://net-internals/#dns into the address bar, and press Enter.
• Click the Clear host cache button.
• Navigate to chrome://net-internals/#sockets in the address bar.
• Click Close idle sockets and Flush socket pools. This forces Chrome to terminate existing TCP connections and request fresh lookups.
• Navigate to Chrome Settings > Privacy and Security > Security > Use secure DNS. If enabled with an invalid custom provider, switch to 'With your current service provider' or choose Cloudflare / Google from the dropdown.

Step 4: Audit and Sanitize the Windows Hosts File

The Windows hosts file has higher resolution priority than any DNS server. If a developer or software application added a testing entry pointing a live domain to 127.0.0.1, 0.0.0.0, or a decommissioned staging server IP, browser connections will fail.

Open Notepad as Administrator, click File > Open, browse to C:\Windows\System32\drivers\etc\, select All Files, and open hosts. Inspect the file for custom entries. The default Windows hosts file contains only commented lines starting with #. If you see the failing domain listed, remove the entire line, save the file, and flush DNS.

Step 5: Reset Winsock Catalog and the TCP/IP Protocol Stack

Windows Sockets (Winsock) handles network input and output requests for internet applications. Virtual network adapters installed by VPN clients, proxy software, or third-party firewall utilities can inject Layered Service Providers (LSP) into the Winsock catalog. When corrupted, these drivers intercept DNS queries and silently return failure codes.

netsh winsock reset
netsh int ip reset
netsh branchcache reset

Executing netsh winsock reset cleans out third-party LSP shims and restores the default catalog state. You must reboot your computer after running this command for the changes to take effect.

Diagnostic Matrix: Root Cause vs Remediation

Check your result and continue troubleshooting

Use the dns lookup tool to inspect the public DNS data relevant to this guide. Record the hostname, query type, resolver and time so you can compare results after a change. This is a DNS check, not a guarantee of worldwide propagation or successful application delivery.

For the underlying behavior and current configuration guidance, consult the official reference. Provider dashboards can change; use the values shown for your own domain rather than copying an example into production.