Why Does a Website Work on Mobile Data but Not Wi-Fi?

If a website works on mobile data but not Wi-Fi, the website is not universally offline. The changing variable is the path from your device through the Wi-Fi network, so the most likely fault is local DNS, the router, a VPN or filter, browser state, or the broadband provider's route. First, run the URL through the ClockTools Website Down Checker. Then test the same URL on the same device over Wi-Fi and mobile data, changing only one variable at a time.

What does this symptom prove?

It proves that at least one network path can reach the site at that moment. It does not prove that every page, account action, region, or network can reach it. Mobile data and home Wi-Fi can use different DNS resolvers, public IP addresses, routes, content filters, and IPv4/IPv6 paths.

Use this small evidence matrix before changing settings:

The phrase “same URL” matters. A homepage and an authenticated dashboard can travel through different application paths. Copy the full address rather than typing only the domain.

Is the website actually down?

Check it from outside your local network before rebooting anything. ClockTools performs an external DNS and HTTP check and reports the verdict, A/AAAA resolution, redirects, final URL, response status, selected headers, and timing. In a controlled check on 2026-08-31, https://example.com returned online, HTTP 200, DNS resolved, and no redirects from the MAA edge. A deliberately nonexistent .invalid hostname returned unreachable, with DNS unresolved and no HTTP result.

Those two probes show why the order matters: a failed DNS lookup and a reachable HTTP server require different fixes. They also show the tool's boundary. One external edge is strong evidence, not proof of availability from every city or ISP.

If the external result is reachable but your Wi-Fi still fails, continue locally. If it is unreachable externally and on mobile data, wait or contact the site owner before changing your router.

Where should you test next?

Follow the diagnosis tree in the accompanying diagram:

1. Keep the device and exact URL fixed; switch only between Wi-Fi and mobile data.

2. On Wi-Fi, try a private window or a second browser.

3. Try another device on the same Wi-Fi.

4. Temporarily pause a VPN or proxy only long enough to run one comparison, then restore it.

5. Compare DNS behavior before replacing the resolver.

6. Restart the router only after recording the evidence you would otherwise erase.

A private window can bypass some cached cookies and extensions, but it does not create a new ISP route. A second device on the same Wi-Fi is more useful for separating device state from network state. For a route-level clue, use Trace Route; for your egress identity, compare What Is My IP? on each network.

Could DNS be the difference?

Yes. Your Wi-Fi router may advertise the ISP's resolver while mobile data uses the carrier's resolver. One resolver can have a stale record, filtering policy, or failure that the other does not.

Start with observation, not permanent replacement. Note whether the external check resolves A or AAAA records. On the affected device, disconnect and reconnect to Wi-Fi, then retry. If your operating system provides a DNS cache flush, use its documented method. Only then compare with a reputable alternate resolver. Cloudflare documents its DNS-over-HTTPS JSON interface for an explicit resolver comparison.

Do not interpret “DNS works” as “the page must render.” DNS only maps the name. TLS, routing, server policy, and the application still have to succeed.

Could the router, VPN, or ISP be blocking the path?

Each can create exactly this split:

• A router can retain bad state, apply parental controls, prefer a broken IPv6 path, or block a category.
• A VPN, proxy, antivirus web shield, or enterprise profile can alter DNS and routing.
• An ISP can have a routing or resolver incident affecting one destination.
• A site can rate-limit or block the Wi-Fi network's public IP while accepting the mobile carrier IP.

Check scope before disabling protections. If every device fails only on one Wi-Fi network, focus on that network. If only one managed device fails, do not remove its security controls; ask the administrator. Microsoft's Windows Wi-Fi troubleshooting sequence and Google's Android connection troubleshooting both begin with basic connection checks and progressively isolate device and network state.

What should you reset, and in what order?

Use the least disruptive change first:

Avoid factory-resetting the router unless you have its configuration and credentials. Avoid leaving a firewall, VPN, or security product disabled merely because the page loaded once. If the page opens but looks incomplete, run the Website Rendering Test because static assets or scripts may be failing even when the main HTTP response succeeds.

When should you stop troubleshooting locally?

Stop and escalate when the evidence points outside your control: the external checker and mobile data both fail; trace results die consistently beyond your router; every device on one ISP fails while another network works; or the site shows an access-policy response tied to your public IP. Give the provider the exact URL, timestamps with timezone, external verdict, DNS result, affected network, and steps already tested. That evidence is far more useful than “the internet is broken.”