Why Your VPN Makes Your Internet Slower

If you buy through our links, we may earn a commission. It never affects our verdicts or scores — how that works. As an Amazon Associate I earn from qualifying purchases.

Three things slow a VPN down, and the one everybody blames is the smallest. In rough order of how much they cost you: how far away the server is, which protocol you are using, and how busy that server is. Encryption is a rounding error next to the other two.

Distance, which is the big one

A VPN does not shorten your route. It lengthens it. Your traffic goes to the VPN server first and reaches the site afterwards, so a request that used to travel across your city now travels to wherever you chose and back out again.

If you are in London reading a London website through a server in Los Angeles, every click makes two Atlantic crossings that were not there before. No amount of bandwidth fixes that, because it is not a bandwidth problem — it is distance, and distance costs time at the speed of light.

This is why the single most effective thing you can do is pick a nearer server, and why “fastest server” buttons mostly just mean “closest”.

Protocol, which is a setting

This is the one people never look at, and it is a dropdown in your VPN app.

The WireGuard project published a comparison of tunnel protocols on the same hardware:

Protocol	Throughput	Ping
WireGuard	1,011 Mbps	0.403 ms
IPsec (AES-GCM)	881 Mbps	0.508 ms
IPsec (ChaPoly)	825 Mbps	0.521 ms
OpenVPN	258 Mbps	1.541 ms

OpenVPN moved a quarter of what WireGuard did on the same machine, and took nearly four times as long to answer. If your app is set to OpenVPN and offers WireGuard, that is the whole fix.

A caveat that belongs with those numbers, and which most articles quoting them leave off. The project labels its own benchmarks “old, crusty, and not super well conducted”, notes that both WireGuard and IPsec “have gotten faster” since, and says replacing them is a work in progress. It stands by one part: “OpenVPN remains extremely slow.”

Treat the table as the shape of the difference rather than figures you will reproduce. The shape is not in dispute; the decimal places are.

Server load, which you cannot see

The third cause is the one no dashboard shows you. A commercial VPN server is shared, and its capacity is divided among everyone connected to it at that moment.

This is why the same server is fine on Tuesday morning and unusable on Sunday evening, and why “switch servers” fixes things that look like faults. If a nearby server is slow and a slightly further one is fast, you have found congestion rather than distance.

The check that separates the three

Two minutes, and it tells you which of the three you have.

Speed test with the VPN off. This is your ceiling. Nothing below can beat it.
Turn the VPN on, nearest server, and test again. The gap between this and step 1 is protocol plus that server’s load.
Try a second nearby server. If it is much faster, step 2 was congestion, not the protocol.
Now test a deliberately distant server. The extra drop is distance, and it is the part you cannot engineer away — only avoid.

What to actually do

Choose the nearest server that does the job. If you need a specific country, nearest within that country. Distance is the dominant cost and it is free to avoid.
Switch the protocol to WireGuard if your provider offers it. It is usually one dropdown, and it is the largest single improvement available to most people.
Change servers before you blame the provider. Congestion looks exactly like a slow service and is fixed by a different button.
Do not buy a faster broadband plan to fix VPN speeds. Same mistake as with Wi-Fi — a bigger pipe does nothing about a longer route. If your line itself is the suspect, why your Wi-Fi is slower than the speed you pay for has the test that settles it.
Expect to lose something. A VPN that costs you nothing at all is doing less than you think. The goal is a cost small enough to forget, not zero.