Interactive Troubleshooter

Published: Sep 2, 2026

Updated: Oct 8, 2026

DNS_PROBE_FINISHED_NXDOMAIN Chrome Error - DNS & Hosts File Tree

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

This interactive diagnostic decision tree resolves the DNS_PROBE_FINISHED_NXDOMAIN error in Google Chrome and Chromium-based browsers. It systematically diagnoses non-existent domain (NXDOMAIN) lookup failures caused by stale OS/browser DNS caches, corrupted local hosts files, misconfigured upstream DNS resolvers, and rogue network filter drivers.

Full Diagnostic Tree & Step-by-Step Overview

What scope and pattern of domain resolution failure triggers the DNS_PROBE_FINISHED_NXDOMAIN error?

Error occurs exclusively on a single specific website, while all other domains load normally in Chrome.
Error affects ALL websites across Chrome and other browsers, but IP addresses (e.g., 1.1.1.1) respond to ping commands.
Error appears intermitted or occurs only when connected to specific Wi-Fi networks, VPNs, or proxy connections.
Error is accompanied by Chrome flags warnings, DNS over HTTPS (DoH) failures, or web filter security blocks.

What specific local configuration or domain record anomaly is isolating the resolution failure to one website?

Local OS `hosts` file contains an outdated or corrupted IP mapping for the requested domain string.
Chrome internal host resolver cache (`net-internals`) or socket pool retains a stale negative cache entry.
Domain Name System (DNS) authoritative nameservers for the target site are misconfigured or missing `A`/`AAAA` records.
Local DNS client service cache in the operating system has stored a negative cache response (NXDOMAIN TTL).

Auditing and Restoring Factory Defaults in the Operating System Hosts File

Solution:

Root Cause: Invalid Local Domain Mapping in OS Hosts File

The operating system evaluates the local hosts file (C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Unix/macOS) before issuing external DNS queries. If an entry maps a target domain (e.g., example.com) to an invalid IP, 0.0.0.0, or 127.0.0.1, the OS bypasses public DNS servers entirely and returns a Non-Existent Domain (NXDOMAIN) or immediate connection failure in Chrome.

Diagnostic Verification:

Open PowerShell as Administrator and query the hosts file for the target domain:

Get-Content -Path "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String "example.com"

Observe if an active, uncommented mapping line targets the domain.

Step-by-Step Fix:

1.Open Hosts File in Administrative Notepad:

Press Win + S, type Notepad, right-click and select Run as administrator.

Click File > Open, navigate to C:\Windows\System32\drivers\etc\ (select All Files (*.*) in the file type dropdown), and open hosts.

2.Purge Stale Domain Mappings:

Locate any lines containing the problematic domain string.

Delete those lines entirely or place a # character at the beginning of the line to convert it into a comment.

3.Save and Flush Caches:

Save the file (Ctrl + S).

Open Command Prompt as Administrator and flush the local cache:

ipconfig /flushdns

Prevention & Long-Term Monitoring:

Avoid using third-party software or unverified ad-blocking scripts that automatically append thousands of unmanaged domain rules to your local hosts file.

Clearing Google Chrome Internal Host Cache and Flushing Socket Pools

Solution:

Root Cause: Stale Internal Chromium Host Resolver and Socket Cache

Google Chrome features an internal asynchronous DNS client and socket pooling mechanism independent of the operating system DNS resolver. If a domain brief lookup failure occurs (e.g., during a momentary router drop), Chrome caches the negative NXDOMAIN result internally. Subsequent requests hit Chrome's internal cache, preventing new outbound DNS lookups even after the network recovers.

Diagnostic Verification:

Open Chrome and navigate to chrome://net-internals/#dns.

Search for the target domain in the Host resolver cache table to confirm if an active entry exists with an error status.

Step-by-Step Fix:

1.Clear Chrome DNS Host Cache:

Type chrome://net-internals/#dns in the Chrome address bar and press Enter.

Click the Clear host cache button.

2.Flush Chrome Socket Pools:

Navigate to chrome://net-internals/#sockets in the address bar.

Click Close idle sockets and then Flush socket pools.

3.Clear Browsing Data and Restart Chrome:

Press Ctrl + Shift + Delete in Chrome.

