Resolving this site cannot be reached or dns_probe_finished_bad_config error within a windows vps

The Chrome error “This site can’t be reached” with DNS_PROBE_FINISHED_BAD_CONFIG inside a Windows VPS means the browser could not resolve the domain name because of a DNS configuration problem. Start by clearing the DNS cache and checking Chrome’s Secure DNS setting. Then verify and correct the DNS servers configured on the VPS, reset the Windows networking stack if needed, and test the domain’s DNS at the source in case it is a nameserver, DNSSEC or glue record issue.

Before you start

• Have Administrator access inside your Windows VPS. If you lose RDP while changing network settings or rebooting, use the Virtualizor VNC console from our client area to get back in.
• Expect a reboot after some steps. netsh winsock reset and netsh int ip reset both require it and will disconnect RDP.
• Know which outcome you want. If your website is on our shared or reseller hosting, your domain should use ns1.serverworld.uk, ns2.serverworld.uk, ns3.serverworld.uk and ns4.serverworld.uk at your registrar. If you run your own DNS on the VPS, you need working resolvers on the VPS and, if authoritative, the right DNS published at your registrar.
• If you also have a Linux VPS to cross-check from, you will need sudo on it. The commands below cover both AlmaLinux 9 and Ubuntu 24.04.
• Risks:
  • Setting incorrect DNS servers can break lookups for Windows Update and your applications until corrected.
  • On Ubuntu 24.04, editing Netplan YAML incorrectly or using netplan apply without care can drop SSH. Prefer netplan try and keep console access available.
  • On AlmaLinux 9, reactivating a NetworkManager connection can sever SSH. Plan to use the Virtualizor VNC console if you are remote.
  • Chrome’s Secure DNS can override system DNS. Troubleshoot it in the browser as well as on the OS.

Step 1: Confirm it is a DNS issue and scope the problem

First confirm the VPS cannot resolve names and see whether the error affects one domain or all domains.

On Windows Server inside your VPS

This command tests DNS resolution of a domain using the system’s current DNS configuration.

Resolve-DnsName example.com

This command tests resolution through a specific resolver without changing system settings. Replace 1.1.1.1 with a resolver you want to test.

Resolve-DnsName example.com -Server 1.1.1.1

On Ubuntu 24.04

This command installs the dig tool so you can test DNS. It installs the bind9-dnsutils package.

sudo apt update && sudo apt install -y bind9-dnsutils

This command tests resolution using the system resolvers.

dig example.com

This command sends the query to a specific resolver, which helps separate VPS DNS from upstream resolver issues.

dig @1.1.1.1 example.com A

On AlmaLinux 9

This command installs the dig tool. It installs the bind-utils package.

sudo dnf install -y bind-utils

This command tests resolution using the system resolvers.

dig example.com

This command sends the query to a specific resolver.

dig @1.1.1.1 example.com A

If only one domain fails while others resolve, investigate that domain’s DNS further in Step 6 and Step 7. If nothing resolves, fix the VPS resolver configuration in Step 3 and Step 4.

Step 2: Clear DNS caches and retest

Clear caches so you are not chasing stale results.

On Windows Server inside your VPS

This command clears the Windows DNS client cache from Command Prompt.

ipconfig /flushdns

This command clears the DNS client cache from PowerShell.

Clear-DnsClientCache

Retest with Resolve-DnsName from Step 1.

On Ubuntu 24.04

This command flushes the systemd-resolved cache. Ubuntu 24.04 uses systemd-resolved by default.

sudo resolvectl flush-caches

Retest with dig from Step 1.

On AlmaLinux 9

If you installed a caching resolver on AlmaLinux, flush it with its own tool. If you did not, move on to Step 3 and Step 4 and focus on the configured DNS servers. Retest with dig from Step 1.

Step 3: Check Chrome Secure DNS inside the VPS

Chrome can use its own DNS over HTTPS provider which overrides system DNS. If that provider is blocked or unreachable, you will see DNS_PROBE errors in Chrome while other tools work.

