VPN will not connect on public Wi-Fi: captive portals explained
Public networks intercept your first request and redirect it to a sign-in page. Until you complete it, the network carries nothing else, so a VPN cannot connect. Disconnect the VPN, open a plain HTTP page to trigger the portal, sign in, then reconnect the tunnel.
4 min read
A captive portal is a network that answers every request with its own sign-in page until you have accepted its terms. That is not a bug or hostility toward VPNs; it is how the operator ties a session to a room number, a boarding pass or a click on a terms checkbox. But the practical result is that the network carries nothing until you have signed in, and a VPN's handshake is part of "nothing".
Why it fails the way it does
Your VPN client tries to reach its server. The portal intercepts the packets and either drops them or answers with an HTTP redirect, which is not a valid response to a VPN handshake. The client sees no reply and reports a timeout.
Meanwhile your device shows full signal and a working Wi-Fi connection, because at the link layer everything is fine. That mismatch is why this is confusing rather than obviously diagnosable.
Auto-connect makes it worse. A client set to connect automatically on untrusted networks fires the moment you join, before you have signed in, and if a kill switch is enabled it now blocks the very traffic that would have loaded the portal.
The order that works
- Turn the VPN off, and turn off any auto-connect or always-on setting temporarily.
- Trigger the portal. Most devices detect it and pop the page themselves.
If not, open a plain HTTP address —
http://neverssl.comexists precisely for this, because an HTTPS address cannot be redirected without a certificate warning. - Complete the sign-in.
- Confirm you are online by loading any normal page.
- Turn the VPN back on, and re-enable auto-connect.
Why HTTPS will not open the portal
The portal works by answering a request with a redirect. For an HTTPS request it would have to present a certificate for the site you asked for, which it does not have, so the browser shows a certificate error instead of the sign-in page. Modern sites use HSTS, so the browser refuses to fall back to HTTP.
That is why typing a familiar site into the address bar increasingly fails to summon the portal, and why the plain-HTTP trick is still useful.
Captive portal detection, and what it discloses
Every major platform probes for portals by requesting a known URL and checking whether the response is what it expects. Apple, Google and Microsoft each have their own. If the answer is a redirect, the system knows it is behind a portal and shows the sign-in sheet.
This probe runs before your VPN connects, by design — otherwise a device could never sign in to a hotel network. It discloses very little: that a device of that type joined a network at that time. That is the trade for being able to use public Wi-Fi at all.
RFC 8910 and RFC 8908 define a cleaner mechanism, where the network advertises its portal URL over DHCP and exposes a small API for session state. Support is growing but far from universal, so the probe remains the fallback.
After sign-in, a few portals still interfere
- DNS filtering. Some networks force all lookups through their own resolver and block others, which breaks a VPN that specifies its own DNS. Symptoms look like a tunnel that connects and passes nothing.
- UDP blocking. Common in hotels and on some airline Wi-Fi, and fatal for WireGuard, which has no TCP fallback. An OpenVPN endpoint on TCP 443 is the way through.
- Session timeouts. Portals often expire a session after a few hours. The VPN drops and cannot reconnect, and you have to sign in again.
Settings worth having for travel
- Auto-connect off, or set to connect after portal sign-in if your client supports that distinction. Several do, and it removes the whole problem.
- A TCP 443 endpoint saved as a fallback, for networks that block UDP.
- Kill switch on once you are through, because the entire point of using a VPN on a shared network is that the network cannot read your traffic.
Do not skip the VPN because the portal was awkward
The portal is where public Wi-Fi is most annoying and also where it matters most. Once signed in, you are sharing a network with everyone else in the building. Bring the tunnel up before doing anything else, and confirm it with what is my IP rather than trusting the icon — on a network that was actively interfering a minute ago, a second of verification is proportionate.
