Public DNS works but the default resolver repeatedly fails
Test the alternative on one device first. Keep it only if repeated normal browsing improves and required filtering still works.
Immediate quick checks
Find the Failing Layer Before Resetting the Router
If websites are not loading but the internet works elsewhere, compare one site, browser, device and network path before changing DNS or resetting the router.
- 1Try another website and a private window. This separates one-site and browser-profile failures.
- 2Try another browser and device. Keep the same Wi-Fi connection for a useful comparison.
- 3Turn off VPN or proxy routing for the test. Follow workplace policy and restore required controls afterwards.
- 4Compare home broadband with mobile data. This exposes a home DNS, filter or route-specific failure.
Choose the closest failure
Website Loading Problem Selector
Start with scope. The correct fix changes completely depending on whether one site, one browser, one device or every website fails.
60-second diagnosis
Match the Failure Pattern to One Diagnostic Action
| Failure pattern | Likely layer | Immediate action |
|---|---|---|
| One website fails everywhere | Website outage, account, region block or the site's delivery route. | Check the site on mobile data and an independent status source. Do not reset the router for one failing site. |
| One browser fails | Extension, cache, cookie, certificate state or browser proxy. | Use a private window with extensions disabled, then compare a second browser. |
| One device fails | VPN adapter, proxy, DNS, DHCP lease, security software or device clock. | Compare another device on the same Wi-Fi before changing the router. |
| Apps work but new websites fail | Fresh DNS resolution, HTTPS filtering or browser configuration. | Compare DNS lookups and another browser while keeping the network unchanged. |
| Some large or modern sites stall | VPN/MTU, IPv6 path, filtering or route-specific failure. | Remove VPN/proxy variables, compare mobile data and use advanced packet-size checks only if the simpler tests support them. |
| Every website fails on every device | Router DNS, provider outage, ONT/line fault or network-wide filtering. | Check router and ONT status, compare Ethernet, restart once and check provider status. |
Recommended tests
Check whether the wider connection is stable
These tests do not replace browser and DNS checks, but they show whether packet loss or a wider connection problem is making web requests fail.
Start with the simplest isolation
Browser and Device Checks Before Changing DNS
- Test more than one site.
One failing site is not evidence that the broadband line or DNS is broken.
- Use a private window with extensions disabled.
If the site works, clear only that site's data and re-enable extensions one at a time.
- Compare another browser.
A second browser working on the same device points to the original browser profile, cache, proxy or security state.
- Compare another device on the same Wi-Fi.
If the second device works, do not restart or reconfigure the whole router first.
- Check time, VPN, proxy and security software.
An incorrect clock can break certificate checks; a VPN, secure web gateway or stale proxy can redirect browser traffic into a failed path.
Common Browser Error Codes and What to Test Next
| Displayed error | What it usually indicates | First useful check |
|---|---|---|
ERR_NAME_NOT_RESOLVED | The browser could not translate the website name into a usable address. | Check the spelling, compare the default and public DNS lookups, then clear the local DNS cache. |
DNS_PROBE_FINISHED_NXDOMAIN | The DNS response says the requested name does not exist. This can be a genuine missing record, a typing error, stale DNS or filtering. | Test several unrelated domains and compare the configured resolver with a public resolver before changing router-wide DNS. |
ERR_CONNECTION_TIMED_OUT | The browser did not complete the connection in time. Possible causes include a website outage, route failure, firewall or VPN interference, or wider packet loss. | Compare mobile data, another browser and the LinkSpeed Packet Loss Test. Use MTU checks only when the wider pattern supports them. |
DNS verification
Compare the Default Resolver with a Public DNS Service
Run several lookups. A single slow result does not prove the resolver is faulty.
Compare DNS and Clear the Windows Cache
Open Command Prompt. Compare the normal resolver with a public resolver, then clear the local cache and repeat the affected website.
nslookup www.linkspeed.co.uk
nslookup www.linkspeed.co.uk 1.1.1.1
ipconfig /flushdnsCompare DNS and Clear the macOS Cache
Open Terminal. The cache command may request the administrator password and normally returns no confirmation message.
dig www.linkspeed.co.uk
dig @1.1.1.1 www.linkspeed.co.uk
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderCompare DNS on Linux
Open Terminal. On systems using systemd-resolved, resolvectl can clear the local resolver cache; other distributions may use a different resolver service.
dig www.linkspeed.co.uk
dig @1.1.1.1 www.linkspeed.co.uk
sudo resolvectl flush-cachesBoth resolvers return addresses but the site still times out
DNS is not the only suspect. Compare browser, VPN, security filtering, IPv6 and the destination route.
What each command result actually tells you
| Command or comparison | Primary purpose | Useful signal |
|---|---|---|
nslookup domain or dig domain | Tests the DNS resolver currently configured on the device. | Repeated timeouts or no usable answer across several unrelated domains suggests a resolver, filter or local network problem. |
nslookup domain 1.1.1.1 or dig @1.1.1.1 domain | Compares a public resolver without changing the whole router. | The public resolver works repeatedly while the default resolver fails under the same conditions. |
ipconfig /flushdns, the macOS cache command or resolvectl flush-caches | Clears local cached DNS answers before a controlled retest. | The same website begins loading after the cache is cleared and continues working on repeat visits. |
ping 1.1.1.1 compared with ping -6 2606:4700:4700::1111 | Provides supporting evidence about IPv4 and IPv6 reachability. | A repeatable difference can justify deeper IPv6 or route checks, but ping failure alone does not prove that web traffic is broken. |
Advanced checks
Use IPv6 and Packet-Size Tests Only When the Pattern Fits
These checks are relevant when IPv4 sites work, larger modern sites stall, VPN use changes the result or the same group of sites fails across browsers and devices. They are not the first step for one broken browser.
Check for wider request instability first: run the LinkSpeed Packet Loss Test over Ethernet. Failed requests can support a wider connection diagnosis, but the browser test does not directly prove packet fragmentation or an MTU fault.
Direct IPv4 and IPv6 reachability
ping 1.1.1.1
ping -6 2606:4700:4700::1111Some networks rate-limit ICMP, so failed ping alone does not prove that web traffic is broken.
IPv6 packet-size comparison
Windows:
ping -6 2606:4700:4700::1111 -l 1452Linux:
ping -6 -M do -s 1452 2606:4700:4700::1111Reduce the payload and compare repeated results. macOS flags vary by release; consult man ping. A smaller packet succeeding where larger traffic repeatedly fails can support an MTU diagnosis, but only when the target responds consistently.
Do not disable IPv6 permanently or jump straight to MSS clamping. Confirm the failing path and check VPN, tunnel, firewall and provider routing first.
Apply the matched fix
Fix the Layer Your Comparison Identified
One browser fails
Do this: clear site data, disable the conflicting extension, remove a stale browser proxy and update the browser. Retest: use the same site and network.
One device fails
Do this: remove stale VPN/proxy settings, renew the network connection and reset the device network stack only after saving required workplace settings. Retest: compare the same site on that device and another device.
DNS comparison proves the default resolver is unreliable
Do this: test a reputable resolver on one device, restart the browser and repeat several domains. Retest: confirm normal browsing and required parental or security filtering.
Every home device fails but mobile data works
Do this: check router filtering, DNS, ONT lights and provider status. Restart once in the correct ONT-then-router order on full fibre. If apps and websites both fail, use the Wi-Fi Connected but No Internet guide. Retest: use Ethernet and several unrelated sites.
Escalate with evidence
When the Failure Points to Filtering or Provider Routing
Contact the provider when the same group of sites fails across several devices and browsers over Ethernet, while those sites work on mobile data. Provide timestamps, exact URLs, browser error codes, default and public DNS results, whether IPv4 and IPv6 differ, and whether a reputable VPN changes the route. If browsing and other services deteriorate only during the evening, follow the internet slow at night diagnosis before reporting a site-specific fault.
A VPN changing the result is supporting evidence, not proof of the exact fault. It can bypass provider DNS, filtering, peering and routes at the same time.
FAQ
Websites Not Loading FAQs
Why do apps work but websites fail?
Apps may keep existing connections or cached addresses while browsers need fresh DNS and secure web requests. Test another browser and DNS resolution.
Why does only one site fail?
The site, its account, a supporting content domain, filtering or one external route may be responsible. Compare mobile data before changing the whole network.
Why does one browser fail?
An extension, cache, cookie, certificate state or proxy setting is likely. Start with a private window and a second browser.
Can DNS fail while internet works?
Yes. Existing sessions may continue while new website names cannot be resolved reliably.
Should I keep public DNS permanently?
Only after repeated one-device tests show a reliable improvement and required filtering or workplace policies still work.
When should I contact the provider?
When repeatable Ethernet tests show a cross-device route, resolver or filtering issue that does not occur over mobile data.