Give your WordPress site its first task.
Connect the site you already have, add your agent to Slack or Telegram, and tell it what you need.
Connect your siteStart with 500 free credits. No credit card needed.
On this page
Key takeaways
- Open the site on a phone using mobile data before you change anything. If it loads there, the problem is your computer, router or resolver, and your site needs no changes.
- If every network fails, edit records with whichever provider your nameservers point to. That is not always the registrar, and changes made in any other dashboard do nothing.
- Kinsta says nameserver changes can take 24 to 48 hours, and WordPress.com says up to 72. A wrong record stays wrong no matter how long you wait, so check the records before you blame propagation.
- To change DNS safely: copy every record, including MX for email, into the new provider, check them, then switch nameservers. Keep the old host running while the change spreads.
- Look at plugins only after the domain resolves and the site loads. Deactivating plugins does nothing for a DNS error.
Chrome shows DNS_PROBE_FINISHED_BAD_CONFIG on its “This site can’t be reached” page. It means the browser asked DNS for your domain’s IP address and did not get a usable answer. With no address there was nothing to connect to, so your server never heard from the browser. WordPress never ran.
That is why the usual WordPress reflexes don’t help here. Deactivating plugins, switching themes or editing the site URL under Settings → General changes nothing, because the failure happened before any of that code could run. Save our guide to plugins that stop working for after the domain resolves again. Your first question is simpler: does anyone else see this error?
Who else sees the error? Run the scope test first
Open the site on your phone with Wi-Fi turned off, using mobile data. Then try another computer on your own network, and if you can, ask someone in a different city to try. These three checks take two minutes and tell you which half of this article you need.
| What you see | Where the problem is |
|---|---|
| One computer fails, other devices on the same Wi-Fi work | That computer: its DNS cache, VPN, security software, browser setting or hosts file |
| Every device on your Wi-Fi fails, mobile data works | Your router or your internet provider’s resolver |
| Several unrelated websites fail too | Your local network or resolver, not your domain |
| Your site fails on Wi-Fi and mobile data, from different places | Your domain’s DNS: nameservers, records or DNSSEC |
| Your site fails only for people on one mobile carrier or one company network | That network’s resolver may be filtering your domain |
The last row is easy to miss. Some carriers and corporate networks use DNS security filters that refuse to resolve domains they have flagged as malicious. Your records can be perfect and the site still fails for everyone on that network. The only fix is to contact the filtering provider, and the appeal process varies by vendor.
Practitioners disagree about which case is more common for this exact error code. Many people who troubleshoot it say it is usually local. Hosting documentation, including Kinsta’s, still lists wrong records and wrong nameservers among the causes of failed resolution. Nobody publishes frequency data for this error, so don’t guess. Let the scope test decide.
How to fix it when only your device or network fails
If the site loads anywhere else, leave your site alone. Nothing on it is broken, and changing DNS records now can create a real outage. Work through these steps in order, from cheapest to most involved, and test the site after each one.
- Restart the browser fully. Close every window, quit Chrome and reopen it. Then try an Incognito window. If Incognito works, disable extensions one at a time, starting with ad blockers and security extensions.
- Restart the router. Unplug it, wait about a minute, plug it back in and give it time to reconnect. This clears a stuck router that is handing out bad DNS settings.
- Flush and renew on Windows. Open Command Prompt as administrator and run
ipconfig /flushdns, thenipconfig /release, thenipconfig /renew, one at a time. On a Mac,sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderclears the local cache. - Try a public resolver as a test. In your network adapter’s DNS settings, set the servers to Google Public DNS (8.8.8.8 and 8.8.4.4) or Cloudflare’s resolver (1.1.1.1 and 1.0.0.1). If the site loads, your internet provider’s resolver was failing.
- Test without the layers in between. Pause your VPN or proxy, turn off Chrome’s secure DNS setting (search “secure DNS” in Chrome settings), and on Android check Private DNS. Pause antivirus web filtering just long enough to test, then turn it back on.
- Check the hosts file. A leftover entry for your domain in
C:\Windows\System32\drivers\etc\hostsor/etc/hosts, often from a past migration test, overrides DNS on that one machine.
A correct result is simple: the site loads on the device that was failing, in a normal window. If switching resolvers was the fix, decide whether to keep the change. A public resolver can work around a broken provider, but it also changes which DNS service sees your traffic, so an office network should follow its own IT policy.
Don’t rely on local fixes for one thing: deciding the site is healthy. When you flush your cache or change your resolver, only your own computer is affected. If the site loads for you after that, it proves nothing about your visitors.
How to fix it when every network fails
When the site fails everywhere, the problem is in the domain’s authoritative DNS, where the real records live. Google’s Search Central team wrote in 2023 that DNS errors are most often caused by a setting, or a missing setting, on the DNS server. If you don’t manage that server, contact your DNS provider. If you don’t know who that is, ask your host or registrar.
Find out which dashboard actually controls your DNS
Your nameservers decide where your records live. That might be your registrar, your host, Cloudflare, or a provider you set up years ago and forgot about. Editing records anywhere else does nothing, and deleting “unfamiliar” records in the real zone can make things worse. One wordpress.org support thread shows the cost of guessing: the owner blamed a security headers plugin for taking down the main site and every subdomain, when the real problem was that the domain’s DNS record had disappeared from Cloudflare.
On macOS or Linux, run:
dig example.com NS +short
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 www.example.com +shortOn Windows, nslookup -type=ns example.com and nslookup example.com 1.1.1.1 give the same information. The NS result tells you which provider to log in to. If the A lookups return nothing, the wrong IP, or a SERVFAIL error, the fault is in that zone.
Compare the records with what your host expects
Log in to the provider the nameservers point to. Compare the A record for the root domain, and the A or CNAME record for www, against the values your current host gives you. These are separate hostnames, and each needs its own correct record. WooCommerce’s Shopify migration guide, for example, points the root A record at the new host’s IP and points www at the primary domain with a CNAME. Test both example.com and www.example.com in the browser.
The usual mistakes people make with their own records:
- An A record pointing at the old host after a move, or at a mistyped IP.
- Conflicting records for the same hostname. Kinsta’s docs say to remove existing records for a hostname before adding new ones.
- A record added by mistake while verifying an email or marketing tool. Some registrars add your domain to the host field automatically, so typing the full domain there creates a doubled name.
- A forgotten Cloudflare setup. If Cloudflare is your DNS provider, you change the origin IP and proxy status in the Cloudflare dashboard. The Cloudflare WordPress plugin covers caching and performance features. It does not manage your DNS records. Cloudflare redirect rules can also send visitors somewhere unexpected, which our guide to WordPress redirects covers.
Once the right record is corrected, sites often come back quickly. Some owners report minutes. How fast depends on how long resolvers cached the old answer.
Check DNSSEC if you recently switched providers
If you moved your DNS to a new provider and DNSSEC was turned on at the registrar, the old signing records may no longer match. Cloudflare’s documentation says that changing nameservers without handling DNSSEC can cause SERVFAIL errors, and then the domain won’t resolve at all. Ask your registrar or DNS provider to check the DS records. Don’t simply switch DNSSEC off without understanding why it fails.
Why “wait for propagation” is often the wrong answer
Propagation is real. Kinsta’s DNS docs say nameserver changes may take 24 to 48 hours, and WordPress.com’s support docs say DNS changes usually take a few hours but can take up to 72. But waiting only helps when the new records are correct. If an A record points at the wrong IP, the site stays broken no matter how long you wait.
Check the authoritative answer with dig first. If the authoritative answer is correct and a few resolvers still return the old one, that is propagation. If it is wrong, fix it. Change one thing at a time. If you keep editing records while you wait, you soon can’t tell which version is live.
How to change DNS without taking the site down
The most damaging DNS mistake is also the easiest to avoid. Kinsta warns that switching nameservers before the records exist at the new provider can leave the domain with no DNS records at all. The website, email and everything else on the domain go down together. Do it in this order:
- A day or more ahead, lower the TTL on records you plan to change. WooCommerce suggests a low value such as 300 seconds for a migration. A low TTL makes the switch faster, but not instant.
- Copy or import every record into the new DNS provider, including MX records for email and any TXT verification records.
- Check each record against the old zone and the new host’s values.
- Only then change the nameservers at your registrar.
- Keep the old host running until both hostnames resolve to the new server from several networks.
For a store, pick a low-traffic window and take a fresh backup kept off the host on both sides. Some WooCommerce owners say carts and sessions started before the switch can cause checkout problems afterwards. Agencies running many client domains should keep a written record of which provider is authoritative for each one, along with the other checks in our guide to managing multiple WordPress sites.
What to check once the domain resolves again
When the site loads from several networks, you are back in WordPress territory. Check the home page, a few inner pages, the login screen and checkout if you run a store. If something is broken now, WordPress.org’s plugin documentation says to find a conflict by deactivating plugins one at a time. That is the right process for this stage. It never fixes DNS.
If you would rather not chase what is left yourself, SiteSelf takes WordPress fixes requested through chat once the site resolves. Your DNS records stay with your registrar or DNS provider, and SiteSelf doesn’t change them.
When to stop and get help
Stop changing records and contact your DNS provider, host or registrar if:
- You cannot log in to the registrar or the DNS provider. This happens often when a former developer or agency registered the domain in their own name. Recover access through the registrar’s ownership process, and keep the accounts in your business’s name from then on.
digreturns SERVFAIL and you recently changed providers. That points to DNSSEC, which the registrar has to fix.- The authoritative records match your host’s values and the site still fails everywhere after the propagation window your provider quotes.
- The site fails only on one carrier, which suggests resolver filtering.
When you ask for help, include which devices and networks you tested, when the error started, what you changed beforehand, and the output of your dig or nslookup commands. Support can usually go straight to the record that matters.