Why your VPN is slow, in five checks
Measure first: run a speed test with the tunnel down, then up, against the same server. A loss of ten to thirty percent on a nearby server is normal. Anything worse points at distance, a congested server, an MTU problem, the wrong protocol or a line that was already slow.
4 min read
Before diagnosing anything, get a baseline. Run the speed test with the VPN off, note download, upload and latency, then run it again with the tunnel up to the same server. Without those two numbers every conclusion below is a guess.
A tunnel costs something. The honest range on a nearby server is roughly ten to thirty percent of throughput, plus the round trip to the server in latency. If your numbers are in that band, nothing is wrong and the rest of this article will not help.
Check one: distance
Latency is the floor set by physics. Light in fibre travels about 200,000 kilometres per second, and real paths are not straight, so a round trip to a server 8,000 km away costs at least 80 milliseconds and usually 150.
That matters for throughput as well as responsiveness, because protocols that wait for acknowledgements move less data per unit time as latency rises. A tunnel to another continent can halve your throughput without anything being misconfigured.
Pick the nearest server on the server list and retest. If the numbers jump, distance was the answer.
Check two: server load
A shared server with many active users divides its capacity among them. Peak evening hours in a popular region are noticeably worse than the same server at 06:00.
Test by connecting to a second server in the same country and comparing. If the neighbour is much faster, the first one was busy. Providers that publish load figures make this a glance rather than an experiment.
Check three: MTU
This one does not look like a speed problem. Small requests are fine, latency is fine, and then large transfers stall or crawl.
The cause is a path MTU black hole: a packet too large for the tunnel is sent with the don't-fragment bit set, the router that cannot forward it is supposed to send back an ICMP message with the correct size, and that message is dropped somewhere. Nothing learns anything, and the large packets vanish.
Set the tunnel MTU to 1412, or 1280 to test. If throughput recovers, walk it back up until it breaks again and subtract 20.
Check four: the protocol
WireGuard is faster than OpenVPN in most conditions, and the gap widens on hardware without AES acceleration — phones, tablets, streaming sticks, cheap routers. ChaCha20-Poly1305 is designed to be fast in software, which is exactly what those devices need.
If your client offers a choice and you are on OpenVPN, switch and retest.
Also check the transport: OpenVPN over TCP is markedly slower than over UDP, because a reliable protocol carrying another reliable protocol produces two retransmission timers interfering with each other. TCP mode exists to get through restrictive networks, not for speed.
Check five: your own connection
Bufferbloat is the most commonly missed cause. Run a latency test while a download is running. If latency climbs from 20 ms to 300 ms under load, your router is over-buffering, and the VPN inherits the problem plus adds its own round trip.
Smart queue management on the router — cake or fq_codel on OpenWrt — fixes
it, and improves everything else on the line at the same time.
Also check Wi-Fi. A 2.4 GHz connection in a crowded building can cap you well below your line speed with or without a tunnel. Test wired at least once so you know which layer you are measuring.
Things that are not the cause, despite being blamed
- Encryption overhead on a modern CPU. A phone from the last five years encrypts a gigabit of ChaCha20 without noticing. Encryption is the bottleneck on routers and old hardware, rarely on anything else.
- The protocol's header size. It costs a few percent, not half.
- "The VPN is throttling you." Providers that shape traffic usually say so. A sudden cliff at a round number is worth asking about; a general slowness is almost always one of the five checks.
A quick decision table
| Symptom | Likely cause |
|---|---|
| Latency up a lot, throughput down proportionally | Distance |
| Fine at 06:00, poor at 21:00 | Server load |
| Small requests fine, large transfers stall | MTU |
| Slow everywhere, on every server, on OpenVPN | Protocol or transport |
| Latency triples during a download | Bufferbloat on your line |
| Slow with the VPN off too | Not the VPN |
Work down it in order. The first four are fixed by changing a setting; the last two are fixed at home, and no VPN configuration will touch them.