Set Time range to All time, check Cached images and files, and click Clear data.

Relaunch Chrome.

Prevention & Long-Term Monitoring:

Disable aggressive preloading features under chrome://settings/cookies if transient network drops frequently corrupt browser socket caches.

Verifying External Authoritative DNS Records and Nameserver Propagation

Solution:

Root Cause: Authoritative DNS Zone File Misconfiguration or Domain Expiration

When a domain's authoritative nameservers fail to return an A (IPv4) or AAAA (IPv6) record for a given hostname, recursive DNS resolvers return an explicit NXDOMAIN (RCODE 3) error code. This indicates that the domain name does not exist in the public Domain Name System hierarchy, or that its WHOIS registration has expired and entered a Redemption Period.

Diagnostic Verification:

Open Command Prompt and query public DNS resolvers directly using nslookup:

nslookup -type=A targetdomain.com 1.1.1.1
nslookup -type=NS targetdomain.com 8.8.8.8

If public resolvers like Cloudflare (1.1.1.1) and Google (8.8.8.8) both return *** 1.1.1.1 can't find targetdomain.com: Non-existent domain, the issue originates at the domain's DNS registrar or authoritative zone file.

Step-by-Step Fix:

1.Inspect WHOIS Registration Status:

Query WHOIS records using a reliable registrar tool or terminal command to verify that the domain status is ok or active and not clientHold or expired.

2.Correct Authoritative DNS Zone Records (Domain Administrators):

Log into your domain registrar/DNS hosting panel (e.g., Cloudflare, Route53, GoDaddy).

Ensure a valid A Record exists for @ and www pointing to the correct web server IPv4 address.

3.Allow Propagation Time:

If nameservers were recently updated, allow 24 to 48 hours for global DNS propagation across recursive resolvers.

Prevention & Long-Term Monitoring:

Enable auto-renewal on domain registrations and monitor DNS zone record TTLs.

Purging Windows OS Local DNS Resolver Cache via Command Line

Solution:

Root Cause: Corrupted Operating System DNS Resolver Memory Cache

The Windows DNS Client service (dnscache) caches both successful name resolutions and negative responses (NXDOMAIN errors). If an initial lookup fails due to a momentary connection glitch, the OS stores this negative result for the duration of the Negative Cache Time-To-Live (TTL) parameter, forcing all system applications to return DNS_PROBE_FINISHED_NXDOMAIN.

Diagnostic Verification:

Open Command Prompt as Administrator and query the local resolver cache:

ipconfig /displaydns

Review the output for the target domain name and check if the Record Name lists a negative response entry.

Step-by-Step Fix:

1.Execute Complete OS DNS Cache Flush:

Open Command Prompt as Administrator and execute:

ipconfig /flushdns

2.Clear NetBIOS and Name Resolution Registers:

Run the following commands in sequence:

nbtstat -R
nbtstat -RR

3.Restart the Windows DNS Client Service (if service permits):

In administrative PowerShell, run:

Restart-Service -Name "Dnscache" -Force -ErrorAction SilentlyContinue

Prevention & Long-Term Monitoring:

Execute ipconfig /flushdns whenever network gateways or DNS server settings are altered.

What upstream network layer or resolver configuration is blocking ALL domain lookups?

Local network adapter is assigned an unresponsive or dead ISP/router DNS server address.
Windows Sockets (Winsock) catalog or TCP/IP protocol stack configuration is corrupted.
Local DNS Client Service (`dnscache`) is frozen, disabled, or failing system RPC calls.
Router/Gateway DNS forwarder daemon has crashed or dropped WAN recursive queries.

Configuring Public High-Performance DNS Resolvers (Cloudflare / Google)

Solution:

Root Cause: Failure of Default ISP Recursive DNS Resolvers

By default, devices receive DNS server addresses automatically via DHCP from the local router, which forwards queries to the Internet Service Provider's (ISP) recursive DNS servers. If the ISP's DNS infrastructure experiences an outage, high latency, or packet loss, the host network adapter receives no response or time-out errors for name queries, causing Chrome to display DNS_PROBE_FINISHED_NXDOMAIN for every domain.

Diagnostic Verification:

