Why Your VPN Slows Everything Down

Encryption is rarely the reason a VPN is slow on modern hardware. Distance, a busy exit server and MTU are — and MTU is the one that makes some sites hang forever while everything else works.

Every VPN costs you something. The question is what, and how much of it you can get back.

The usual explanation — "encryption is slow" — is the least useful one. Modern processors have dedicated AES instructions and encrypt at multiple gigabits per second while barely registering on a CPU graph, so on a reasonably current laptop or phone it is not what you are noticing.

It is not never, though. Encryption becomes a real ceiling on a low-power router terminating the tunnel itself, on older mobile hardware without crypto acceleration, and on multi-gigabit lines where even efficient software cannot keep up. If your VPN caps at a suspiciously round figure and the device gets warm, look at the CPU. For everyone else the causes below matter far more.

The real causes are less obvious, and one of them produces a symptom so specific it is worth recognising on sight.

Measure the cost

Run the connection test with the VPN off, then on. Compare latency and jitter, not just throughput.

Run the connection test →

The four real causes

1. Distance — usually the largest

Your traffic no longer goes straight to its destination. It goes to the VPN server first, then onward.

Connect from London to a server in Singapore and every request travels to Singapore and back before reaching anything. That is a physical cost, bounded by the speed of light in fibre — roughly 200 km per millisecond, and real routes are never straight.

This is why choosing the nearest server usually matters more than any other setting. If you do not need a specific country, do not pick a distant one.

2. A busy exit server

You share that server with everyone else connected to it. At peak times a popular endpoint can be the bottleneck regardless of how fast your own connection is.

This is the easiest thing to test: switch to a different server in the same region. If throughput improves substantially, the first one was congested — nothing about your connection changed.

3. MTU and fragmentation — the one that breaks things oddly

The most technically interesting cause and the one that produces the strangest symptoms.

Every network path has a maximum transmission unit — the largest packet it will carry. Ethernet is typically 1500 bytes. A VPN wraps your packets in its own headers, so the space left for your data shrinks, often to somewhere around 1380–1460 bytes depending on the protocol.

If something sends a packet too large for the tunnel, one of three things happens:

• It gets fragmented — split and reassembled, which costs throughput and CPU.
• The sender is told to send smaller packets, via an ICMP "fragmentation needed" message, and adapts. This is Path MTU Discovery working correctly.
• That ICMP message is blocked, the sender never learns, and the oversized packets vanish silently.

That third case is the notorious one, and it has a distinctive signature:

Small requests work perfectly. DNS resolves. Pings succeed. Short pages load. But any page with substantial content hangs forever and eventually times out — and only some sites are affected.

VPN connected but some websites will not load

This is an MTU black hole. The connection establishes because the handshake packets are small; it stalls the moment a full-size data packet is sent. If you have ever had a VPN where "most of the internet works but a few sites just spin", this is almost certainly why.

4. Protocol and routing overhead

Different VPN protocols carry different overhead, and some behave much better than others on lossy links. TCP-based VPNs in particular suffer badly when the underlying connection loses packets, because you end up with reliable transport inside reliable transport — each retransmitting independently, amplifying the delay. Where a provider offers a UDP option, it is usually the faster choice.

There is also routing: your provider's path to a destination may simply be worse than your ISP's, and occasionally better. That is a routing question rather than a VPN one, and an MTR with and without the tunnel will show it.

Finding your working MTU

If you suspect MTU, this test finds the true limit. It sends packets that must not be fragmented, starting large and reducing until they get through.

Windows:

ping -f -l 1472 1.1.1.1

macOS:

ping -D -s 1472 1.1.1.1

Linux:

ping -M do -s 1472 1.1.1.1

The size given is the payload, excluding 28 bytes of IP and ICMP headers. So 1472 + 28 = 1500, a standard Ethernet MTU.

Run it with the VPN connected, and make sure the destination actually routes through the tunnel — with split tunnelling, or a provider that excludes certain addresses, you may be measuring your ordinary connection instead and getting a reassuring answer that means nothing. tracert or traceroute to the target will show whether the first hop is the tunnel.

If it fails with "packet needs to be fragmented" or similar, reduce the size — try 1400, then 1300 — until it succeeds. Then work upward to find the largest that passes. Worth repeating against a second destination if the number looks surprising: what you are measuring is the path MTU to that host, and a single unusual route can mislead you.

1472  fails      →  too big for the tunnel
1400  fails
1372  succeeds   →  working MTU = 1372 + 28 = 1400

Set your VPN client's MTU to that figure. Most clients expose it; WireGuard configurations take an MTU = line in the interface section, and OpenVPN uses tun-mtu.

