The gaming post says not to trust a speed test and then moves on. This is the long version: what to measure instead, with which tools, and how to read output that is routinely misread by people who should know better.
The short version is that a speed test answers a question you did not ask.
Why speed tests mislead
A speed test measures throughput to a nearby, well-peered node, over several parallel TCP connections, for about ten seconds.
Every one of those choices is wrong for evaluating a VPN.
The path is wrong. Speedtest picks a server close to you, frequently inside your own ISP's network. That measures your last mile, which is exactly the segment a VPN does not change. The segment a VPN does change - your ISP's transit out to the wider internet - is the part the test carefully avoids.
Parallel streams hide the problem. Multiple TCP connections in aggregate mask per-connection issues. A single stream on a high-latency path with a small receive window will be slow while eight parallel streams report a fine number. Real traffic is often one stream.
It reports the wrong statistic. A speed test gives you a peak. What you feel in a game, a call, or an SSH session is variance - and that number is not on the results page.
A VPN can make your speed test worse and your actual experience better. That is not a paradox; it is the test measuring a different path.
The three numbers that matter
Throughput - how much data per second. Matters for downloads and video. Almost nothing else.
Latency - round-trip time to the thing you are talking to. Matters for anything interactive.
Jitter - how much latency varies. Matters most of all, and is the one nobody measures.
A stable 90 ms connection feels better than a 60 ms one that spikes to 250 ms twice a minute. Rubber-banding in games, robotic audio in calls, and a laggy SSH session are all variance, not average. Measure jitter or you have not measured the thing you care about.
Latency and jitter
ping is enough if you read the last line rather than the stream:
ping -c 100 -i 0.2 1.1.1.1
--- 1.1.1.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 19832ms
rtt min/avg/max/mdev = 21.114/23.402/38.771/2.104 ms
mdev is your jitter. Under 5 ms is comfortable, 5–20 ms is noticeable in games,
above that is where calls start breaking up. max matters too - one 250 ms spike
is one visible stutter.
Run it with the VPN off, then on, to the same target, at the same time of day. Routing congestion is time-of-day dependent, and the difference between 9am and 9pm is often larger than the difference a VPN makes.
Reading mtr without panicking
mtr combines traceroute and ping: it shows every hop and the loss and latency
at each.
mtr -rwzbc 200 asiavpn.app
-r report mode, -w wide output, -z show ASNs, -b show both hostname and
IP, -c 200 send 200 packets. Two hundred is the minimum for meaningful
percentages - a 10-packet run tells you nothing.
Now the part that gets misread constantly.
Loss at an intermediate hop is usually not loss. Routers deprioritise
generating ICMP replies to protect their control plane - Control Plane Policing.
A core router forwarding 100 Gbps of traffic perfectly will happily rate-limit
the ICMP TTL-expired messages mtr depends on. It shows up as 40% loss at hop 6
and means nothing.
Read the last hop first. If your destination shows 0% loss, there is no loss on the path, whatever the middle of the table says. Real loss propagates: it starts at a hop and continues through every hop after it, including the final one. Loss that appears at one hop and disappears at the next is ICMP rate limiting, every time.
5. ae-1.core1.example.net 40.0% 200 28.1 29.4 27.9 61.2 3.1 ← ignore
6. ae-3.core2.example.net 0.0% 200 28.4 29.1 28.0 44.8 2.2
7. asiavpn.app 0.0% 200 31.2 32.0 30.8 48.1 2.6 ← this one
Latency that only increases is fine. Each hop is farther away; the numbers going up is physics. What matters is a jump - 30 ms to 180 ms between two consecutive hops - which tells you where the path leaves the region.
Measure both directions. Internet routing is asymmetric: packets to the
server and packets back can take different paths, and only one of them may be
bad. An mtr from your machine only sees the forward path. Run one from the
server back to your IP as well. A problem visible in one direction and not the
other is the single most useful diagnostic there is, and one-way testing hides it
completely.
Throughput with iperf3
Speed tests measure the wrong path because they choose the target. iperf3 lets
you choose it - you run the server on the machine you actually care about.
On your VPS or VPN server:
sudo apt install iperf3
iperf3 -s
Open 5201/tcp in both the OS firewall and the provider firewall, then from your
client:
iperf3 -c YOUR_SERVER_IP -t 30 # upload, single stream, 30 seconds
iperf3 -c YOUR_SERVER_IP -t 30 -R # download (reverse)
iperf3 -c YOUR_SERVER_IP -t 30 -P 4 # 4 parallel streams
Run the single-stream test first and treat it as the honest number. Compare it
against -P 4: if four streams are dramatically faster than one, you are looking
at a window-size or loss problem on a long path, not a bandwidth limit. That
distinction is precisely what a speed test's parallel streams conceal.
For jitter and loss under load, use UDP:
iperf3 -c YOUR_SERVER_IP -u -b 50M -t 30
UDP does not retransmit, so the loss figure is real loss rather than something TCP quietly repaired. This is the closest thing to what a game or a call experiences.
Then run the whole set again with the VPN connected. Same server, same duration, same time of day.
The MTU trap
If throughput through a WireGuard tunnel is bizarre - the handshake completes,
ping works, SSH works, but HTTPS to some sites hangs forever - you have an MTU
problem, not a bandwidth problem.
WireGuard adds 60 bytes of overhead over IPv4 and 80 over IPv6: outer IP header
(20 or 40), UDP (8), and 32 bytes of WireGuard header and authentication tag. The
default tunnel MTU of 1420 is 1500 - 80, chosen conservatively to be safe even
when the outer path is IPv6.
It breaks when the path underneath is not 1500 - PPPoE links are 1492, some mobile networks are lower, and a tunnel inside a tunnel is lower still. Find the real ceiling by sending unfragmented packets of decreasing size:
ping -M do -s 1472 -c 3 1.1.1.1 # 1472 + 28 bytes of headers = 1500
Reduce -s until it stops failing. Add 28 to the largest size that works - that
is your real path MTU - then set the WireGuard interface to that minus 60 (or 80
if the outer path may be IPv6):
[Interface]
MTU = 1360
The classic symptom is worth memorising: small packets fine, large packets vanish. It looks like a firewall problem and it is not.
A protocol you can repeat
Numbers are only useful compared against other numbers taken the same way.
- Pick one target and keep it. Ideally the server you actually use.
- Test at the hour you actually use it. Repeat on another day.
- For each condition - VPN off, VPN on, one server, another server - run:
ping -c 100,mtr -rwzbc 200,iperf3 -t 30,iperf3 -t 30 -R. - Record
avg/mdev/maxfrom ping, final-hop loss from mtr, and the single-stream throughput. Five numbers. - Change one thing at a time.
That takes about four minutes per condition and produces something you can actually reason about, instead of a screenshot of a speed test.
What to conclude
If the VPN improves latency to your game server, your ISP was routing badly and the VPN found a better path - real, and the case the gaming post describes.
If latency is worse but jitter is much lower, take the VPN. Stability beats a lower average every time in anything interactive.
If throughput drops but latency and jitter hold, that is the tunnel's overhead and the server's capacity. For browsing and gaming it does not matter; for large downloads it does.
And if the single-stream number is far below the parallel one on both sides, the
problem is the path, not the VPN - go back to mtr, in both directions, and find
the hop where it changes.
Cover photo by Luke Chesser on Unsplash.
