Why Does a VPN Make Ship Internet Even Slower?

Updated 22 September 2026 · vpn, connectivity, satellite, crew-wifi

Some links on this page are affiliate links. If you buy through them we may earn a commission at no extra cost to you — it never changes which product we recommend.

A VPN slows an already slow ship connection down further for four reasons that stack on top of each other. The device has to encrypt every packet leaving it and decrypt every packet arriving — extra processing work. Traffic detours through a separate VPN exit server before reaching its real destination — extra distance. That exit server can be busy with other users — extra congestion. And the tunnel wraps every packet in its own extra data, which shrinks the room left for the actual content — extra overhead.

On a fast shore line, spare bandwidth absorbs all four costs and nobody notices. A ship link usually has no spare bandwidth, so each of the four shows up as something the crew can feel: a page that won't load, a call that won't connect, a payment screen that hangs. The rest of this article breaks down which of the four you can fix yourself, and which ones just have to be lived with.

The percentage trap, and why crew WiFi breaks it

Consumer VPN blogs report the speed penalty as a percentage of a fast line, and that percentage is the wrong unit at sea. Treat all of the figures below as directional, not precise: each comes from a VPN review site's own test, not from an independent lab, and none of these outlets publish their full testing methodology.

ZoogVPN's 2026 benchmark across 30 services reports an average speed loss of 20.67 percent, with its best result at 6.26 percent. Internxt's write-up cites a Security.org speed test of 12 premium providers from February 2026 that found download-speed loss below 10 percent in the scenario Security.org tested. Windscribe's own help pages, which carry no date in the material available, state that VPNs typically cut speed by 10 to 30 percent — that figure comes from the VPN vendor itself, so read it as marketing as much as measurement.

Take the friendliest of those numbers and apply it to a shared crew line, where every off-watch engineer is on WhatsApp at the same time. Ten percent of a fast line is invisible. Ten percent of the trickle that reaches a cabin at 2000 can be the difference between a video call that connects and one that spins forever.

Throughput is how much data moves per second — it is the number a speed test reports in Mbps. Latency is different: it is the delay before data starts arriving at all, measured in milliseconds. On a ship, latency usually fails first, not throughput. A VPN's latency cost is a fixed number of milliseconds, so it does not shrink just because the bandwidth already has less to give.

This is the gap the percentage-based articles leave open. They tell you the tunnel is slower. They do not tell you at what point on a genuinely constrained link it stops being worth running.

Why does a VPN make an already slow ship connection even slower? The four costs

Each of the four costs behaves differently, and only two of them are yours to fix.

Encryption work on a device that is already struggling

A phone or laptop encrypts everything going out and decrypts everything coming in — standard math the processor has to run on every packet. How expensive that is depends on two things: the protocol (the specific method the VPN uses to build the tunnel — WireGuard and OpenVPN are two examples) and the hardware doing the work.

A recent laptop has hardware acceleration, a chip built to do encryption math quickly, and barely notices the extra load. A five-year-old phone with a tired battery notices a lot, especially if it is also fighting a weak access point (the WiFi router or antenna covering that part of the accommodation block) at the same time.

The CPU cost of moving the work to a router

Running the VPN on a travel router instead of the phone moves that encryption work onto the router. A cheap travel router has a much weaker CPU — the processing chip that runs the math — than a modern phone, so the router itself can become the bottleneck before the ship's satellite link is even the limiting factor. Check a router's throughput rating with encryption turned on, not its advertised WiFi speed, before buying one for this job. The full setup is covered in the guide on setting up a VPN on a ship's router without admin access.

The trombone: your packets take the scenic route

Without a VPN, traffic goes from the ship to wherever it is going. With a VPN, it goes from the ship to the exit server first, and only then to the destination. One network testing site calls this the trombone effect, and the name fits: the traffic slides out and comes back before going anywhere useful.

Picking a VPN exit server in Amsterdam while the ship is alongside in Singapore adds a detour across half the planet — on top of a link that already bounces off a satellite. That satellite bounce is called a satellite hop: the signal has to travel up to the satellite and back down before it reaches the internet at all.

Older maritime systems use geostationary VSAT, where the satellite sits in a fixed spot far above the equator. That distance already adds a long, unavoidable delay before the VPN adds its own detour on top — the worst case for a VPN's extra hop. Low-earth-orbit systems such as Starlink fly much closer to Earth, so the base delay is smaller and the VPN's extra hop hurts less by comparison. The specifics of that setup are in the piece on VPNs that work with Starlink Maritime.

