Why Does School Wifi Block VPNs and Discord?

Yes, and it's rarely a blacklist of websites. Most campus and halls networks run a commercial filtering appliance that inspects traffic as it leaves the building, and that appliance is looking for patterns, not domain names.

What the network actually sees

A normal VPN connection has a shape. Even encrypted, the handshake, the packet timing, and the TLS certificate metadata can fingerprint it as "VPN traffic" before a single byte of your actual browsing is visible. Deep packet inspection (DPI) doesn't need to decrypt anything to flag it, it just needs to recognize the pattern.

Discord gets caught in the same net for a related reason. Its voice traffic runs over UDP, and plenty of campus networks default to blocking UDP outbound except for a short allowlist (DNS, maybe a VoIP range). Chat still works because it's plain HTTPS over TCP 443. Voice dies because it isn't.

The other common mechanism is SNI filtering. Every HTTPS connection announces which hostname it's asking for in plaintext, in the very first packet of the TLS handshake, before encryption even starts. A filter reading that one field can block a specific site or a specific VPN provider's domain without decrypting anything downstream. Cloudflare's writeup on Encrypted Client Hello covers why this plaintext field exists and what closing it involves: https://blog.cloudflare.com/encrypted-client-hello/

None of this requires the network admin to know what you're doing. It just requires the traffic to look recognizable.

Why a "VPN blocker" isn't one filter

Ask an IT department and they'll usually say they don't block VPNs, they block categories: streaming, P2P, proxy/anonymizer. The VPN gets caught as a side effect of the anonymizer category matching its handshake fingerprint. This is worth knowing because it changes what fixes the problem. A VPN using the same handshake as every other VPN gets caught by the same filter every time. A VPN whose traffic doesn't look like VPN traffic doesn't.

What actually gets through

Pangea is built around that distinction. It ships five transports and tries them in order until one connects:

VLESS + Reality borrows a real site's TLS handshake, so a filter reading the SNI field sees a genuine site, not a VPN. Cloak does TLS obfuscation aimed at a decoy cover site. Shadowsocks skips TLS altogether on its own port, so anything looking specifically for TLS-shaped VPN traffic misses it. Hysteria2 runs over UDP and QUIC, useful exactly when a network kills TCP-based VPN protocols but leaves UDP alone (or vice versa, depending what the filter targets). NaiveProxy mimics real Chromium TLS and HTTP/2, matching an ordinary browser's fingerprint.

The client is GPLv3 and on GitHub, so what it actually sends is checkable rather than a claim you have to take on faith.

What it won't fix

Two things are outside what a VPN can do, and worth saying plainly rather than discovering the hard way. A captive portal that requires logging in with a student ID before any traffic leaves the building isn't a filter you route around, it's an access gate that has to be passed first. And an institutional VPN some universities require for network access at all (binding your student ID to your traffic, whitelisting only approved destinations) is a different thing entirely from a consumer VPN: it's the network monitoring you, not you getting privacy from the network. OONI documents this kind of network interference in detail if you want to see what it looks like from the measurement side: https://ooni.org/

If your campus blocks by application signature and UDP, the fix is a VPN with more than one way to look like ordinary traffic. Pangea has a 5-day free trial with no card required, so you can test it against your actual network before deciding anything. See pricing