Why Is My VPN So Slow? Work Through It In This Order

Almost nobody has a slow VPN. What they have is a slow path, and the VPN is the most visible thing standing on it. There are four causes worth checking and they are not equally likely, so the order you check them in decides whether this takes five minutes or an evening.

Work down the list. Stop when the number changes.

Step zero: measure the thing you are comparing against

Run a speed test with the VPN off and write the number down. Then run the same test, from the same device, on the same wifi, against the same test server, with the VPN on. Two numbers taken ten minutes and three variables apart are not a comparison, and most "my VPN halved my speed" reports turn out to be a phone that quietly moved to the 2.4GHz band.

While you are here: if the no-VPN number is already well below what you pay for, the VPN is not your problem and nothing below will help.

Cause 1: the server is too far away

This is the answer roughly half the time and it is the easiest to test. Connect to the nearest server your provider offers — the same city if possible, the same country otherwise — and measure again.

Distance costs you in two different currencies:

• Latency is physics. Light in fibre covers about 200km per millisecond, and the route is never a straight line. A server on another continent adds 150–300ms to every round trip and there is no setting that repeals this.
• Throughput suffers because of latency, not instead of it. TCP ramps up its sending rate based on how quickly acknowledgements come back, so a long round trip caps a single connection's speed even when the pipe is empty. This is why a 500Mbps line can deliver 40Mbps to a single download on the far side of the world.

If the nearby server is fast and the distant one is not, you have not found a fault. You have found geography. Choose a closer exit for everyday use and only reach for the distant one when the whole point is to be somewhere else.

Cause 2: the MTU is wrong

This is the one that produces the strangest symptoms: speed tests look fine, but large downloads stall, some sites never finish loading, and video buffers at a quality your connection should laugh at.

Every packet on your network has a maximum size — the MTU, usually 1500 bytes on ethernet. A VPN wraps your packet inside another packet, and the wrapper needs room. WireGuard typically leaves about 1420 bytes for your data; OpenVPN a little less. If your device keeps sending 1500-byte packets, each one must be fragmented or dropped, and the retries are where your throughput goes.

It usually works itself out via path MTU discovery, which relies on ICMP messages coming back to say "too big". Plenty of networks — hotels, mobile carriers, over-enthusiastic corporate firewalls — drop ICMP entirely. Then discovery fails silently and you get the black-hole behaviour above.

To test, ping with the don't-fragment flag set and shrink the payload until replies come back:

# macOS / Linux
ping -D -s 1400 1.1.1.1

# Windows
ping -f -l 1400 1.1.1.1

Whatever payload size succeeds, add 28 for the IP and ICMP headers to get your working MTU. Most VPN clients expose an MTU field in advanced settings; 1400 is a safe manual value, and 1280 will work almost anywhere at a small cost in efficiency.

Cause 3: the server is busy

Shared VPN servers are shared. A popular exit in a popular city at nine in the evening is carrying everybody else's evening too.

Most clients show a load percentage per location. If yours does, avoid anything above about 70%. If it does not, test three servers in the same country — if one is dramatically faster than the others, you have your answer, and it is not a permanent one. Re-test at a different hour before concluding anything about the provider.

This is also where "unlimited bandwidth" earns its place in the marketing. Unlimited bandwidth means nobody caps your monthly total. It says nothing at all about how much of the server's capacity is available to you at the moment you want it.

Cause 4: the route, or the protocol, is bad

Two separate faults with a similar smell.

The route problem: your ISP's path to that particular VPN data centre is congested or oddly chosen, even though both ends are healthy. Traffic from Europe that transits North America to reach a European server is not unheard of. You cannot fix this, but you can route around it by picking a different city — sometimes a further one is faster, which is the tell.

The protocol problem is more actionable. If you are on OpenVPN over TCP, move to UDP, or move to WireGuard. TCP inside TCP is a genuinely pathological combination: both layers detect the same lost packet, both retransmit, both back off, and throughput collapses under any packet loss at all. TCP mode exists to get through networks that block UDP, and it should be a last resort rather than a default.

A reasonable order to try: WireGuard, then OpenVPN over UDP, then OpenVPN over TCP 443 only if the first two cannot connect at all. There is more on the tradeoff in WireGuard vs OpenVPN.

The things that are almost never the cause

• Encryption overhead. Every phone and laptop made in the last decade has hardware AES; ChaCha20 is fast without it. The CPU cost is real on a €30 router and irrelevant everywhere else.
• Your antivirus. Occasionally true, rarely worth the reinstall.
• The provider "throttling" you. Possible, unfalsifiable, and almost always actually cause 3.

One that is worth knowing: some ISPs shape or de-prioritise traffic they cannot classify, and a VPN tunnel is by definition unclassifiable. If your VPN is consistently slow on one network and consistently fine on another, with the same server and protocol, that is the shape of it. Testing at 3am is the crude confirmation — shaping usually relaxes off-peak.

The five-minute version

1. Measure without the VPN. Same device, same network, same test server.
2. Connect to the closest server and measure again.
3. Switch to WireGuard if you are not already on it.
4. Set the MTU to 1400 if large transfers stall while small ones are fine.
5. Try two other servers in the same country to rule out load.

If all five are clean and it is still slow, the honest conclusion is usually that the distance you need is the distance you are paying for in milliseconds. A tunnel cannot be shorter than the ground it crosses — which is roughly the point of Notes from the Underground Network.

Questions people actually ask