Open Command Prompt and test raw IP connectivity versus DNS lookup:

ping 1.1.1.1 *(Succeeds with 0% packet loss)*
nslookup google.com *(Times out or fails to reach default gateway server)*

Step-by-Step Fix:

1.Open Network Connections GUI:

Press Win + R, type ncpa.cpl, and hit Enter.

2.Configure IPv4 Public DNS Settings:

Right-click your active network adapter (Wi-Fi or Ethernet) > Properties.

Select Internet Protocol Version 4 (TCP/IPv4) > click Properties.

Select Use the following DNS server addresses:

Preferred DNS server: 1.1.1.1 (Cloudflare)

Alternate DNS server: 8.8.8.8 (Google)

3.Configure IPv6 Public DNS Settings (If IPv6 is Active):

Select Internet Protocol Version 6 (TCP/IPv6) > click Properties.

Set Preferred to 2606:4700:4700::1111 and Alternate to 2001:4860:4860::8888.

4.Flush Cache and Apply:

Click OK, open Command Prompt, and run ipconfig /flushdns.

Prevention & Long-Term Monitoring:

Review guidelines in the Microsoft Official Support Guide regarding enterprise TCP/IP stack parameters and custom DNS assignment rules.

Performing Complete Winsock Catalog and TCP/IP Protocol Stack Reset

Solution:

Root Cause: Windows Sockets (Winsock) Catalog and IP Stack Corruption

Windows Sockets (Winsock) manages network I/O requests for applications. Improper network driver updates, abrupt system shutdowns, or third-party software uninstalls can corrupt Winsock Layered Service Providers (LSP) or TCP/IP registry keys. This breaks the socket abstraction layer required for Chrome to send UDP/TCP port 53 DNS payloads.

Diagnostic Verification:

Open Command Prompt as Administrator and run:

netsh winsock show catalog

Observe if command returns errors or missing socket provider entries.

Step-by-Step Fix:

1.Reset Winsock Catalog:

Open Command Prompt as Administrator and run:

netsh winsock reset

2.Reset TCP/IP Stack Configuration:

Execute the following command to rewrite TCP/IP registry keys:

netsh int ip reset c:\resetlog.txt

3.Clear Interface IP Leases:

Execute command sequence:

ipconfig /release
ipconfig /renew
ipconfig /flushdns

4.Restart Computer:

Reboot the system to re-initialize core kernel networking socket drivers.

Prevention & Long-Term Monitoring:

Avoid installing untrusted network optimizer tools or VPN software that inject non-standard LSPs into the network stack.

Restarting and Re-enabling the Windows DNS Client Service

Solution:

Root Cause: Windows DNS Client (`dnscache`) Service Stall or RPC Failure

The Windows DNS Client service (dnscache) runs as an integral system service under svchost.exe. If the service stalls due to resource exhaustion, thread lockups, or corrupted memory handles, system applications (including Chrome) fail to resolve hostnames and fall back to error state flags.

Diagnostic Verification:

Open PowerShell as Administrator and query the service status:

Get-Service -Name "Dnscache"

Check if Status is Stopped or if the process fails to respond to RPC queries.

Step-by-Step Fix:

1.Restart DNS Client via PowerShell (Administrative Privileges Required):

Run administrative PowerShell:

Restart-Service -Name "Dnscache" -Force

2.Re-enable Automatic Startup via Windows Registry (If Service is Disabled):

If the service is disabled and greyed out in services.msc, open regedit as Administrator and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache

Double-click Start DWORD and set its value to 2 (Automatic).

3.Reboot the computer to re-initialize the service under system privileges.

Prevention & Long-Term Monitoring:

Ensure system memory and svchost.exe handle limits are kept within normal operating parameters.

Power-Cycling Local Router/Gateway and Purging DNS Proxy Daemons

Solution:

Root Cause: Router Embedded DNS Proxy/Dnsmasq Daemon Crash

Consumer routers run embedded Linux-based DNS proxy daemons (such as dnsmasq or named) to forward DNS requests from local LAN clients to ISP upstream servers. Heavy concurrent connections, memory leaks, or firmware bugs can cause the proxy daemon to crash while leaving Layer 2/3 IP routing active. As a result, pings to IP addresses succeed, but all domain resolution requests fail with DNS_PROBE_FINISHED_NXDOMAIN.

