VPNs on In-Flight and Cruise Ship Wi-Fi

Wi-Fi on aircraft and ships is delivered over a satellite or air-to-ground link shared by everybody on board. That link has a long round-trip time, limited capacity, and traffic management that is usually far more aggressive than anything on the ground. A VPN can work over it, but the experience is defined by the link, not by your provider — and some of these networks restrict tunnels outright.

The practical answer is to adjust what you attempt, not just which server you pick.

Why the link changes everything

A satellite link introduces delay that no software can remove: the signal has to travel to the satellite and back, and geostationary services have a longer path than low-orbit ones. Add a shared uplink, hundreds of passengers, and per-user shaping, and the result is a connection with high latency, variable throughput, and frequent brief interruptions.

A VPN sits on top of that. It adds its own handshake, its own overhead per packet, and its own sensitivity to loss. Where a plain web page might struggle through, an encrypted tunnel that has to re-establish after each interruption struggles more. This is not a defect in the VPN; it is what tunnelling over a lossy, high-delay path feels like.

What tends to break, and why

Connection setup times out. Establishing a tunnel requires a round trip or two before anything useful happens. On a saturated link those handshakes can simply fail, repeatedly, while ordinary web browsing keeps limping along.

The tunnel drops when you move between coverage areas. Handovers between satellite beams or ground stations cause interruptions. Some VPN clients reconnect transparently; others need a nudge.

A kill switch makes it look like total failure. If your kill switch blocks traffic whenever the tunnel is down, an unstable link produces long dead periods rather than degraded service. That is correct behaviour, but on this kind of link you should expect it.

Onboard services stop working. Many aircraft and ships offer a local portal — moving map, entertainment library, messaging, food ordering — served from equipment on board. Route all your traffic through a tunnel and that local service can become unreachable, because it never involved the internet at all.

Only some protocols pass. Provider networks frequently allow standard web traffic and block much else. As on guest Wi-Fi, changing to a protocol or mode that presents on a common port is the highest-value single change; the general pattern is in why hotel and airport Wi-Fi breaks your VPN.

The portal step still applies

These networks are captive portals with extra steps: choose a plan, sometimes enter a booking reference or cabin number, accept terms, occasionally pay. All of that must complete before a tunnel can reach anything, so the sequence is the same — sign in first, tunnel second.

Cruise networks add a wrinkle: sessions are often tied to a cabin or a per-device allowance, and switching devices can require signing out properly rather than just closing a laptop.

Geolocation gets strange

Where you appear to be on these links has little to do with where you physically are. The visible address usually belongs to the connectivity provider and often maps to a ground station or the operator’s home country. In practice:

• You may appear to be in a country you are nowhere near.
• The apparent country can change mid-journey as the connection changes ground stations.
• Some services flag this address space as commercial or non-residential.

If a site behaves as though you are in an unexpected country, that is normal here and not worth troubleshooting. The general explanation is in why IP geolocation gets your location wrong.

What is actually reasonable to do onboard

Match your expectations to the link:

• Text-first work. Email, messaging, plain documents, and terminal sessions tolerate delay far better than anything interactive.
• Anything you prepared offline. Downloaded reading, offline maps, drafts saved locally, media already on the device.
• Short, discrete transactions rather than long sessions that must stay connected.

And what to avoid:

• Video calls. Latency and jitter make these unpleasant even without a tunnel.
• Large downloads or backups. These will be shaped, may be blocked, and may consume a paid allowance quickly.
• Streaming. Many onboard plans prohibit it explicitly, and the link cannot sustain it well regardless.
• Anything urgent involving a second factor. If a login needs an SMS code you cannot receive at altitude, you are stuck — see why 2FA breaks when you travel.

Should you use a VPN at all up there?

Yes for anything you would not want a shared onboard network to observe, with a caveat: if the tunnel will not establish reliably, the honest choice is to postpone the sensitive task rather than to do it unprotected. Onboard networks are shared with strangers and operated by a third party, so the reasoning for using one is the same as any untrusted network — but a tunnel that keeps collapsing gives you neither privacy nor usable service.

The better plan is to decide before you board what needs to happen in the air and prepare accordingly, which is the point of the pre-departure connectivity checklist.

Bottom line

In-flight and cruise connectivity is a shared, high-latency, heavily managed link, and a VPN inherits all of those properties. Expect slow handshakes, drops at handover, odd apparent locations, and blocked protocols — then plan to do text-shaped work over it, and leave anything demanding for solid ground.