Site opens on mobile data, not Wi-Fi?

Why a site fails only on Wi-Fi: router DNS, content filters, IPv6, Private DNS, captive portals. How to find the cause and fix it.

Published 5 min readĐọc bằng tiếng Việt →

This is one of the most useful clues in troubleshooting: the same phone, the same site, and it works on mobile data but not on Wi-Fi. The site itself is clearly fine, and so is your phone. Something on the Wi-Fi path is different. This article lists the common reasons from most to least likely, with a quick test for each.

What really changes when you switch to Wi-Fi

Switching networks changes several things at once:

  • The DNS server. Mobile data uses your carrier's resolver. Wi-Fi usually uses the router, which forwards to the ISP behind it or to another service.
  • The filters in the path. A router, a school firewall or an ISP can each filter differently.
  • The IP versions available. One network may offer IPv6 and the other only IPv4.
  • The gateway behaviour. Some Wi-Fi networks require a login or consent page first.

Cause 1. The Wi-Fi's DNS gives a wrong or no answer

This is the most common cause. The router's DNS may be misconfigured, overloaded, caching a bad answer, or deliberately filtering. Test: set another DNS server for the Wi-Fi network, or enable GreenTunnel so DNS goes to the encrypted server you chose, then retest. If the site now opens, DNS was the cause. See encrypted DNS. A quick restart of the router also clears a bad cache.

Cause 2. A content filter on the router or the network

Parental controls, family DNS services, and school or office firewalls block categories or domains. Other devices on the same Wi-Fi will fail too. Test: try another device on the Wi-Fi, and check the router for filtering options. If you do not manage the network, it may be a policy. See Which websites are blocked on my Wi-Fi?

Cause 3. The ISP filters by DNS or by site name

The ISP behind your Wi-Fi may block a site that your carrier does not (carriers and ISPs differ). The filter may use DNS or the site name (SNI) in the first HTTPS packet. Test: run Inspect URL on the Wi-Fi. A "fake DNS" verdict is fixed by encrypted DNS. A "name filtered" verdict may be helped by a bypass technique. See What is DPI? and Is a site blocked on your network?

Cause 4. IPv6 trouble on one of the networks

If the Wi-Fi advertises IPv6 but its IPv6 path is broken, apps may try IPv6 first and wait before falling back to IPv4, so the site loads slowly or fails. Test: check whether other sites that are IPv6-only or dual-stack also stall, and temporarily disable IPv6 on the router if you manage it. See IPv6 and VPNs.

Cause 5. Private DNS or a custom DNS on the phone

A "Private DNS" hostname on Android, or a DNS profile on iOS, may work on mobile data and fail on a Wi-Fi that blocks or intercepts it (for example, a network that blocks DNS over TLS on port 853). Test: set Private DNS to automatic or off and retest.

Cause 6. A captive portal you have not completed

Cafés, hotels and airports often show a login or "I agree" page. Until you accept it, many sites fail even though Wi-Fi shows as connected. Test: open a plain HTTP page such as http://neverssl.com to trigger the portal page, or disconnect and reconnect to the network.

Cause 7. Router quirks: MTU, firewall or a bad update

An MTU mismatch can break only some sites, those whose packets are large. A router firmware problem or an overloaded NAT can do similar things. Test: restart the router, update its firmware, and try another band (2.4 and 5 GHz). If it keeps failing only for some sites, the router or ISP line is the likely cause.

Cause 8. A VPN, proxy or ad-blocker interacting with Wi-Fi

An app may be configured for mobile data only, or an ad-blocking DNS may flag the site. Test: turn each such app off in turn. Only one VPN can be active on a phone at once.

A short routine

  1. Reload, then toggle Wi-Fi off and on.
  2. Check for a captive portal with http://neverssl.com.
  3. Test on a second device on the same Wi-Fi.
  4. Set Private DNS to automatic and turn off other VPN, proxy or filter apps.
  5. Restart the router.
  6. Run Inspect URL on the Wi-Fi and follow its verdict. For the full flow, see How to check if a website is blocked on my Wi-Fi and How to unblock a website.

If a technique helps, Requester will show the connection as Bypass. If a site only fails for an app that dislikes modified traffic, add its domain to Always direct in the routing rules.

What GreenTunnel can and cannot do here

GreenTunnel can fix DNS tampering with encrypted DNS and may get past name-based filtering by reshaping the first packets. It cannot fix a broken router, a captive portal, an IPv6 fault, or an IP-level block, and it does not hide your IP address. It is a local VPN with no server of ours, free on Android and iPhone, with optional Premium. See the home page.

FAQ

Why does one site fail on Wi-Fi while all others work?

That points to a DNS or filter issue specific to that name, or to an MTU or IPv6 quirk affecting only that server. Compare DNS answers and run Inspect URL.

Does it mean my router is hacked?

Almost never. Far more often it is a DNS cache, a filter setting or an ISP policy. If DNS answers look wrong for many sites, set your own DNS server and update the router.

Should I just change DNS on the router?

It is a reasonable test and often a fix. Some networks intercept plain DNS, so encrypted DNS on the device is more dependable.

Why does the opposite happen: it works on Wi-Fi but not on mobile data?

The same reasoning applies in reverse. Carriers have their own DNS, filters and IPv6 behaviour. Run the same tests on mobile data.

Sources

← All posts