1. In Chrome on the VPS, go to Settings, then Privacy and security, then Security.
2. Find Use secure DNS.
3. If it is on with a custom provider, verify the provider, or turn it off to force Chrome to use the Windows system DNS.

Test the site again. If the error goes away only when Secure DNS is off, review the chosen provider or leave Secure DNS disabled on that VPS.

Step 4: Verify and correct the DNS servers configured on the VPS

If your Windows VPS points at wrong or unreachable resolvers, DNS lookups will fail for everything. Check what is set and, if needed, switch to known working resolvers such as 1.1.1.1 and 8.8.8.8 while you investigate.

On Windows Server inside your VPS

This command lists the DNS servers configured on each network adapter, along with the interface alias you will need for the next command.

Get-DnsClientServerAddress

This command sets IPv4 DNS servers on a specific adapter. Replace Ethernet with your adapter name. It sets resolvers to 1.1.1.1 and 8.8.8.8 in that order.

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,8.8.8.8

Retest with Resolve-DnsName example.com. If it works now, the previous resolvers were the cause.

On Ubuntu 24.04

Ubuntu 24.04 manages DNS through Netplan and systemd-resolved. Edit the Netplan file that is already in use, then apply the change safely.

This command lists the Netplan configuration files on the system. Edit the file you find here rather than creating a new one, so you do not end up with two files fighting over the same interface. On cloud images the file is commonly named 50-cloud-init.yaml.

ls /etc/netplan

This command opens that file for editing. Replace the filename with the one the listing showed you.

sudo nano /etc/netplan/50-cloud-init.yaml

Example content to define DNS resolvers on an Ethernet interface named ens18. Adjust for your interface and network.

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: true
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

This command applies the Netplan change temporarily, with a rollback timer running behind it. It reduces the risk of locking yourself out over SSH.

sudo netplan try

Read this part carefully. netplan try does not keep the change on its own. You have to accept it explicitly at the prompt, by pressing Enter, before the timer expires. If you do nothing, or your SSH session drops and you never reach the prompt, Netplan quietly puts the previous configuration back and your edit is not in effect. If that happens, reconnect and run the command again, or make the change from the Virtualizor VNC console where a network wobble will not cut you off mid-prompt.

Once you have accepted the change, retest with dig example.com to confirm it really is live.

On AlmaLinux 9

AlmaLinux 9 uses NetworkManager which writes /etc/resolv.conf from connection profiles. Set DNS servers on the active profile and then reactivate it.

This command lists NetworkManager connections so you can identify the profile name.

nmcli connection show

This command sets IPv4 DNS servers to 1.1.1.1 and 8.8.8.8 on the chosen profile and tells NetworkManager to ignore DHCP-provided DNS. Replace eth0 with your connection name.

sudo nmcli connection modify eth0 ipv4.dns "1.1.1.1 8.8.8.8" ipv4.ignore-auto-dns yes

This command reactivates the connection so the change takes effect. Plan for a brief disruption if you are connected over SSH.

sudo nmcli connection up eth0

Retest with dig example.com.

If you changed the resolvers only to test, put them back before you move on. Run the same command for your operating system with your intended addresses in place of 1.1.1.1 and 8.8.8.8, whether those are your organisation’s resolvers or the ones the VPS had originally. Leaving a diagnostic setting in place is how internal name lookups break a fortnight later with nobody remembering why.

Step 5: Reset the Windows networking stack if corruption is suspected

If DNS still fails, reset Winsock and the TCP/IP stack inside the VPS. This clears network layers that can hold on to a broken state. You will need to reboot.

This command resets Winsock.

netsh winsock reset

This command resets the TCP/IP stack and writes a reset log.

netsh int ip reset

Reboot the VPS, then test again with Resolve-DnsName. Use the Virtualizor VNC console if RDP does not reconnect after the reboot.

Step 6: Test your domain against multiple resolvers to isolate the fault

If one domain still fails, test it against public resolvers. If a resolver returns SERVFAIL with DNSSEC enabled but NOERROR when checking without validation, you have a DNSSEC problem at the domain.

On Windows Server inside your VPS