Diagnostic Verification:

Log into your router's administrative web console (e.g., 192.168.1.1 or 192.168.0.1).

Check the system status log for dnsmasq or DNS server crash/timeout entries.

Step-by-Step Fix:

1.Hard Power-Cycle the Router/Modem:

Disconnect the power cable from the router and modem.

Wait 30 to 60 seconds to fully discharge internal capacitors.

Reconnect the power cable and allow 2 to 3 minutes for full boot and WAN negotiation.

2.Update Router Firmware:

Access the router administrator panel, navigate to System Settings > Firmware Update, and install the latest vendor release.

3.Enable DNS Forwarding / DoH Bypass on Router:

If available, toggle 'DNS Proxy' to disabled or set static WAN DNS servers (e.g., 1.1.1.1) directly in the router's WAN configuration.

Prevention & Long-Term Monitoring:

Keep router firmware updated to prevent buffer overflow vulnerabilities in embedded DNS software.

What secondary network interface, tunnel, or filter is interfering with DNS packet routing?

Active Virtual Private Network (VPN) client or stale TAP/TUN adapter is misrouting DNS queries.
System HTTP/SOCKS Proxy server setting is intercepting domain lookup requests.
Third-party Antivirus / Firewall Web Protection module is dropping outbound UDP/TCP port 53 packets.
Wi-Fi access point captive portal redirect loop is blocking unauthenticated DNS traffic.

Re-configuring VPN DNS Leak Protection and Rebuilding TAP/TUN Adapters

Solution:

Root Cause: VPN DNS Leak Protection and Split-Tunnel Routing Collisions

VPN applications utilize virtual TAP/TUN network interfaces and install custom kernel drivers to force all DNS traffic through encrypted tunnels. If the VPN client disconnects abruptly, crashes, or experiences split-tunnel misconfigurations, the virtual DNS routing rules remain locked while the tunnel closes. The system attempts to route DNS queries through a dead virtual interface, blocking all domain lookups.

Diagnostic Verification:

Open PowerShell and check active network interfaces and route metrics:

Get-NetAdapter | Where-Object { $_.Status -eq "Up" }
Get-DnsClientServerAddress

Observe if a disconnected VPN TAP adapter remains assigned as the primary DNS server.

Step-by-Step Fix:

1.Disconnect and Reset VPN Client State:

Open your VPN application, disconnect from any active servers, and fully exit the app.

2.Flush Dynamic Interface Rules:

Open administrative Command Prompt and run:

netsh interface ip reset
ipconfig /flushdns

3.Disable Stale Virtual Adapters in Control Panel:

Open ncpa.cpl > locate any leftover TAP/TUN virtual adapters (e.g., *TAP-Windows Adapter V9*, *NordLynx*) > right-click and select Disable.

Prevention & Long-Term Monitoring:

Enable 'Kill Switch' and 'Auto-Connect' features inside your VPN software to ensure clean interface tear-down on disconnect.

Resetting System-Wide HTTP/SOCKS Proxy Settings and WinHTTP Configuration

Solution:

Root Cause: Stale System Proxy Server Redirection

If a proxy server configured in Windows or Chrome is offline, misconfigured, or left behind by removed security tools, all outbound web traffic (including proxy-managed DNS lookups) fails. Chrome inherits the system proxy settings by default, leading to connection failures and DNS probe errors.

Diagnostic Verification:

Open Command Prompt as Administrator and check system WinHTTP proxy settings:

netsh winhttp show proxy

Check if an active proxy server IP/port is set.

Step-by-Step Fix:

1.Reset WinHTTP Proxy Configuration:

Open Command Prompt as Administrator and run:

netsh winhttp reset proxy

2.Disable User-Level LAN Proxy via Internet Options:

Press Win + R, type inetcpl.cpl, and hit Enter.

Go to the Connections tab > click LAN settings.

Uncheck Use a proxy server for your LAN.

Check Automatically detect settings.

Click OK > Apply.

3.Verify Chrome Proxy Flags:

In Chrome, open chrome://settings/system > ensure Open your computer's proxy settings reflects the updated configuration.

