Picking the fastest VPN server
Start with the nearest server, because latency is set by distance and everything else follows from it. Then test one or two alternatives in the same region, because congestion is per-server and a busy nearby exit can be slower than a quiet one slightly further away.
4 min read
"Fastest" is two numbers that do not always move together. Throughput is how much data per second; latency is how long each round trip takes. A server can be excellent at one and poor at the other, and which you should optimise for depends entirely on what you are doing.
Start with distance
Latency is set by physics and routing, and it is the floor you cannot negotiate. Light in fibre covers roughly 200 kilometres per millisecond, and real paths wander, so about 100 kilometres per millisecond of round trip is a working rule.
| Distance | Best case round trip |
|---|---|
| Same city | 1 to 5 ms |
| Same country | 5 to 25 ms |
| Neighbouring country | 15 to 40 ms |
| Across a continent | 40 to 90 ms |
| Across an ocean | 80 to 150 ms |
| Opposite side of the world | 250 ms and up |
Latency also caps throughput for anything acknowledgement-driven, which is most things. So the nearest server is the right default even when you only care about download speed.
Then check load
Two servers in the same city can differ by a factor of three at nine in the evening. Capacity is shared, and popular locations fill up.
If your client shows server load, use it. If it does not, testing two or three neighbours takes a few minutes: connect, run the speed test, note the median of three runs, move on.
Do this at the time of day you actually use the connection. A server that is excellent at 3am tells you nothing about 9pm.
Watch out for the "fastest" button
Automatic selection usually optimises for the server's own reported load or for a latency probe, and it may pick a server in another country. That is fine for throughput and a problem if you needed a particular exit country — for a service that applies regional rules, or a bank that objects to a foreign address.
Confirm what you actually got with what is my IP rather than assuming the client picked what you would have.
Optimise for the right number
Streaming. Throughput, with a floor. 4K needs about 25 Mbps; beyond that more bandwidth does nothing. Any server that clears the floor comfortably is equally good.
Video calls. Latency and jitter. Under 150 ms of latency and under 30 ms of jitter keeps a call clean. Bandwidth requirements are modest.
Gaming. Latency, and nothing else. Nearest server, always.
Large downloads. Throughput. A distant server with a fat uplink can beat a nearby congested one here, because a long single transfer amortises the latency.
Browsing. Latency, mostly. Pages make dozens of small requests, and each one pays the round trip.
When the nearest server is not the best
Three real cases:
Bad routing. The path from your ISP to a nearby exit can be worse than the path to one further away, because transit relationships are not geographic. Measure rather than assume.
Congestion. Covered above, and the most common.
A virtual location. Some providers advertise a country where they run no hardware, routing traffic to a nearby one. The latency will reveal it: a round trip under 30 milliseconds cannot have crossed an ocean whatever the label says.
A five-minute routine
- Baseline with the VPN off. Three runs, take the median.
- Connect to the nearest server. Three runs.
- Connect to a second server in the same region. Three runs.
- Keep the better one, and note the numbers so you can tell when something changes.
Repeat once every few months, or whenever performance seems worse than you remember. The server list covers what each location is actually for, which is a better starting point than sorting by flag.
Why the numbers move between tests
Even a careful measurement varies, and knowing why stops you chasing noise.
Your own line is shared with the rest of the household and, on cable and mobile, with the neighbourhood. The VPN server is shared with other users. The path between them crosses transit networks whose congestion changes hour to hour. And the test server itself has capacity limits.
That is four independent sources of variation, which is why the median of three runs is worth more than one careful run. A difference under about ten percent between two servers is not a difference; it is the noise floor.
Sticking with one server
Once you have a good one, stay on it. Constantly switching costs you the reconnection each time, loses whatever routing warm-up the path had, and on services that watch for it, rapid server cycling looks exactly like the behaviour their proxy detection is built to catch.
Retest occasionally rather than continuously. Capacity gets added, routes change, and a server that was mediocre in March may be the best option in September — but that is a quarterly question, not a daily one.