This command queries a specific resolver so you can compare results.

Resolve-DnsName yourdomain.tld -Server 1.1.1.1

Repeat against another resolver.

Resolve-DnsName yourdomain.tld -Server 8.8.8.8

On Ubuntu 24.04

This command traces delegation from the root to your zone which can reveal broken nameserver delegations.

dig +trace yourdomain.tld

This command enables DNSSEC validation at the resolver and shows if validation fails with SERVFAIL.

dig @1.1.1.1 yourdomain.tld +dnssec

This command disables validation checking on the client side. If this returns NOERROR while the previous returns SERVFAIL, your domain’s DNSSEC chain is misconfigured.

dig @1.1.1.1 yourdomain.tld +cd +dnssec

On AlmaLinux 9

Repeat the same tests on AlmaLinux to confirm results from another host.

dig +trace yourdomain.tld
dig @1.1.1.1 yourdomain.tld +dnssec
dig @1.1.1.1 yourdomain.tld +cd +dnssec

If these tests show a domain-level error, move to Step 7 to correct delegation, DNSSEC or glue. If the domain resolves here but not inside Chrome on the VPS, revisit Step 3 and the configured DNS servers in Step 4.

Step 7: Fix domain-level issues that cause DNS_PROBE_FINISHED_BAD_CONFIG

Chrome’s DNS probe will fail if the domain is delegated incorrectly or has DNSSEC or glue problems. Here is what to look at.

• Nameservers at your registrar. If your website is hosted on our shared, reseller or WordPress hosting, set your domain’s nameservers at your registrar to:
  • ns1.serverworld.uk
  • ns2.serverworld.uk
  • ns3.serverworld.uk
  • ns4.serverworld.uk
  Use these exact hostnames. A wrong value will take your site and email offline. After changing nameservers, allow time for the change to propagate through registries and resolvers.
• DNSSEC. If a validating resolver returns SERVFAIL while a +cd query returns NOERROR, your DNSSEC chain is broken. Typical causes are an incorrect DS record at the registry or expired signatures. Update or remove the DS at the registrar to match your zone’s DNSKEY before re-enabling DNSSEC. Tools like DNSViz can help you visualise the chain.
• Glue records. If you use in-domain or vanity nameservers such as ns1.yourdomain.tld, you must have correct glue records at the registry. Missing or stale glue causes intermittent failures. Update glue records at your registrar.

These changes happen at your registrar rather than in Virtualizor or cPanel. If you are not sure where to edit nameservers, open a support ticket and we will point you to the right screen.

Step 8: If your VPS runs DNS, make sure it is reachable

If your Windows or Linux VPS is acting as an authoritative DNS server for domains, make sure queries can reach it and that it answers correctly.

• Open firewall ports for DNS. DNS uses UDP 53 and TCP 53. On AlmaLinux 9 with firewalld, the commands below allow DNS through the firewall and persist the change, then reload the rules.

  sudo firewall-cmd --add-service=dns --permanent
  sudo firewall-cmd --reload

• Test from outside. From another host, query your VPS directly with dig @your-vps-ip yourdomain.tld A and check it answers.
• Validate zones before reloads. Incorrect zone data, serial handling or syntax errors can take zones offline. Validate your configuration before reloading the DNS service.

Step 9: Reset and retest in order

• Chrome only failing while tools work: review Secure DNS in Step 3 again.
• Tools also failing: confirm your configured DNS servers in Step 4 are reachable, then repeat ipconfig /flushdns and Resolve-DnsName.
• Still failing on Windows after a resolver change: perform the network stack reset in Step 5 and reboot.
• Only one resolver failing: switch to working resolvers while you address the upstream resolver’s outage.

What next

If you are working through DNS and server management topics, browse our VPS guides. If you are comparing server options and want a fresh start, see our London VPS page. That is our UK range, running in our own data centre in Maidenhead, Berkshire.

If you are stuck or the VPS will not reconnect after a change, use the Virtualizor VNC console from our client area. If you need hands-on help, open a support ticket and tell us which steps you have taken and what you saw.