How to test VPN speed so the numbers mean something
Pin the test server, hold the underlay still and read delay apart from throughput. The tunnel changes the path before it measures anything at all.
A speed test never measures the VPN. It measures a path, and switching the tunnel on replaces part of that path before the first byte moves. That is why one laptop shows a healthy figure against one site and a poor one against another with nothing changed on either side. Read the result as evidence about a route, not as a score for a product.
Three things decide whether the comparison is worth anything: whether both runs hit the same target, whether the access network stayed still, and whether you recorded delay alongside volume.
What the tunnel rewrites before the first byte
The client wraps every packet in another header, so usable payload per packet shrinks. The cost is per packet rather than per transfer, which means a large file needs more packets than the same file sent untunneled. Overhead like that shows up as packet count, not as a visible setting.
Two consequences follow. A test built from large blocks feels the per-packet cost, while a test built from many small requests feels the round trips instead. And if path MTU discovery is blocked somewhere along the way, the tunnel settles on a smaller packet size and throughput falls for a reason that has nothing to do with ciphers.
You can watch the ceiling directly. On Linux, ask for the largest payload that survives without fragmentation, then repeat with the tunnel up:
ping -M do -s 1472 -c 3 203.0.113.10
If that fails, step down to 1,400 and try again. A tunnel that only carries 1,380 bytes is telling you something is clamping further down the path, and no amount of tuning at the client will lift it.
Why the test server moves when the tunnel comes up
Most tools choose a nearby server from the public address they observe. With the tunnel up, that address belongs to the exit node, so the tool may pick a host in a different city or country. You are then comparing two destinations, and the gap between them includes the distance from the exit to the test host.
Pin the server by name or ID before the first run and keep it for every run after that. If the tool will not hold it, choose a target you control and drive it yourself: iperf3 -c test.example.net -R -t 20 keeps the destination fixed and gives you a number you can compare against yesterday.
Change one variable, and the underlay is not one
Wireless is the usual hidden change. Signal strength shifts when the laptop moves and channel occupancy shifts when a neighbour starts a call, so two runs ten minutes apart on Wi-Fi are not repetitions of the same test. Wired, or a fixed position with the signal level written down, removes most of that noise. A note of the signal level at the start and end of each run is usually enough to show whether two runs belong together.
Device load belongs in the same bucket. A client encrypting on one core hits its own ceiling long before the link does, and a background sync hits it sooner. Watch CPU during the run and note what else was open. Power settings can bite here too, because a laptop on battery may cap the processor long before the link is anywhere near busy.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
Hold the underlay still instead of averaging across it. Three runs that agree tell you more than ten taken in different rooms.
Delay, loss and ICMP answer different questions
Ping sends a small probe to a fixed address, and plenty of networks answer ICMP at low priority or ignore it entirely. Missing replies describe the probe, not the application's packets. A round-trip time that climbs under load usually means a queue is filling, not that the route got longer.
To learn whether the tunnel adds delay, compare one target with and without it, or compare two exits reachable from the same access network. Run the probe repeatedly and look at the spread, because an average hides exactly the variation that makes a call unusable.
Go back to the task that felt slow
A benchmark that improves while the call still stutters has answered something else. Re-run the task that started the investigation, whether that was a meeting, a file share or a remote desktop session. If the figure improved and the task did not, the bottleneck sat somewhere the test never reached, such as the server behind the tunnel or the uplink at your end.
Log every run with device, access network, endpoint, protocol, target and time. A run that never connected is a reachability result rather than a throughput of zero, so file it under that label instead of deleting it.
A short list before the next comparison
Fix the target and write down why you chose it. Record the packet size the path allows, so a later drop has an explanation. Keep the access network identical, note CPU load, and take three runs before believing a difference.
Then change exactly one thing and repeat. The comparison you can explain beats the one with the bigger number.