Why is my VPN slow? Distance, overhead, MTU and the path

A VPN is slow for one of five reasons, and they are easy to tell apart once you measure. Distance: every packet now travels to the VPN server and back, and if the server is far away every connection pays for it. Loss on the path: TCP slows down sharply when packets go missing, and longer paths give it more chances to. CPU: encryption costs processor time on the client and the server, and a small server or an old router hits a ceiling. MTU: wrapped packets no longer fit, some get dropped silently, and certain sites hang while others are fine. And the network in between: an ISP that routes your traffic to the server badly, throttles traffic it does not recognise, or is simply congested in the evening. A speed test with the VPN off and on, a ping to the server, one MTU test and one mtr run will tell you which.

The rest of this post is how to run those tests, how to read them, and what fixes each cause - including the honest answer when the fix is "a server closer to you", which no setting will ever replace.

Measure before you change anything#

Change one thing at a time, and start with numbers. Five measurements cover almost every case:

1. A speed test with the VPN off, to a test server near the VPN server's location.
2. The same test with the VPN on.
3. ping to the VPN server's address with the VPN off, for a minute, noting the average and the loss.
4. mtr (or WinMTR, or pathping on Windows) to the VPN server's address, also with the VPN off.
5. A large-packet ping test for MTU, described below.

Test with the VPN off against a server near the VPN server, not near you. Otherwise you are comparing a short path with a long one and blaming the tunnel for the distance.

Distance and why it costs more than latency#

Light in fibre covers about 200 km per millisecond, so every 1,000 km of path adds about 10 ms of round trip before any equipment touches the packet. Real routes are longer than the straight line. Latency, jitter and packet loss has a table of realistic figures from various cities to Frankfurt.

Latency does not only make things feel sluggish. It limits how fast a single TCP connection can go when there is any packet loss at all. A useful rough model (the Mathis formula, for classic congestion control) says a TCP connection's throughput is at most about the segment size divided by the round-trip time times the square root of the loss rate.

Treat these as an illustration of the shape, not a prediction: modern congestion control such as BBR is much less sensitive to random loss, and browsers open several connections at once. The lesson holds anyway. Doubling the distance to your VPN server roughly halves what a lossy line can carry per connection, which is why a VPN that is fine in the morning can feel broken on a busy evening.

A VPN adds distance whenever the server is not on the way to where you are going. If you are in Berlin and the site is in Frankfurt, a VPN in Frankfurt costs almost nothing. If the site is in Berlin too, every packet now goes to Frankfurt and back.

Protocol overhead and encryption cost#

Every VPN adds headers to each packet. The cost in bandwidth is small:

If your VPN is 5% slower than your line, that is overhead and there is nothing to fix. If it is 50% slower, it is something else.

Encryption costs CPU, and the cost scales with throughput. Phones and laptops from the last several years encrypt hundreds of megabits per second without trouble. The weak points are old routers running a VPN client, cheap single-board computers, and small servers. On the server side the cost is per byte across every device connected, so a server shared by a household at the same moment needs more CPU than one used by a single phone.

You can see a CPU ceiling in the numbers: the throughput stops at the same figure no matter how fast the line is, and the CPU graph for the client or server sits at its limit while the test runs. On a hosted server with a hard CPU limit, that limit is the ceiling; more line speed will not help, a larger plan will.

MTU: when some sites hang and others are fine#

The classic MTU symptom is odd enough to be diagnostic on its own: the VPN connects, small things work, and certain sites or large downloads stall forever. What is happening is that wrapped packets are now bigger than some link on the path allows, the packets that are too big are dropped, and the message that should tell the sender to use smaller ones (ICMP "fragmentation needed") is blocked by a firewall somewhere. Small packets get through, large ones vanish.

Ethernet's standard MTU is 1,500 bytes. PPPoE connections, common on DSL and some fibre, have 1,492. Mobile networks and some tunnels have less. WireGuard's tools default the tunnel MTU to 1420 on the assumption of a 1,500-byte path and IPv6 overhead; on a PPPoE line 1,412 or lower is safer.

Find the largest packet that passes without fragmentation. The payload size plus 28 bytes (20 IP header, 8 ICMP header) is the path MTU.

Windows:  ping -f -l 1472 1.1.1.1Linux:    ping -M do -s 1472 1.1.1.1macOS:    ping -D -s 1472 1.1.1.1

If 1472 fails with a "needs to be fragmented" or "message too long" error, lower the size until it passes. 1464 passing means a path MTU of 1,492, the PPPoE value. Then set the tunnel MTU to the path MTU minus the VPN's overhead.

Xray-based connections are much less affected by this than WireGuard or OpenVPN, because they proxy TCP streams rather than wrapping IP packets: each end uses TCP's own segment sizing against the real path. Clients running in VPN or TUN mode still have a virtual interface with an MTU setting, and an unusually high value there can cause trouble with UDP applications; the defaults are sensible, so leave them unless you have a measured reason.

