Do VPNs Work on Hotel, Airport & School Wi-Fi? Captive Portals Explained

You connect to hotel Wi-Fi, your device shows "connected," but nothing loads — and turning on your VPN doesn't help, it makes it worse. This is one of the most common travel VPN frustrations, and it has a specific, well-understood cause: a captive portal. Once you understand how captive portals actually work, the fix is a simple two-step sequence that resolves the vast majority of cases.

What a captive portal actually is

A captive portal is the login or terms-acceptance page that hotels, airports, cafés, and schools use to control network access — enter your room number, accept terms of service, or provide payment before you get full internet access. Technically, it works by intercepting your device's very first plain HTTP web request and redirecting it to that login page.

Why a VPN breaks this — and why order matters

Here's the core conflict: a VPN encrypts all your traffic before it leaves your device, which means the captive portal can no longer see or intercept your first request to redirect you to the login page. If your VPN connects (or tries to) before you've passed the portal, the network simply can't authenticate you — you get "connected" with no actual internet access, and the VPN looks broken when the real issue is that authentication never happened.

The exact step-by-step fix

1. Disconnect your VPN entirely — not just pause it, fully disconnect.
2. Join the Wi-Fi network normally.
3. Open a browser and try loading any plain website. The login page should appear automatically. If it doesn't, try a site specifically designed to trigger it, since many modern sites force HTTPS connections that captive portals can't intercept.
4. Complete the login — room number, terms acceptance, whatever the network requires.
5. Confirm real internet access by loading a couple of ordinary sites without the VPN.
6. Reconnect your VPN. It should now connect normally, since the network already recognizes your device as authenticated.

If the portal page never appears

Sometimes step 3 fails silently — you're stuck "connected" with no portal in sight. A few things break portal detection specifically:

• Browser forcing HTTPS. Modern browsers aggressively upgrade connections to HTTPS, which the portal can't intercept the way it can plain HTTP. Try a different browser — Safari on Apple devices and Edge on Windows tend to have better native captive-portal detection than Chrome.
• Custom DNS servers. If your device uses a custom DNS (Cloudflare, Google, or similar) instead of the network's own DNS, the portal's redirect mechanism can fail to trigger. Temporarily reverting to automatic/network DNS often fixes this.
• Cached network state. Forgetting the network entirely and rejoining fresh, or toggling Wi-Fi off and back on, forces the device to treat it as a new connection and re-triggers portal detection.

Once you're through: why VPN blocking still happens

Passing the portal doesn't guarantee smooth VPN sailing afterward. Hotel and airport networks commonly block or restrict VPN traffic on purpose — for network management, sometimes for local content-restriction compliance, and sometimes simply because enterprise-grade router hardware flags VPN protocols by default. The most commonly blocked ports are standard VPN ports like OpenVPN's default and WireGuard's default UDP port. The workaround:

• Switch to obfuscated/stealth mode if your provider offers it — this disguises VPN traffic to look like ordinary HTTPS, which restrictive networks can't distinguish and block without breaking normal web browsing entirely.
• Switch to TCP on port 443 specifically — this is the same port regular encrypted web traffic uses, making it much harder for a network to block without breaking the internet for everyone else on it too.
• Try a different VPN server if the first attempt fails; some networks block by destination pattern rather than protocol.

Why "Always-On VPN" complicates this specifically

If you've enabled an always-on VPN mode that auto-connects and blocks non-VPN traffic, that setting will actively fight the sequence above by preventing the portal from ever being reached. Most providers offer a "temporary internet access" option in this scenario — a short window (often around three minutes) of unprotected access specifically to complete captive portal authentication before the always-on protection resumes.

A note on mobile hotspot workarounds

If a specific network's captive portal or VPN blocking proves genuinely unworkable despite trying every step above, switching to your phone's mobile hotspot for VPN-dependent tasks is a reliable fallback that sidesteps the problem entirely — mobile carrier networks essentially never run captive portals or VPN-blocking infrastructure the way public Wi-Fi networks do. This costs mobile data rather than using the free Wi-Fi, but for a short, VPN-dependent task like checking a work email or accessing a geo-restricted service, it's often faster than continuing to troubleshoot a stubborn hotel or airport network. It's a genuinely underused workaround precisely because people default to fighting the Wi-Fi network rather than sidestepping it entirely, even when a data-based alternative sits in their pocket the whole time. For a short verification task, the mobile data cost is almost always trivial compared to the time lost troubleshooting a network that was never going to cooperate.

The bottom line

This isn't really a VPN malfunction — it's a predictable interaction between two systems doing exactly what they're designed to do. Disconnect, authenticate, reconnect, and if the network still fights you afterward, obfuscation or TCP port 443 is the next lever. A provider with reliable obfuscated servers built in makes this whole process meaningfully less frustrating on a trip — worth checking before your next hotel stay via current provider comparisons.