Prevention & Long-Term Monitoring:

Periodically audit network settings after removing web security extensions or proxy tools.

Disabling Antivirus Web Shield and NDIS Lightweight Filter Drivers

Solution:

Root Cause: Third-Party Security Filter Driver Interception

Antivirus suites (e.g., Avast, AVG, Bitdefender) install NDIS Lightweight Filter (LWF) drivers into the OS network stack to perform real-time web filtering and SSL inspection. If the security software's local filtering engine corrupts its internal rule definitions, it may classify legitimate outbound DNS requests (UDP/TCP port 53) as malicious, dropping the packets silently.

Diagnostic Verification:

Open ncpa.cpl > right-click your active network adapter > Properties.

Inspect the list under *This connection uses the following items* for non-Microsoft items (e.g., *AVG Network Filter Driver*).

Step-by-Step Fix:

1.Temporarily Disable Web Shield Features:

Open your antivirus application and disable features labeled Web Shield, DNS Shield, or Real-Time Protection.

2.Unbind Security Filter Drivers from Adapter:

Open ncpa.cpl > right-click active adapter > Properties.

Uncheck the box next to any third-party antivirus filter driver listed.

Click OK and test domain resolution in Chrome.

3.Reinstall or Update Security Suite:

If the filter driver was the cause, update the security application to the latest version or perform a clean reinstall.

Prevention & Long-Term Monitoring:

Use native Windows Defender Security tools to avoid third-party NDIS stack driver conflicts.

Triggering Captive Portal Authentication on Public and Guest Networks

Solution:

Root Cause: Unauthenticated State on Captive Portal Networks

Public Wi-Fi networks (hotels, airports, coffee shops) restrict outbound internet access—including DNS resolution—until the device completes a web-based authentication or terms-of-service agreement. If Chrome attempts to load HTTPS websites before authentication occurs, domain name lookups time out or get blocked by the access point firewall, returning DNS_PROBE_FINISHED_NXDOMAIN.

Diagnostic Verification:

