What VPN server load is, and why it matters as much as distance
Server load is how close a VPN server is to its limits on sessions, processor and bandwidth; a busy nearby server often loses to a quiet distant one.
Server load is how close a VPN server is to the limits of what it can carry: how many sessions it holds, how much of its processor time is spent encrypting and decrypting, and how much of its uplink is in use. When any of those runs short, everyone on the server gets less, and the effect is often larger than the distance to it. A quiet server in a city 500 km away frequently outperforms a full server in the nearest one.
The three limits a server hits
A VPN server is an ordinary machine with a fixed network link, and it reaches its limits in a predictable order.
Bandwidth first. The uplink is shared by every session on the server. If the link is 1 Gbit/s and a few hundred people are connected, a handful of them downloading heavily can leave everyone else with a fraction of what their own connection could do. This is the limit that hits first in practice, and it is why bandwidth per server matters more than how much memory it has.
Processor next. Every packet is decrypted on the way in and encrypted on the way out. WireGuard does this cheaply, so a modest server can carry a great deal of WireGuard traffic. Older protocols cost several times more processor time per packet, so a server serving many sessions on a heavier protocol can run out of processor before it runs out of bandwidth.
Session count last. Each session needs a little state and, for some protocols, a little processor time even when idle. Servers are given a ceiling so that the bandwidth and processor limits above are not reached with nothing in reserve; a sensible ceiling for a small server is a few hundred sessions, and a city with several servers multiplies that.
Memory, which is the figure people often ask about, is rarely the constraint. A small server can hold far more idle sessions than its uplink can serve at once.
What load feels like
Load shows up differently from distance, which is how you can tell them apart.
| Symptom | Distance | Load |
|---|---|---|
| Round-trip time | High but steady | Moderate but jumps around |
| Page loads | Consistently slow to start | Sometimes instant, sometimes hang |
| Downloads | Full speed once running | Well below your connection's speed |
| Calls and games | Constant lag | Stutter and drop-outs |
| Change over the day | Almost none | Follows the local evening peak |
The last row is the giveaway. A route does not get worse at eight in the evening; a server does, when the people in its time zone come home. If a city is fine at lunchtime and poor after dinner, load is the cause.
Why load beats distance
Distance adds a fixed cost of roughly 1 ms per 100 km each way, and once the connection is running, distance barely limits how much data flows. Load does the opposite: it adds a variable cost that grows as the server fills and directly caps how much data you get. For anything heavier than messaging, the variable cost wins.
A worked example makes it concrete. A server 100 km away with a busy uplink might give you a 15 ms round trip that jumps to 60 ms under queueing and a fifth of your connection's bandwidth. A server 600 km away with room to spare might give a steady 25 ms and nearly all of it. The second is better for almost everything, and it only looks worse on a map. The post on why the nearest server is not always the quickest covers the routing side of the same question.
What an app should do with load
Load is something the provider knows and the user cannot measure, so the app has to be told. A good app gets a live load figure per server from the provider, combines it with the round trip it measures from your phone, and uses both to rank.
Two things follow. First, load should be shown per city as a real percentage or headroom figure, not folded into a signal glyph that could mean anything. Second, the choice of server inside a city should be the app's, not yours. If you could pin a server, you would pin it and then complain when it was drained for maintenance; if the app picks the healthiest server each time, maintenance is invisible. How a good VPN app picks a server goes through the whole sequence.
What you can do about a busy server
Change city, and prefer headroom over the last few milliseconds. If a city with a slightly higher round trip has far more room, it will feel quicker for downloads, streaming and calls alike. Check again later if you were connected during a local peak, because the ranking will have changed. And if the app does not show load at all, treat any speed complaint as unexplained: you have no way of knowing whether you are on a good server on a bad day or a bad server on any day. Why your VPN is slow puts this beside the other causes.
Culvert VPN shows a real load figure for each city beside the round trip measured from your phone, ranks servers by load and distance, and connects you to the healthiest server in the city you tap; it is free on Google Play.
Questions people also ask
What does a load percentage on a VPN city mean?
It is how much of the servers' capacity in that city is already in use, typically counting active sessions against a limit set by the server's uplink and processor. Lower means more room for your traffic.
Does load affect latency or only download speed?
Both. A busy server queues packets, which makes the round trip longer and, worse, uneven. You feel that as stutter in calls and games before you notice slower downloads.
Can I pick a specific server to avoid a busy one?
In a well-built app you should not need to. It should track load per server, show it per city, and choose the least loaded healthy server in the city you tap.
All 12 guides in Speed, battery and reliability · Every guide