DNS_PROBE_FINISHED_BAD_CONFIG

The short version: Set your DNS servers explicitly to a public resolver such as 1.1.1.1 or 8.8.8.8, then flush the DNS cache and retry. This fixes the majority of cases and simultaneously proves the fault was the resolver configuration. If a VPN recently disconnected, reset the network adapter, since VPN clients often leave DNS settings pointing at a resolver that is no longer reachable.

Key takeaways

• DNS_PROBE_FINISHED_BAD_CONFIG means Chrome ran its DNS probe and concluded the resolver configuration itself is broken, so no lookup could complete.
• It is the opposite of NXDOMAIN. That error means DNS answered definitively that the name does not exist; this one means DNS never produced a usable answer at all.
• The fault is local in almost every case: the device, the router, or the resolver they were told to use. The website is rarely involved.
• Setting a public resolver such as 1.1.1.1 or 8.8.8.8 is both the usual fix and a diagnosis, because it proves the problem was the previous DNS configuration.
• A VPN that exited badly is a common cause, leaving DNS settings pointing at a resolver only reachable through a tunnel that no longer exists.

Error type

DNS / browser error

Whose side

Almost always your device or network, not the website

Fix difficulty

Easy

Common cause

The DNS resolver configuration is not usable

What does DNS_PROBE_FINISHED_BAD_CONFIG mean?

DNS_PROBE_FINISHED_BAD_CONFIG is not a raw network error so much as a conclusion. When a name fails to resolve, Chrome runs a diagnostic probe to establish why, and this message is one of its verdicts: the DNS configuration available to the device does not work. The resolver addresses may be wrong, they may point at a server that no longer answers, or the queries may be blocked before they arrive. What the browser is telling you is that it could not obtain a usable answer, which is a different situation from receiving an answer it did not like.

That distinction matters because it points the investigation firmly at your own side. NXDOMAIN, the other common probe verdict, means DNS worked exactly as designed and told you the name does not exist, which usually means a typo or a domain that has lapsed. BAD_CONFIG means the lookup never completed. Most devices receive their resolver addresses from the router over DHCP, so anything that corrupts that path breaks every lookup at once: a router handing out addresses that no longer work, a VPN client that exited without restoring what it changed, or security software intercepting DNS traffic. The rest of the connection keeps working, which is what makes the failure feel so strange.

53

The UDP and TCP port DNS queries use, which some restrictive networks block outright

1.1.1.1

A public resolver worth setting explicitly, both as a fix and as a way to prove the fault was local

RFC 1035

The specification defining how DNS queries and responses work, published in 1987 and still current

How the DNS_PROBE_FINISHED_BAD_CONFIG error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

example.com's server IP address could not be found.

DNS_PROBE_FINISHED_BAD_CONFIG

• DNS_PROBE_FINISHED_BAD_CONFIG
• DNS probe finished bad config
• This site can't be reached, DNS_PROBE_FINISHED_BAD_CONFIG
• ERR_NAME_NOT_RESOLVED
• DNS server not responding
• Server IP address could not be found

The DNS probe verdicts, compared

Chrome reports several different outcomes from the same probe, and each one narrows the problem differently.

What each DNS outcome tells you

Chrome distinguishes these because a lookup can fail in several ways, and each points somewhere different.

What causes DNS_PROBE_FINISHED_BAD_CONFIG?

• Resolver addresses handed out by the router that are wrong, unreachable, or pointing at a DNS server that has stopped answering.
• A VPN client that exited badly and left DNS settings pointing at a resolver only reachable inside a tunnel that no longer exists.
• A stale DNS cache on the device holding failed or outdated entries that keep being reused.
• Security software or a firewall intercepting or blocking DNS traffic on port 53, so queries never reach a resolver.
• A router in a bad state after an outage or a firmware update, still advertising DNS servers it can no longer reach.
• A corrupted or leftover hosts file entry, which is consulted before DNS and can break one hostname while others resolve normally.
• Chrome's own secure DNS setting pointing at a DNS-over-HTTPS provider that is unreachable on the current network, which restricted networks often block.

How to find the cause fast

