Chrome: DNS_PROBE_FINISHED_BAD_CONFIG on every site

Hi, it's BlueByte. Chrome fills the page with This site can't be reached and DNS_PROBE_FINISHED_BAD_CONFIG underneath — and it happens on every site, not just one. The wording makes it sound like the page is broken, but it isn't: Chrome ran its own DNS probe and decided the problem is your machine's DNS setup, not the website. We'll walk through what that string means, how to prove it's DNS and not the network, fix it by cause with commands you can paste, and keep it from coming back.

What DNS_PROBE_FINISHED_BAD_CONFIG is really telling you

Chrome shows a few close variants of the same page:

This site can't be reached
The webpage at https://example.com/ might be temporarily down or it may
have moved permanently to a new web address.
DNS_PROBE_FINISHED_BAD_CONFIG

You may see DNS_PROBE_STARTED or DNS_PROBE_FINISHED_NO_INTERNET flash first. Chromium defines this status in plain words: "The DNS configuration is wrong, or the servers are down or broken." That is the whole diagnosis in one line — Chrome asked the operating system to resolve the hostname, the resolver answered with a failure, and Chrome's follow-up probe confirmed DNS itself is the part that's misbehaving. The site is fine; name resolution on this machine (or the router in front of it) is not.

Why the DNS config, not the site, is the problem

A handful of concrete causes produce this:

• A stale DNS resolver cache — an old, wrong record is cached and keeps being served.
• A bad DHCP lease — the adapter picked up an IP, gateway, or DNS server that no longer works.
• A corrupt Winsock catalog — the Windows network stack is in a bad state, often after a VPN or "network booster" tool is uninstalled.
• A DNS server that's unreachable or wrong — the configured resolver (usually the router) is down, or a manual entry points at a server that stopped answering.
• A router handing out broken DNS over DHCP — every device on that network sees the error, which is the tell.

First, prove it's DNS and not the network

Don't guess — separate connectivity from name resolution:

ping 8.8.8.8
ping google.com

If ping 8.8.8.8 succeeds but ping google.com fails with could not find host, you have a working network but no name resolution — which is exactly what the error claims. Now query the resolver directly:

nslookup google.com

A broken resolver looks like this:

Server:  UnKnown
Address:  192.168.0.1
 
*** UnKnown can't find google.com: Server failed

A Server failed or a timeout here points straight at the configured DNS server. Run ipconfig /all to see which servers the adapter is actually using.

Clear the caches that hold the bad config

Flush the OS resolver cache first — this alone fixes the stale-record case. On Windows:

ipconfig /flushdns

Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

resolvectl flush-caches

Chrome keeps its own in-process host cache too. Open chrome://net-internals/#dns, click Clear host cache, then reload the page.

Renew the lease and reset the network stack

If flushing didn't help, drop the DHCP lease and pull a fresh one:

ipconfig /release
ipconfig /renew

Microsoft's reference describes /release as sending a DHCPRELEASE to the server and /renew as renewing the configuration — together they replace a bad lease. If the stack itself is corrupt, reset Winsock and the IP stack, then reboot:

netsh winsock reset
netsh int ip reset

Nothing here touches your files — you're resetting network state, not the disk. A reboot is required for the Winsock reset to take effect; that's expected, not a sign something went wrong.

Point at a DNS resolver that actually answers

If your ISP's or router's resolver is the broken part, set a public one on the adapter (replace Wi-Fi with your adapter name from ipconfig /all):

netsh interface ip set dns name="Wi-Fi" static 8.8.8.8
netsh interface ip add dns name="Wi-Fi" 1.1.1.1 index=2

Reload the page. If sites resolve now, the original DNS server was the "bad config" the error named.

A stuck laptop, walked end to end

One Windows laptop showed DNS_PROBE_FINISHED_BAD_CONFIG on every site; a phone on the same Wi-Fi was fine, so the fault was on the laptop. ping 8.8.8.8 worked, ping google.com failed — DNS, confirmed. ipconfig /flushdns changed nothing, and neither did release/renew. nslookup google.com returned Server failed against 192.168.0.1, the router. Setting DNS to 8.8.8.8 loaded every site instantly. The root cause was the router's resolver having crashed; changing the client DNS was the immediate fix, and restarting the router was the permanent one.

Confirm it's fixed and keep it from coming back

Verify by running nslookup google.com and seeing a real address come back, then loading a page in Chrome. To prevent a repeat: reboot the router on a schedule or set a reliable resolver, don't hand-enter DNS servers you can't verify, and remove "network optimizer" tools that rewrite Winsock behind your back.

How it differs from NXDOMAIN and ERR_NAME_NOT_RESOLVED

This is where the exact string earns its keep. Chromium defines DNS_PROBE_FINISHED_NXDOMAIN as "The DNS servers are working fine, so the domain must not exist" — a typo or a dead domain, and only that one site fails. DNS_PROBE_FINISHED_BAD_CONFIG means DNS itself is broken, so every site fails. ERR_NAME_NOT_RESOLVED is the lower-level version of the NXDOMAIN case. The quick rule: one site fails, suspect the site or a typo; every site fails, it's your DNS.