Why Your Internet Is Slower On a VPN
Short answer
Your traffic detours via the VPN server, so distance sets a floor you cannot beat. Switch to the nearest server and to the WireGuard protocol first — those two changes fix most complaints. If speed is still poor on a nearby server, the cause is server congestion, an MTU mismatch, or your connection being slow with the VPN off too.
On this page
Some of the slowdown is not fixable, and it is worth separating that part out before you spend an evening changing settings.
Your traffic is taking a longer route. A request that went from your house to a server fifty kilometres away now goes to a VPN server, possibly in another country, and then onward. The return trip makes the same detour. No protocol, provider or setting removes that, because the limit is how fast light moves through fibre.
What is fixable is everything else, and in practice two changes fix most complaints.
Two minutes of triage
Run a speed test twice: once with the VPN off, once with it on and connected to the nearest available server. Write both numbers down.
| What you see | Likely cause | Go to |
|---|---|---|
| Both slow | Your connection, not the VPN | It was already slow |
| VPN within ~10% of normal | Working correctly | Nothing to fix |
| VPN much slower, nearby server | Congestion, protocol or MTU | The three real causes |
| VPN much slower, distant server | The detour | Change server |
| Some sites fine, others stall | MTU mismatch | Packet size |
That last row is the one people misdiagnose most often. It is not a speed problem at all, and no amount of server switching fixes it.
Change these two settings first
The server. Pick the closest location your provider offers, not the one the app selected and not the one with a flag you like. Latency scales with physical distance, and latency is what makes browsing feel slow even when raw throughput looks fine.
If you need a specific country, pick the city in that country nearest to you. A connection to the near side of a country is meaningfully faster than one to the far side.
The protocol. In the client’s settings, usually under Protocol or Connection:
- WireGuard — pick this unless it fails. Small, efficient, fast to connect.
- IKEv2 — good fallback, handles network changes well.
- OpenVPN (UDP) — slower, but works where the others are blocked.
- OpenVPN (TCP) — slowest by a clear margin. Only when UDP is blocked.
If your client is set to “Automatic”, it may have chosen OpenVPN over TCP because UDP failed once on a network you are no longer using. Set it explicitly and test.
The difference between WireGuard and OpenVPN over TCP on the same server is frequently larger than the difference between any two providers.
The three causes worth chasing
Server congestion
A VPN server has finite capacity shared among everyone connected to it. Popular locations, the obvious big-city choices, fill up at peak times.
The tell is a daily pattern. Fast in the morning, poor from about seven in the evening, fine again late at night. Some clients show a server load percentage; where they do, use it.
The fix is to pick an unfashionable city in the same country. Traffic routes are rarely so different that this costs you anything, and the server is far less busy.
Protocol forced to TCP
OpenVPN over TCP carries TCP connections inside a TCP connection, which creates a known pathology: when the outer connection retransmits a lost packet, the inner one is also retransmitting, and the two back off against each other. On a connection with any packet loss this collapses throughput badly.
If your client has fallen back to TCP, it is because UDP is blocked somewhere. Try WireGuard explicitly. If it fails, you are on a network that filters, and TCP is the price of connecting at all.
Extra hops you enabled
Multi-hop, double VPN and obfuscation features each add a server or a layer of processing. They are doing what they advertise; they cost what you would expect. Turn them off and retest before concluding anything else is wrong.
The MTU problem that looks like slowness
Distinctive symptom: most of the internet works, a handful of sites hang at a blank page forever, and large file transfers stall at a few percent while small requests complete instantly.
Encapsulation makes every packet larger. A packet that exactly filled the link’s maximum size before now needs to be split, and where the path mishandles that splitting, the oversized packets disappear without any error. Small packets keep flowing, which is why some things work perfectly.
Lower the MTU in the client’s advanced settings. Try 1400 first, then
1380. On WireGuard configurations the setting is often an MTU = line in
the config file. What the tunnel is actually
doing covers why the number changes.
When the VPN is not the problem
If the speed test with the VPN off was already poor, stop troubleshooting the VPN. You are measuring your connection, and the tunnel is only making a slow line slightly slower.
Common causes have nothing to do with VPNs: a weak Wi-Fi signal, a congested 2.4GHz band, an old router, or an evening contention problem on your provider’s network. Slow Wi-Fi despite a strong signal covers the diagnosis, and it is worth doing first because every VPN measurement you take afterwards will otherwise be wrong.
On a router-level VPN there is one extra suspect: the router’s own processor. Consumer routers are poor at encryption, and a fast line through a cheap router’s VPN client is bounded by that chip rather than by anything else. Whether a router VPN is worth it goes through the arithmetic.
Measuring it properly
Most speed complaints are based on one test at one moment, which is not enough to draw a conclusion from. A few minutes of better measurement saves an evening of changing settings at random.
Run each test three times and take the middle result. Single tests vary enough that two measurements differing by a third may be telling you nothing.
Test the same server location each time while you are comparing settings. A result from a London server and one from a New York server are not a comparison of protocols, however tempting that reading is.
Watch latency as well as throughput, because it is what browsing actually feels like. A connection with high throughput and 200ms of latency feels sluggish on every page load, while one with modest throughput and 15ms feels immediate. Server distance moves latency far more than it moves throughput.
Finally, test from a wired connection where you can. A Wi-Fi measurement includes whatever your Wi-Fi is doing that minute, which on a congested 2.4GHz band is a great deal.
What does not help
- Reconnecting repeatedly. It may move you to a less busy server, which is worth one or two attempts and not ten.
- Paying for a “premium” or “gaming” server tier. Unless it reduces the physical distance, it does not change the thing that dominates.
- Disabling encryption, where a client allows it. Removes the entire point while saving almost nothing, because modern processors do AES in hardware.
- Changing DNS servers. Affects the lookup at the start of a connection, not throughput. Worth doing for other reasons; not this one.
Realistic expectations
On a nearby server with WireGuard, expect to lose a few percent of your throughput and to gain a few milliseconds of latency. On a well-provisioned server you may not be able to tell the VPN is on during normal browsing.
Across an ocean, expect latency to roughly double or worse, and throughput to fall substantially on connections that depend on round trips. That is the detour and it is permanent.
The honest limit: if you need a server in a distant country for a specific reason, you are choosing to pay the latency. No provider has solved geography, and any marketing claiming otherwise is describing their server count, which is a different thing entirely.