DNS_PROBE_FINISHED_BAD_CONFIG is Chrome saying its DNS probe completed and the result suggested a configuration problem rather than a missing domain. In practice it is the "your DNS setup is wrong" error, as distinct from NXDOMAIN, which is "that name does not exist."
What Chrome is distinguishing ¶
Chrome runs a background probe to work out whether a lookup failure is the domain's fault or the resolver's. When the probe itself behaves oddly — malformed responses, a resolver that is unreachable, results that contradict each other — you get BAD_CONFIG rather than NXDOMAIN. The implication is useful: the domain is probably fine and your path to DNS is not.
Fixes, fastest first ¶
- Restart the router. Genuinely the highest-yield step here. Consumer routers run small DNS forwarders that get into bad states, and a reboot clears them.
- Flush the DNS cache on the machine — commands for Windows, macOS and Linux, plus Chrome's own cache at
chrome://net-internals/#dns. - Set an explicit resolver. Replace whatever DHCP handed you with 1.1.1.1 or 8.8.8.8. If pages load immediately afterwards, the resolver you were given was the problem — which is common on hotel, cafe and some ISP networks.
- Renew the DHCP lease (
ipconfig /releasethen/renewon Windows). A lease carrying a stale resolver address produces this exactly. - Turn off VPN, proxy or DNS filtering temporarily. Split-tunnel VPNs are a frequent cause: DNS goes one way, traffic another, and the two disagree.
- Disable Chrome's secure DNS (Settings, Privacy and security, Use secure DNS) as a test. DNS-over-HTTPS to a provider your network blocks fails in precisely this way.
Confirming the domain is innocent ¶
Before spending time on your machine, spend ten seconds ruling out the site. Our DNS lookup resolves the domain from outside your network: if the records come back cleanly there, the domain is healthy and every remaining cause is local. If they do not, no amount of flushing will help — the problem is the domain's DNS, not yours.
The split-tunnel VPN case ¶
This deserves its own note because it is common and confusing. A split-tunnel VPN routes some traffic through the tunnel and some directly, and if DNS goes one way while the connection goes the other, you get resolution results that do not match the network actually carrying your traffic. Internal hostnames fail outside the tunnel; public ones sometimes resolve to internal addresses that are unreachable from where you are.
The symptom is a machine that works fine until the VPN connects, or one that only fails for certain domains. Disconnecting the VPN and retrying is a two-second test that settles it.
If it started after a network change ¶
New router, new ISP, or a new office all mean a new resolver, and a device that cached the old one can hold it well past the point it stopped working. Renewing the DHCP lease is the fastest correction; a full network-settings reset is the blunt version if that does not take.
FAQ ¶
Is DNS_PROBE_FINISHED_BAD_CONFIG a virus?
No. It is a DNS configuration failure. That said, malware that redirects traffic does sometimes work by rewriting DNS settings, so if the error appeared alongside other odd behaviour, checking your configured resolvers is reasonable.
Why does only one device have this problem?
Because DNS settings are per-device. A laptop with a manually configured or VPN-supplied resolver will fail where a phone on the same Wi-Fi succeeds — and that contrast is the fastest confirmation that the domain is fine.
How is this different from NXDOMAIN?
NXDOMAIN is an authoritative "this name does not exist" — the lookup worked and the answer was no. BAD_CONFIG means the lookup process itself misbehaved, which points at your resolver rather than the domain.