If you cannot set it, mssfix (OpenVPN) or clamping MSS at the router achieves much the same by telling each end to use smaller segments from the outset. Note the limit: MSS clamping only affects TCP. Oversized UDP — QUIC, video calls, game traffic, DNS over UDP — is untouched by it, so clamping can fix web browsing while leaving those still broken. Setting the interface MTU properly is the complete fix; clamping is the workaround when you cannot.

What to try, in order

1. Choose a closer server. Largest single improvement in most cases, and free.
2. Try a different server in the same region. Isolates a congested endpoint from everything else.
3. Switch protocol — prefer UDP where offered; WireGuard is generally faster than older options.
4. Test MTU using the method above, particularly if some sites hang while others are fine.
5. Test wired. Wi-Fi and VPN overhead compound, and Wi-Fi is frequently the larger part.
6. Check the connection without the VPN. If loss or jitter is already present, the VPN is amplifying an existing problem rather than causing one.

How to measure what your VPN actually costs

A single before-and-after pair proves less than people assume, because normal variation between runs can be larger than the effect you are trying to see.

Change one thing at a time, and hold everything else still:

1. Wired, nothing else running. Wi-Fi variability alone can swamp the VPN's contribution.
2. Run the connection test with the VPN off. Note latency, jitter and loss — not just throughput.
3. Connect the VPN and run the identical test, same server region, same time of day.
4. Repeat both, three to five times each, alternating. One run of each tells you very little.
5. Compare the medians, and compare all four numbers rather than the download figure alone.

What the four numbers tell you: added latency is mostly distance to the exit; a large jitter increase suggests a loaded server or a poor path rather than the tunnel itself; new packet loss that was not there before points at the provider's network; and throughput falling much further than the table below suggests something is misconfigured.

If loss or jitter is already present with the VPN off, fix that first — a tunnel amplifies an existing problem and you will otherwise spend the afternoon blaming the wrong thing. The same goes for bufferbloat, which a VPN makes worse rather than causes.

How much slowdown is normal

Rough expectations for a well-configured setup on a healthy connection. These are illustrative rather than benchmarks — the real figures depend on your line, the provider, the protocol, the route and the device:

If you are losing far more than the first two rows with a nearby server, something is probably misconfigured rather than inherent. Read the table in that direction only: a heavy loss is a reason to investigate the exit server, not proof that it is congested.

Note the last row is not really a slowdown at all. It is a partial failure that gets described as slowness, which is why it goes undiagnosed for so long.

When the VPN is faster

Occasionally a VPN improves things, and it is worth understanding why so you can tell whether yours will.

If your ISP routes badly to a particular destination — a congested peering link, a circuitous path — a VPN whose provider has a better route can genuinely beat it. This is real, but specific to that destination, and it is also one of the signals people misread as evidence of throttling.

Test it rather than assume it: MTR to the destination with and without the tunnel, and compare where the latency accumulates.

Frequently asked questions

Why is my VPN so slow?

Most often distance to the server or a congested exit server, not encryption — modern processors handle encryption without meaningful cost. Choose a nearer server, try a different one in the same region, and prefer UDP-based protocols.

Does encryption slow down a VPN?

Rarely by much on modern hardware — processors have dedicated AES instructions and encrypt at multi-gigabit speeds. It can matter on a low-power router terminating the tunnel, on older phones without crypto acceleration, and on multi-gigabit connections. On a current laptop or phone it is not what you are noticing.

Why do some websites not load at all when my VPN is connected?

An MTU problem is the strong suspect when small requests work and larger pages consistently stall — filtering, routing, or a fault at the destination can produce similar-looking results, but rarely with that split. The tunnel reduces the space available for your data, and if oversized packets are dropped without the sender being told, connections establish and then stall on the first full-size packet. Small requests work; large ones hang.

What MTU should I use for my VPN?

Find it rather than guess: send unfragmented pings of decreasing size until they succeed, then add 28 bytes for headers. Typical working values fall between 1400 and 1460, but it depends on your protocol and path.

Is WireGuard faster than OpenVPN?

Generally yes. It has a smaller codebase, more modern cryptography and less per-packet overhead, and it usually shows lower latency. How much depends on the device, the network and the server — treat it as the better default rather than a guaranteed margin.

Should I use TCP or UDP for my VPN?

UDP where possible. TCP-based tunnels carry reliable transport inside reliable transport, so on a lossy link both layers retransmit independently and delay compounds badly. TCP mode is mainly useful for getting through restrictive firewalls.

Can a VPN ever make my connection faster?

Yes, though it is uncommon. If your ISP has a congested or roundabout path to a specific destination and your provider has a better one, the tunnel can win for that destination. It will not increase your line's capacity.