The network in between#

Often the tunnel is fine and the road it runs on is not.

ISP routing. Your ISP decides how your traffic reaches the VPN server's network, through which transit providers and which exchange points. A poor route can add 30 ms and a congested link on the way. mtr shows where latency jumps and where loss begins; reading traceroute and mtr explains how to tell real loss from a router that simply deprioritises replies to probes.

Evening congestion. Residential networks are sized for average use, and the evening peak is when links between providers fill up. A VPN that is slow from 8 pm to 11 pm and fine at noon is almost always a congested link on the path, not the server.

Shaping and throttling. Some networks deliberately slow traffic they classify as VPN, or international traffic in general. Comparing a VPN that looks like a VPN with one that looks like ordinary HTTPS on the same line is a good test: if the disguised one is faster, something on the path is treating protocols differently.

Your own wifi. Test with a cable before blaming anything further away. A laptop two walls from the router on a crowded 2.4 GHz channel can lose a few percent of packets on its own, and as the table above shows, loss is what TCP hates most.

TCP inside TCP, and UDP inside TCP#

How the VPN carries traffic changes how it reacts to loss.

• WireGuard and OpenVPN over UDP wrap your packets in UDP. If one is lost, the TCP connection inside notices and recovers. One layer of retransmission, behaving normally.
• OpenVPN over TCP wraps your TCP connections inside another TCP connection. When a packet is lost, both layers retransmit on their own timers, and under sustained loss the inner connection's throughput can collapse. Use OpenVPN over TCP only when UDP is blocked.
• Xray proxies streams: your TCP connection ends at the client and a new one starts at the server, with the bytes carried over a TLS connection in between. That avoids the double retransmission problem for web traffic. UDP traffic, such as games and calls, is relayed over the same TCP connection, so a lost packet holds back everything behind it until it is resent. On a clean path this is invisible; on a lossy one, real-time apps stutter.

That last point is why a censorship-resistant VPN is not a gaming accelerator. Does a VPN lower ping in games goes through when a tunnel helps a game and when it only adds distance.

Problems on the device#

Proxy mode instead of VPN mode. A browser goes through the proxy, the download manager or game launcher does not, and you are testing the wrong thing. Check which mode the client runs in.

Battery optimisation. Android may restrict a VPN app running in the background. Exempt the VPN client from battery optimisation if the connection keeps dropping when the screen is off.

Security software inspecting HTTPS. Antivirus suites that intercept TLS add their own processing to every connection, VPN or not, and some interact badly with VPN adapters.

Two VPNs. A work VPN and a personal one, or a VPN and a firewall app that works as a local VPN, give you overlapping routes and unpredictable paths.

DNS at the far end. With a full tunnel, every new hostname costs a round trip to the server before the connection to the site even starts. On a 100 ms path, a page that touches thirty domains feels slower than its bandwidth suggests. That is the price of not leaking DNS, and browsers' own caches soften it after the first visit.

A private server: what you can and cannot fix#

On a server of your own, two of the five causes are partly under your control. The CPU: on RE:NODE's private VPN line, plans are sized by how many devices use the server at once, the CPU share is a hard limit, and the panel's graphs show CPU against that limit, so you can see a ceiling rather than guess at one. And contention: nobody else is on your server, so the only devices competing for it are yours. How many devices on a VPN covers sizing.

Distance is not under your control. The server runs Xray with VLESS and Reality, in one location, Germany. From most of Europe that is a short path; from further away, every connection pays the distance described above, and no plan changes physics. There is no traffic cap, so a slow tunnel is never a quota being enforced quietly. VPN use is restricted in some countries; know your local law before relying on one.

FAQ#

How much speed loss is normal with a VPN?

With a nearby server and a capable device, 5-15% below your line speed is normal - mostly overhead and a slightly longer path. Losing half or more points to distance, loss, a CPU ceiling or MTU trouble, and the measurements above will tell you which.

Why is my VPN fast on mobile data and slow on wifi?

The VPN is the same, so the difference is the local network: wifi signal and interference, the home router, or a different ISP route to the server. Test on a cable to rule out the wifi first, then compare mtr from both networks.

Does a faster internet plan make the VPN faster?

Only if the line was the bottleneck. If the limit is distance with loss, the CPU on either end, or a congested link between providers, a faster plan changes nothing. Compare VPN-off speed to a server near the VPN first.

Should I lower the MTU to speed up my VPN?

Only if the large-packet test shows the path cannot carry full-size packets, or you see the classic symptom of some sites hanging. Lowering MTU when nothing is wrong slightly reduces throughput, because every packet carries less data for the same headers.

Why is my VPN slower in the evening?

Most likely congestion between your ISP and the networks that carry traffic to the server - the evening peak fills those links. Run mtr at a quiet time and at the slow time and compare where loss appears.