Switching off Wi-Fi and watching a page load over mobile data is not just a workaround. It is the single most informative test you can run, and it has already answered the important question: the site is up, and something between your device and it is not.
Two networks, two completely different paths. Same device, same browser, same URL. When one works and the other does not, everything they share is exonerated and everything they do not share is a suspect. That is a short list.
What the test actually proved ¶
Your phone on mobile data uses your carrier's DNS resolvers, your carrier's routing, and no equipment you own. On Wi-Fi it uses your router's DNS, your ISP's routing, and every piece of hardware and policy in your home or office. The difference between the two is where the fault lives.
Before going further, confirm the site is genuinely up rather than intermittently failing for everyone: run a multi-method check. Four independent probes that all succeed while your Wi-Fi cannot load the page is strong evidence the problem is local. Four that fail means you were unlucky with timing and the site is having a real outage.
1. DNS on the router or the ISP ¶
The most common cause by a wide margin. Your router hands out its own address as the DNS server and forwards queries to your ISP, whose resolver may be stale, overloaded, filtering, or answering with a redirect page for domains it does not like.
Test it by asking a different resolver directly:
- Windows:
nslookup example.com 1.1.1.1 - macOS / Linux:
dig @1.1.1.1 example.com +short
If that returns an address but your normal lookup does not, DNS is the fault. Point the device or the router at a public resolver and retest. Our DNS lookup tool shows what the authoritative answer should be, so you can compare it against what you are being given.
2. A captive portal you never finished ¶
Public and guest networks intercept traffic until you accept their terms. Some only intercept plain HTTP, so an HTTPS site fails with a connection reset or a certificate warning while the portal quietly waits for a page it can hijack. Visit any http:// URL and see whether a login page appears.
3. Router firewall, parental controls, or DNS filtering ¶
Content filtering built into consumer routers, Pi-hole, NextDNS, AdGuard Home, and ISP-level family filters all block by domain. The tell is speed: a filtered domain fails instantly, because something on your network answered. A genuine outage makes you wait for a timeout.
That timing difference is worth internalising. Instant failure means a local decision. Slow failure means nobody answered. See ERR_CONNECTION_REFUSED for the same distinction at the TCP layer.
4. Broken IPv6 on the local network ¶
If your Wi-Fi advertises IPv6 but the path to the internet over IPv6 is broken, your device will prefer the AAAA record, try it, and stall before falling back. Sites that publish no AAAA record work fine, which is why the failure looks arbitrary. Disable IPv6 on the adapter temporarily; if the site loads, that is your answer, and the fix belongs on the router or with the ISP.
5. An MTU black hole ¶
Rare, but unmistakable once you have seen it: the page begins to load and then hangs, or small pages work while large ones do not. Some link in the path drops oversized packets without sending the ICMP message that would tell your device to send smaller ones. PPPoE connections and some VPNs are the usual culprits. Lowering the router MTU to 1400 is the standard test.
6. A device-level proxy or VPN bound to one network ¶
Corporate device management, an old proxy configuration, or a split-tunnel VPN can apply on Wi-Fi and not on cellular. Check the system proxy settings for the Wi-Fi interface specifically rather than globally. If a VPN is involved, our VPN troubleshooting guide covers which failures it causes and which it cures.
7. The ISP itself is blocking or misrouting ¶
Last on the list because it is the least actionable and the most often blamed first. Some ISPs block domains under court order or their own policy, and some simply have a bad route to one destination. A traceroute that dies at the same hop every time, on Wi-Fi but not on mobile data, is the evidence to send to support.
The order worth testing ¶
- Confirm the site is up with a multi-method check. Ten seconds, and it decides whether any of this applies.
- Query a public resolver directly. Most faults stop here.
- Load any plain HTTP page to flush out a captive portal.
- Note whether the failure is instant or slow. Instant means something local answered.
- Disable IPv6 on the adapter and retry.
- Try a second device on the same Wi-Fi. If it also fails, the fault is the network, not the device.
That last step is worth doing early if you have a second device to hand. It splits the remaining suspects in half in about five seconds.