Why does my VPN work on mobile data but not on school wifi?

If your VPN connects instantly on mobile data and then hangs, times out, or connects-but-loads-nothing the moment you join the school or campus wifi, the VPN is not broken. That network is filtering it, and your phone carrier is not. The useful question is which method the network is using, because three of the four have a workaround and one of them mostly does not.

Here are the four, roughly in order of how common they are on education networks.

1. The domain is on a category blocklist

The cheapest filter to run is a DNS blocklist. Your device asks the network's resolver where some-vpn-provider.com lives, the resolver recognises the category, and it answers with nothing or with a block page. In the UK this is often not even the university's own kit: Jisc runs a Protective DNS service for the education sector, and commercial filters sold to schools ship with a "VPN and proxy" category switched on by default.

How it looks: you cannot even reach the provider's website to download the client. The app says it cannot resolve the server.

How to check: try to load the provider's homepage on the wifi. If the site itself is unreachable but everything else loads, you are looking at a DNS or category block, not a protocol block.

What helps: installing the client before you get on that network, and a client that does not need to look up a fresh hostname every time it connects.

2. Only ports 80 and 443 are allowed out

Plenty of managed networks let outbound traffic leave on the two web ports and drop everything else. WireGuard's default is UDP 51820. OpenVPN's is 1194. Both are outside the allowed set, so the packets simply vanish — no error, no reset, just silence until the client gives up.

How it looks: the connection attempt hangs and eventually times out. Every time. Instantly, on any server you pick.

How to check: if regular web browsing works fine and only the VPN times out, a port restriction is the first suspect.

What helps: a transport that runs over TCP 443 and looks like ordinary HTTPS, because that port has to stay open for the network to be usable at all.

3. Deep packet inspection recognises the handshake

This is the one people find hardest to believe: a filter can drop your VPN on port 443 without decrypting anything, because the opening handshake of most VPN protocols is distinctive.

WireGuard's protocol specification fixes the first byte of a handshake initiation message and the message length, so the first packet of a WireGuard session has a recognisable shape regardless of what port it arrives on. OpenVPN is worse: researchers at the University of Michigan showed in OpenVPN is Open to VPN Fingerprinting (USENIX Security 2022) that they could identify OpenVPN flows in real ISP traffic with over 85% recall and negligible false positives, including obfuscated variants.

How it looks: the connection comes up briefly and then dies. Or it works for thirty seconds after you connect and then stops. Or one protocol in your client works and another does not.

How to check: switch protocols in the client. If WireGuard fails and something TLS-based works, you are being fingerprinted rather than port-blocked.

What helps: a transport whose handshake is a real TLS handshake, not an imitation of one.

4. Active probing

The most sophisticated filters do not just watch. When they see a connection they suspect, they connect to that same server themselves and see how it answers. If it responds like a proxy, the address goes on a blocklist. This was documented in detail for the Great Firewall in How China Detects and Blocks Shadowsocks (IMC 2020), where the authors observed probes arriving at their own servers within seconds of a real connection.

Education networks rarely go this far. It matters here mainly because it is the reason a server that worked yesterday can be dead today: something proved it was a proxy, and now the address is blocked for everyone on that network.

What helps: a server that answers a probe the way a genuine website would, because there is nothing to catch.

Why the mobile data test is worth thirty seconds

Turn the wifi off, try the same thing on your phone's connection, and you have separated two possibilities that look identical from the sofa. If it works on mobile data, the app is fine, the servers are fine, your account is fine, and the network you are sitting on is making a decision about your traffic. Everything above is then about narrowing down which decision.

Where Pangea fits

Pangea has five transports and tries them in order until one connects: VLESS + Reality, Cloak, Shadowsocks, Hysteria2, NaiveProxy.

They fail differently on purpose. Reality borrows a real site's TLS handshake, so probing and SNI inspection see a genuine site. Cloak wraps traffic in TLS aimed at a decoy. Shadowsocks uses no TLS at all, so a filter tuned to TLS misses it. Hysteria2 runs over UDP and QUIC, which is worth trying when TCP is the thing being killed. NaiveProxy uses real Chromium TLS and HTTP/2, so the fingerprint matches a browser. If a network learns one of them, the client moves to the next.

The connection uses 256-bit encryption, keys are generated on your device, and the desktop client is GPLv3 on GitHub — you can read what it sends before you trust it.

The honest limits, since this post is about diagnosis: a captive portal you have not signed into will stop everything, a network that blocks the hub's address outright will stop everything, and filtering methods keep improving. Nobody can promise a connection on every network, and anyone who does is selling something. The apps are Windows and macOS, with iOS via Shadowrocket; there is no Android app yet.

If the network you are stuck on is a campus or halls one, that is the case the product was built around — more on that here, or see pricing. There are five days free with no card, which is long enough to find out whether it gets through your particular network before you pay anything.