A crowded exit server

A busy exit server cuts your throughput even when the underlying connection is fine. This is easy to diagnose wrongly, because the symptom looks identical to a bad ship link: everything slow, nothing broken. The test is boring and takes a minute. Switch to a different server in the same country, then to a different country, and see whether the number moves. If it does, the ship was innocent.

MTU: the packets that disappear without an error message

This is the one that makes people think the ship's firewall is blocking them, when it is not. Every packet of data sent over the internet has two parts: a header (routing information, like an address label) and a payload (the actual content). The VPN tunnel adds its own header to every packet, which shrinks the room left for payload inside a fixed-size packet.

The maximum transmission unit, or MTU, is the largest packet size a network link will carry. If the VPN sets that number wrong, some packets end up too big and get dropped instead of delivered, with no error message — they just disappear. The pattern is easy to spot once you know it: most of the internet works fine, and then one specific site or app hangs forever.

Web pages load. The crew portal loads. The bank site hangs. That is MTU, almost always. The same mechanism sits behind a lot of tunnel instability, which is why it shows up again in the article on what actually causes a VPN to keep disconnecting on ship WiFi.

Protocol choice moves the number more than the brand does

Pick the protocol before picking the provider. The published gaps between protocols are much wider than the gaps between well-known providers.

A 2026 protocol comparison published by Tech Insider, a VPN-comparison publication whose testbed methodology this article could not independently verify, ran a deliberately constrained cloud testbed rather than a gigabit line. Those constrained numbers are in the table below, alongside the gigabit figures from the same comparison, and both should be read as results from that one publication's test environment rather than a promise about any specific ship.

The same comparison puts protocol overhead at roughly 5.6 percent for WireGuard, 13.8 percent for IKEv2 and 25.7 percent for OpenVPN UDP in a separate evaluation. On a constrained link, overhead is not a rounding error — it is bandwidth you paid for and will never see.

OpenVPN over TCP deserves its own warning. TCP is already running inside the tunnel for most applications, so putting the tunnel itself on TCP means two layers both trying to correct the same losses. When the underlying link drops packets, and a ship link drops packets, both layers retransmit and fight each other. Keep it in reserve for ports where nothing else connects, which is the scenario covered in the guide to VPNs for ports with heavy internet restrictions.

One nuance argues against treating WireGuard as automatic. A 2025 empirical study of VPN performance in cloud environments, published through Glasgow Caledonian University's research repository, found WireGuard well ahead on raw TCP throughput in VMware, at 210.64 Mbps against 110.34 Mbps for OpenVPN, with lower packet loss. In Azure, the same study reported similar baseline throughput between the two, and OpenVPN actually performed better under one high-latency condition. High latency is the daily reality at sea, so it is worth testing both protocols on the actual link before deciding.

If you are choosing a provider for ship use

The provider matters less than the protocol. What to check is whether it offers a WireGuard-family protocol and lets you choose the exit server yourself. Several well-known services do, including NordVPN and Surfshark, named here without a link because the figures attached to them below come from third-party comparison sites, not from this site's own testing.

VPN Adviser, a VPN-comparison publication whose material carries no publication date and whose methodology this article could not independently verify, ran same-region tests on a 500 Mbps line and reported NordVPN on NordLynx at around 94 percent of baseline and Surfshark on WireGuard at around 88 percent. TrueScho's 2026 write-up, also a VPN-comparison publication, reports NordLynx holding about 88 percent of baseline on a separate 250 Mbps line. Those two sources disagree about the same protocol on different lines, which is a reminder of how much weight to put on any single third-party benchmark when the actual ship link looks nothing like either test bench.

Measure your own penalty in ten minutes

Do this once, on the link actually in use, at the hour it is actually used.

1. Run a speed test with the VPN disconnected and write down download speed, upload speed and ping. Not a screenshot — a written number, because the test gets run again.
2. Connect the VPN to the nearest available exit and run the identical test. Record the same three numbers.
3. Repeat both tests at a different hour, ideally once during the evening rush and once early morning, because a shared crew link behaves differently at 2300 than at 0600.
4. Compare the ping first, then the download. If ping jumped hard and throughput barely moved, the problem is server distance. If throughput collapsed and ping held, suspect a congested exit.
5. Try a second exit server before concluding anything about the ship itself.

