VPN causing packet loss in games: causes and fixes

Start by separating two things that feel identical in a game and are completely different underneath. Latency is how long a packet takes to arrive. Loss is packets that never arrive at all. A VPN always adds the first and should not add the second.

If your ping went from 25 ms to 60 ms, that is the tunnel doing what a tunnel does. If you are seeing rubber-banding and hit registration failures, something is dropping packets, and that is worth diagnosing.

Measure before theorising

Run the speed test with the tunnel down and again with it up, and note the latency and jitter figures rather than only the throughput. Jitter is the variation between measurements, and it is what makes a game feel bad even when the average ping looks fine.

A stable 60 ms is playable. A ping that swings between 30 ms and 200 ms is not, and the average will not show it.

Cause one: MTU

Game traffic is usually small UDP packets, which is why MTU problems in games look different from MTU problems in browsers. Instead of pages hanging, you get occasional dropped updates when a larger packet — a map load, a state sync — is sent and silently discarded.

Set the tunnel MTU explicitly. 1420 for Ethernet, 1412 on PPPoE lines, 1380 on mobile. If the stutter disappears at 1280, walk it back up.

Cause two: NAT type

Multiplayer games rely on peer-to-peer connections for voice and sometimes for gameplay. A tunnel adds a layer of address translation, so your NAT type typically drops from open to moderate or strict.

The effects are slower matchmaking, relayed voice chat, and games that fail to host. That is not loss, but it produces symptoms people describe as loss.

Fixing it requires port forwarding through the tunnel, which most consumer VPN providers do not offer for good reasons. If open NAT matters for the games you play, the honest answer is that a consumer VPN is a poor fit for those sessions.

Cause three: a congested exit

A shared server at peak time drops packets when its uplink saturates. The signature is time-of-day dependence: fine at 03:00, bad at 21:00.

Test by connecting to a different server in the same country. If the neighbour is clean, the first was busy.

Cause four: the route, not the tunnel

Sometimes the path from the VPN exit to the game server is worse than the path from your home connection, even though the exit is nearby. Transit routing is not symmetric and not always sensible.

There is nothing to configure here. Try servers in two or three nearby cities from the server list and keep whichever gives the best result against the game server you actually use.

Cause five: bufferbloat, which was already there

Run a latency test while a download is running. If ping goes from 20 ms to 300 ms under load, your router is over-buffering. The VPN did not cause it; the VPN made it visible by adding a hop that has to wait behind the same queue.

Smart queue management on the router — cake or fq_codel — fixes it properly and improves everything else on the connection.

Cause six: Wi-Fi

Wi-Fi loses packets. It always has. A tunnel makes retransmission more expensive, because a lost packet inside a tunnel takes longer to recover.

Test wired once. If the loss disappears, the tunnel is not the problem and no VPN setting will fix it.

What to expect at best

Server distance	Added latency, roughly
Same city	2 to 10 ms
Same country	5 to 25 ms
Neighbouring country	15 to 40 ms
Another continent	120 to 250 ms

Those numbers are physics plus routing, not overhead you can tune away. If the tunnel has to be on while gaming, the nearest server is the only meaningful lever.

When to just turn it off

If the reason for the tunnel is privacy from your ISP and the game is the one thing suffering, split tunnelling that excludes the game gives you both. If the client has no split tunnelling, turning the VPN off for those sessions is a reasonable choice rather than a defeat.