1. Open a raw IP address such as http://1.1.1.1 in the browser. Loading it while no hostname works confirms the fault is DNS and not the connection.
2. Query a public resolver directly with dig @1.1.1.1 example.com. An answer there while the default resolver fails identifies the configuration as the problem.
3. Check whether other devices on the same network resolve names. All failing points at the router; only one failing points at that device.
4. Look at the adapter's current DNS servers, especially after a VPN disconnect, for addresses that no longer belong on that network.

Terminal

dig example.com;; connection timed out; no servers could be reacheddig @1.1.1.1 example.com +short93.184.216.34# the name is fine; the resolver your device was told to use is not

How DNS_PROBE_FINISHED_BAD_CONFIG looks from the outside

DNS failures on a visitor's side never touch your infrastructure, so nothing about them appears in your logs. But the same class of problem has a version that is entirely yours: a nameserver that stops answering, a zone that fails to load, or records that lapse at the registrar. From inside your own network those failures are often invisible, because internal resolvers and caches keep answering from memory long after the authoritative source has stopped. Checking resolution from outside, from several networks, is the difference between finding out from your own alerting and finding out from the first person who could not reach you.

How to fix DNS_PROBE_FINISHED_BAD_CONFIG

If you are a visitor

1. Set your DNS servers explicitly to a public resolver such as 1.1.1.1 and 1.0.0.1, or 8.8.8.8 and 8.8.4.4, then retry.
2. Flush the DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS).
3. Renew the DHCP lease with ipconfig /release then ipconfig /renew, so the device requests resolver addresses again.
4. Reset the network adapter after any VPN disconnect, since clients frequently leave their DNS settings behind when they exit badly.
5. Restart the router if every device on the network is affected, and check whether it is still advertising DNS servers it can reach.
6. Toggle Chrome's secure DNS setting, since a DNS-over-HTTPS provider can be unreachable on networks that block it.
7. Check the hosts file for stale entries if one specific hostname fails while everything else resolves normally.

If you run the website

1. Confirm your domain resolves from several external resolvers, not just from your own network where caches may be masking a problem.
2. Check that every authoritative nameserver for the zone is answering, since one failing nameserver produces failures for a fraction of visitors.
3. Verify the delegation at the registrar matches the nameservers you actually run, as a mismatch causes intermittent resolution failures.
4. Keep an eye on domain expiry as well as DNS health, because a lapsed registration takes the whole zone down at once.
5. Lower TTLs ahead of any planned DNS change so caches turn over quickly, and raise them again once the change has settled.

Still not fixed? Next steps

• Test whether a raw IP loads while names fail. Reaching 1.1.1.1 in a browser while no hostname resolves isolates the fault to DNS immediately.
• Set a public resolver explicitly on the adapter, then retry. Success there proves the previous configuration was the problem and not the network generally.
• Flush the DNS cache and renew the DHCP lease, which clears stale entries and re-requests resolver addresses from the router.
• Check for VPN leftovers in the adapter's DNS settings, particularly after a client crashed or was force-quit.
• Inspect the hosts file for stale or unwanted entries when one specific hostname fails while everything else resolves.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Prove the resolver is the problem, not the name

# the configured resolver
dig example.com
# ;; connection timed out; no servers could be reached

# a public one, bypassing local configuration
dig @1.1.1.1 example.com +short
# 93.184.216.34   <- the name is fine

Clear cached state and re-request DNS settings

# Windows
ipconfig /flushdns
ipconfig /release && ipconfig /renew

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Check what resolvers the device is actually using

# macOS / Linux
scutil --dns | grep nameserver     # macOS
resolvectl status | grep "DNS Servers"

# Windows
ipconfig /all | findstr "DNS Servers"

How to prevent DNS_PROBE_FINISHED_BAD_CONFIG

The visitor-side version of this error never reaches you, but its counterpart does: a nameserver that stops answering or a zone that fails to load is invisible from inside your own network, because internal caches keep serving answers long after the authoritative source went quiet. Pulsetic checks your website from multiple locations every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, Telegram, or webhook the moment it stops resolving or responding from any of them, so a DNS failure is something you are told about rather than something you are informed of by a customer.

Learn how Pulsetic's domain monitoring detects this from the outside, across 15+ locations.

Sources and further reading

The specifications and vendor documentation this guide is written from, plus deeper reading on the parts it only summarises.

• Chromium network error list (net_error_list.h)
• RFC 1035: Domain names, implementation and specification
• MDN: What is DNS