Bypassing networks that block VPNs

Some networks actively block commercial VPNs — most commonly US universities, corporate Wi-Fi, hotel captive portals, and authoritarian-country ISPs. The threat level varies wildly, so the right response does too. Don’t reach for the heaviest tool first — most VPN blocks in the US/EU corporate world are crude IP-blocklists that one in-app toggle defeats. Save VLESS-over-VPS for nation-state-class filters.

This page is the operator’s tactical playbook. For which VPN to pick, see VPN Recommendation. For where VPN sits relative to Tor and obfuscated proxies generally, see the taxonomy in /general/proxies.

Identify what’s actually blocked

Symptom	What the network is probably doing	First thing to try
WireGuard handshake never completes; OpenVPN-UDP fails	Port-block on UDP 51820 / 1194	Switch to a different WG port (53, 80, 443) or OpenVPN-TCP
Connection completes briefly then drops	IP-blocklist of known commercial-VPN ASNs	Obfuscated mode (in-app) so the destination IP isn’t a known VPN block
Connection won’t even handshake on port 443	Active DPI on VPN handshake patterns	Stronger obfuscation (Shadowsocks, QUIC, WireGuard-in-TLS)
All non-`:443` outbound dies	Allowlist-only firewall	Tunnel over `:443` (any obfuscated transport)
VPN connects, traffic flows briefly, then everything stalls	API endpoint blocking (separate layer — see below)	Switch API access methods

US universities and most corporate networks fall in the first three rows. The fourth is nation-state filters (GFW, Iran, Russia). The fifth is its own thing — read on.

Settings → VPN Settings → WireGuard → Anti-censorship. As of mid-2026 Mullvad ships six methods:

Method	What it does	When to try
Automatic	Cycles through the methods until one connects	Default first attempt
WireGuard port	Same protocol, different port (53, 80, 443)	Network blocks well-known UDP ports
LWO	Mullvad’s own lightweight obfuscator (see Mullvad docs for current mechanism)	Adversary fingerprints WireGuard handshake; QUIC blocked
QUIC	WireGuard wrapped in QUIC (looks like HTTP/3 traffic)	Network passes HTTP/3 traffic to major sites
Shadowsocks	WireGuard wrapped in Shadowsocks (looks like random encrypted bytes)	Lightweight obfuscation; works at most universities
UDP-over-TCP	UDP packets encapsulated in TCP	All UDP outbound is blocked or throttled
None	Vanilla WireGuard	When you’ve confirmed the network doesn’t filter VPNs

Try in roughly this order: Automatic → Shadowsocks → QUIC → UDP-over-TCP → LWO. Each option trades performance for circumvention — start with the lightest that defeats the block.

Mullvad notes that obfuscation methods do not improve performance and may increase CPU / battery consumption. Use only when needed.

Common failure mode — “works for a bit, then stuck”

A specific trap that hits often and which the in-app obfuscation toggle won’t fix on its own: the VPN connects briefly, traffic flows for a bit, then everything seizes up. Looks like a tunnel problem; isn’t.

The Mullvad app frontend log (~/Library/Logs/Mullvad VPN/frontend-main.log on macOS) shows this signature, repeated after every laptop wake-from-sleep or network change:

[warning] Failed to update device info: 14 UNAVAILABLE: Cannot reach the API
[warning] Failed to fetch account data. Retrying in 8000 ms
[warning] Failed to fetch account data. Retrying in 16000 ms
[warning] Failed to fetch account data. Retrying in 32000 ms
[warning] Failed to fetch account data. Retrying in 64000 ms
[warning] Failed to fetch account data. Retrying in 128000 ms

Exponential backoff topping out at 128 s per retry. The daemon is trying to reach api.mullvad.net and can’t. This is not a Shadowsocks / tunnel-obfuscation problem. The Anti-censorship menu only protects the WireGuard tunnel traffic. Before any tunnel can be established, the Mullvad daemon makes a plain-HTTPS call to api.mullvad.net to fetch the relay list, check device info, rotate keys. If the network blocks that endpoint by IP or DNS, the daemon enters a retry loop while the existing cached tunnel slowly degrades — presenting to the user as “stuck.”

The fix is a separate menu: API access methods. Mullvad ships three out of the box:

Method	How the API call gets through
Direct	Plain HTTPS to `api.mullvad.net`. Fails if the network blocks Mullvad IPs or DNS.
Mullvad Bridges	API call routed through Mullvad’s Shadowsocks bridge servers. Disguises destination and protocol.
Encrypted DNS proxy	DNS-over-HTTPS via Cloudflare. Defeats DNS-level blocks of `api.mullvad.net`.

By default the daemon tries Direct first, then falls back through the others. The “stuck for a few minutes” feeling is the backoff window between fallbacks. Pin to a known-working method instead:

# Check which one is currently active
mullvad api-access get

# List all enabled methods
mullvad api-access list

# Test each one from the current network (by index)
mullvad api-access test 1   # Direct
mullvad api-access test 2   # Mullvad Bridges
mullvad api-access test 3   # Encrypted DNS proxy

# Pin to a specific method so the daemon skips the failing one
mullvad api-access use 3    # force Encrypted DNS proxy
# or skip Direct entirely on this network:
mullvad api-access disable 1

For the underlying daemon detail (relay-selection attempts, per-method timing), check /var/log/mullvad-vpn/daemon.log (root-only):

sudo tail -200 /var/log/mullvad-vpn/daemon.log | grep -iE 'api|access method|relay|reconnect|error'

Takeaway: tunnel obfuscation and API-access obfuscation are two different layers. A blocking network can take out either independently, and the symptom of an API block (sluggish degradation, not hard fail) looks nothing like the symptom of a tunnel block (instant connection refusal). If you’re seeing the “worked briefly then stuck” pattern, check the API access methods before assuming the tunnel obfuscation menu has anything to do with it.

Other VPN providers’ equivalents

IVPN — custom WireGuard port + WireGuard-over-OpenVPN; obfsproxy on legacy plans. IVPN docs.
Proton VPN — “Stealth” protocol, Proton’s own TLS-based obfuscation. Proton docs.
NordVPN — “Obfuscated Servers” (OpenVPN-XOR; older mechanism than the above).

Most reputable providers have at least one obfuscated mode. Always avoid Kape-owned providers regardless of the feature list — see VPNs to Avoid.

Layered: VPN over VLESS — when in-app obfuscation fails

If you’ve tried every in-app Anti-censorship method and the VPN still won’t connect, the network is doing more than passive port-blocking or DPI — likely active probing, a strict allowlist, or destination-IP filtering of the VPN’s entire fleet.

At that point the layering is:

Your device → VPN client → Xray client (local) → TLS:443 → Xray server (VPS) → VPN's real servers
                                                  ↑
                                 censoring network sees: normal HTTPS to a CDN-fronted site

You stand up VLESS+REALITY on a VPS in an unblocked location (any cheap provider — Hetzner, Vultr, OVH, $4–$5/mo), wrap the VPN’s traffic inside what looks like HTTPS to a major site, and the VPN client never sees the censoring network. There are three concrete approaches:

TUN mode (cleanest, transparent — Hiddify or Mihomo handle the system-level routing). Works for WireGuard via XUDP.
SOCKS5 proxy from the VPN client (easiest — Mullvad → Settings → VPN Settings → OpenVPN → Use custom SOCKS5 proxy → 127.0.0.1:10808). Requires OpenVPN-TCP mode.
Skip the commercial VPN, just use the VPS as your exit (cheapest). You lose the commercial-VPN privacy properties but you also stop paying for them.

Full walkthrough of each approach, with trade-offs, in VLESS / Xray Deployment Guide → VLESS as outer tunnel for a commercial VPN. Server-side xray.json is the same minimal config in the server-side section — no special “carrying-a-VPN” configuration needed.

Fallbacks without a VPS

If in-app obfuscation fails and you don’t have (or don’t want to stand up) a VPS:

Tor with obfs4 bridges — /general/proxies#tor-with-obfs4-bridges. Slower than a VPN but defeats most university-grade filters and needs no infrastructure beyond your laptop.
Mobile hotspot from a phone — your phone’s LTE is on a different network and almost certainly doesn’t block VPNs. Annoying but reliable.
SSH dynamic port forward to a personal server — ssh -D 1080 user@home-or-vps then point apps at SOCKS5 127.0.0.1:1080. Works as long as SSH outbound is allowed (it usually is, even at universities). Doesn’t get the commercial-VPN’s privacy properties, but unblocks anything HTTP/HTTPS.