These tests measure the difference between two conditions; they do not identify the cause on their own. Combine them with the symptom patterns above and the right culprit usually turns up within a few minutes.

When to leave the VPN switched off

Sometimes the honest answer is that the tunnel costs more than it is worth on that particular link.

A metered quota is the clearest case. If the ship sells data by the megabyte, the tunnel's overhead is billed like any other traffic, and on OpenVPN that overhead is substantial. Every byte of protocol header comes out of the allowance saved for a video call home. The realities of those allowances are laid out in the breakdown of what crew actually get for monthly WiFi data.

Voice and video calls on a high-latency link are the second case. Latency added by a distant exit server cannot be recovered, and real-time audio is the application least able to absorb it. If calling home is the only thing the connection needs to do, connect without the tunnel, use an app that handles satellite delay gracefully, and switch the VPN back on afterwards for browsing. How different calling apps handle that kind of delay is covered in the rundown of VoIP apps that survive satellite latency.

The third case is the one people argue about. On genuinely hostile port WiFi, the privacy the VPN gives you is worth a slower connection, full stop. Losing a chunk of speed beats handing credentials to whoever set up an open network in the seafarers' centre.

FAQ

Does a VPN slow down a satellite connection more than a normal one?

It costs you more in practice, yes. The percentage penalty is not inherently larger, but satellite links already carry high latency and limited capacity, so the same absolute milliseconds and the same protocol overhead hurt more. A distant exit server on a geostationary link is the worst combination, because you are adding a long detour on top of an already long hop.

Which VPN protocol is fastest on a slow ship link?

WireGuard is the right default. A 2026 comparison published by Tech Insider measured 22.9 Mbps for WireGuard against 8.7 Mbps for OpenVPN TCP in a constrained testbed, and put WireGuard's protocol overhead at roughly 5.6 percent against 25.7 percent for OpenVPN UDP. Treat those numbers as one publication's test, not a guarantee. Test IKEv2 as well if you switch often between cabin WiFi and port cellular.

Why do some websites hang completely while others load fine on my VPN?

That pattern almost always points to a maximum transmission unit (MTU) problem rather than to bandwidth. Packets above the working size get dropped instead of delivered, with no error message, so anything that sends large packets stalls while small requests go through. Lower the tunnel MTU in your VPN client in small steps until the hangs stop.

Should I run the VPN on my phone or on a travel router in the cabin?

Run it on whichever device has more processing power to spare, and that is usually the phone. A router covers every device at once, which is convenient, but a cheap travel router's weak processor will become the bottleneck long before the ship's link does. If the router route matters to you, check its throughput rating with encryption enabled rather than its headline WiFi speed.

Will a faster VPN plan fix a slow ship connection?

No. A VPN server cannot add capacity to the link between the ship and shore. A better provider or a closer server can reduce the amount the tunnel takes away, and that is the whole of what it can do. If the underlying connection is the problem, the fixes live at the ship's end, and the practical ones are collected in the guide to making the most of slow crew WiFi.

Verdict

Run WireGuard, pick the closest exit server that does the job, check the MTU the first time a site hangs, and measure the penalty on the actual link instead of trusting a benchmark run on a gigabit line ashore. Do those four things and the tunnel costs a slice of a slow connection rather than most of it. Skip them and it is easy to spend a contract believing the ship's satellite is broken when the real answer to why does a VPN make an already slow ship connection even slower was sitting in the app's settings screen the whole time.

About these numbers

None of the speed figures in this article come from tests run by this site — there is no in-house lab, and a VPN benchmark run ashore on a fast line tells you very little about a ship. Every figure here is attributed to the outlet that published it and, where the outlet gave one, the date. Where a source gave no date, that is stated plainly rather than left implied. Two of the provider comparisons in this article (VPN Adviser and TrueScho) disagree with each other on the same protocol, which is included deliberately, because a single number presented without that disagreement would look more certain than the underlying evidence supports.

Related reading

• VPN Keeps Disconnecting on Ship WiFi: Fix It in 10 Min
• VPN That Works With Starlink Maritime: Tested Setups
• Connectivity at Sea in 2026: What It Costs, and What You Can Actually Buy Yourself