Open a web browser and navigate to a plain, unencrypted HTTP address (e.g., http://neverssl.com or http://detectportal.firefox.com).

Check if the page redirects to a login or landing page.

Step-by-Step Fix:

1.Force Trigger Captive Portal Login Page:

In Chrome, navigate directly to http://neverssl.com or type your gateway's IP address (typically http://192.168.1.1 or http://1.1.1.1) into the URL bar.

2.Disable Custom DNS Server Overrides Temporarily:

If you have custom DNS servers configured (like 1.1.1.1), switch your network adapter settings back to Obtain DNS server address automatically so the local network gateway can resolve its captive portal domain.

3.Accept Terms and Re-enable Custom Settings:

Complete the network splash page login, then re-enable custom DNS settings if desired.

Prevention & Long-Term Monitoring:

Keep http://neverssl.com bookmarked for troubleshooting public Wi-Fi connections.

Which browser-level feature, flag, or secure protocol mode is failing inside Google Chrome?

Chrome Secure DNS (DNS over HTTPS / DoH) mode is enabled with an unreachable provider URL.
Chrome Experimental Network Flags (`chrome://flags`) are causing socket handling bugs.
A malicious or broken Chrome Extension is intercepting and blocking web requests.
Corrupted Chrome User Profile data or local storage cache is failing host resolution.

Re-configuring or Disabling Chrome Secure DNS (DNS over HTTPS)

Solution:

Root Cause: Misconfigured or Unreachable DNS over HTTPS (DoH) Provider

Google Chrome supports DNS over HTTPS (DoH), which encrypts DNS queries inside HTTPS requests sent to a specified provider. If the custom DoH provider URL configured in Chrome is incorrect, blocked by your network firewall, or experiencing downtime, Chrome cannot resolve any domain names, throwing DNS_PROBE_FINISHED_NXDOMAIN even if the operating system's standard DNS is functional.

Diagnostic Verification:

Open Chrome Settings > Privacy and security > Security.

Scroll down to Use secure DNS and check if a custom provider URL is selected.

Step-by-Step Fix:

1.Open Chrome Security Settings:

Navigate to chrome://settings/security in the Chrome address bar.

2.Toggle Secure DNS Mode:

Under Use secure DNS, select With your current service provider (which inherits the working OS DNS settings).

*Alternatively:* Select With and choose a verified public provider from the drop-down menu (e.g., Cloudflare (1.1.1.1) or Google (Public DNS)).

3.Test Disabling Secure DNS:

If errors persist, toggle Use secure DNS to Off temporarily to confirm if DoH encapsulation was the source of failure.

Prevention & Long-Term Monitoring:

Ensure local firewalls permit outbound HTTPS traffic to public DoH resolver endpoints.

Resetting Google Chrome Experimental Flags to Default Settings

Solution:

Root Cause: Experimental Feature Flag Instability in Chromium Engine

Modifying experimental flags under chrome://flags (such as custom Async DNS resolver implementations, QUIC protocol overrides, or experimental socket pooling features) can introduce instability into Chrome's networking layer. Updates to the Chromium browser core can cause modified flags to misbehave, breaking hostname resolution.

Diagnostic Verification:

Navigate to chrome://flags in Chrome.

Look for items marked with a blue dot, indicating non-default user modifications.

Step-by-Step Fix:

1.Access Flags Page:

Open Chrome, type chrome://flags into the address bar, and press Enter.

2.Reset All Flags:

Click the Reset all button located at the top right of the page.

3.Relaunch Browser:

Click the Relaunch button at the bottom of the screen to restart Chrome with default networking parameters.

Prevention & Long-Term Monitoring:

Avoid enabling experimental flags on primary production browsers unless explicitly required for development.

Disabling Conflicting Chrome Extensions and Running Incognito Diagnostics

Solution:

Root Cause: Chrome Extension WebRequest API Interception

Ad-blocking extensions, proxy utilities, and privacy add-ons utilize Chrome's webRequest or declarativeNetRequest APIs to modify outbound HTTP requests and intercept domain queries. If an extension's local rule database becomes corrupt, it may block domain resolution calls, triggering Chrome error pages.

Diagnostic Verification:

Press Ctrl + Shift + N to open an Incognito Window in Chrome.

Navigate to the target domain. If the website loads without error in Incognito mode, an active browser extension is causing the issue.

Step-by-Step Fix:

1.Open Extensions Management:

Navigate to chrome://extensions in the address bar.

2.Isolate the Malfunctioning Extension:

Toggle off all active extensions using their switch controls.

Re-enable extensions one by one, testing the website after each to identify the culprit.

3.Remove Problematic Extension:

Click Remove on the extension responsible for blocking requests.

Prevention & Long-Term Monitoring:

Only install extensions from trusted developers and review extension permissions regularly.

Resetting Google Chrome Profile Data and Restoring Factory Browser Settings

Solution:

Root Cause: Corrupted Chrome User Profile Local State

Persistent corruption within a Chrome User Profile's Preferences, Local State, or Web Data SQLite databases can break browser-level socket initializations and DNS lookup routines. Resetting settings restores default network and cache properties without deleting saved bookmarks or passwords.

Diagnostic Verification:

Click your Profile Icon in the top-right corner of Chrome > click Add under Other Profiles.

Test browsing in the new user profile. If DNS errors disappear, the primary user profile is corrupt.

Step-by-Step Fix:

1.Open Chrome Reset Settings:

Navigate to chrome://settings/reset in the address bar.

2.Execute Settings Reset:

Click Restore settings to their original defaults.

Review the notice and click Reset settings.

3.Re-sync Profile (Optional Alternative):

If a full profile reset is needed, navigate to %LOCALAPPDATA%\Google\Chrome\User Data\ in File Explorer, rename the Default folder to Default.old, and relaunch Chrome to generate a clean profile.

Prevention & Long-Term Monitoring:

Enable Chrome Sync to preserve essential browser data in the event of a required profile reset.

Related Diagnostic Guides

Windows 11 Wi-Fi Connected but No Internet? How to Fix It

Google Account Suspicious Activity? How to Check for Unknown Devices

Microsoft Account Hacked? How to Recover and Secure Your Account

Fast Charging Not Working? How to Check USB PD and Quick Charge Support

Laptop Using Integrated Graphics Instead of Dedicated GPU? Here's How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website