How a good VPN app picks a server for you
Automatic VPN server selection should measure a real round trip from your phone, weigh it against live server load, and pick the healthiest server.
A good VPN app picks a server in three steps: it measures a real round trip from your phone to each city, it combines that with live load figures the provider knows for each server, and when you tap a location it connects you to the healthiest server there, checks that traffic actually flows, and moves on if it does not. The choice of server inside a city is the app's, not yours, because that is what lets the provider maintain the fleet without you noticing.
What the app can measure, and what it has to be told
Two numbers matter for choosing a server, and they come from opposite ends.
Round-trip time is measured on the phone. Only your phone can know how long a packet takes to reach a city and come back over the network you are on, because the answer depends on your carrier's routing as much as on distance. A well-built app sends a small probe to each city and times the reply, then shows that number beside the city. It is a live figure, and it changes when you move between networks. Why the nearest server is not always the quickest shows what this measurement catches that a map cannot.
Load is known by the provider. How many sessions each server carries, how much of its uplink is used and whether it is healthy are things the servers report to the provider's control plane every few seconds. The app receives a summary per city and, for selection, per server. What server load is covers why this figure often matters more than distance.
Neither number needs your location. An app that asks for location permission to pick a server is asking for something it does not need.
Ranking
With both figures in hand, the app ranks. The exact weighting is a design choice, but the shape is consistent in any sensible implementation: a server that is close and quiet ranks first, a server that is close and busy ranks below one that is a little further and quiet, and a server that is unhealthy or full is not a candidate at all. Distance sets a floor on latency that nothing can beat; load adds a variable cost that grows as the server fills. For most use, a modest amount of extra distance is worth a lot of extra headroom.
Country versus city
A two-level picker, country then city, gives you two ways to choose.
Tap a city and the app connects you to the highest-ranked healthy server in that city. Cities show their measured round trip and their load so you can choose for yourself: lowest round trip for calls and games, most headroom for downloads and streaming.
Tap a country and the app picks its city for you, choosing the one with the strongest combination of measured round trip and headroom right now rather than the one that happens to be listed first. That is the right default for most people, most of the time.
Individual servers are never shown. A city may hold several, and which one you land on is decided by the ranking at the moment you connect.
Why you cannot pin a server
It looks like a limitation and it is a feature. A VPN fleet is in constant motion: a server is drained for a kernel update, an exit address is retired and replaced, a machine is swapped for a larger one. If users could pin a server, every one of those operations would be a visible outage for whoever pinned it, and providers would put maintenance off. When the app picks the healthiest server each time, a drained server simply stops being chosen and nobody notices. The honesty moves up a level: you see real numbers for the city instead of a name for the server.
Verifying after connecting
Connected is a claim, and a good app checks it. Once the tunnel is up, the app sends a request through it to the provider's own server asking what address the request arrived from. A reply proves the tunnel carries traffic and gives the exit IP to show you. No reply means the tunnel is not really working, however the handshake went, and the app should try another connection method on the same server, then another server, rather than leaving a green tick over a dead link. Asking the provider's own server rather than a third-party "what is my IP" site matters, because the check itself should not tell anyone else what you are doing. How to check your VPN is working goes through this from the user's side.
Staying connected
Selection does not end at connect. A well-built app keeps the tunnel across switches between Wi-Fi and mobile data, notices when a tunnel has stopped carrying traffic and reselects, and, when a session reaches the provider's ceiling, reconnects on its own. Culvert VPN sessions last up to 24 hours and the app reconnects automatically, running the same selection again so that a server that has since become busy is not chosen a second time.
What to look for in an app
| The app shows | What it tells you |
|---|---|
| A round-trip figure in milliseconds per city | It measured from your phone; trust it |
| A load or headroom figure per city | It knows the provider's side; trust it |
| A three-bar signal glyph | Nothing; it could mean anything |
| A list of individual servers to choose from | Maintenance will be visible to you |
| A location permission request | It is guessing distance rather than measuring |
Culvert VPN measures a live round trip from your phone to each city, ranks servers by load and distance, connects you to the healthiest server in the city you tap, and verifies the exit IP through the tunnel before it calls the connection good; it is free on Google Play.
Questions people also ask
Why can I only pick a city and not a server?
Because server choice is the provider's job. Servers are taken out of service for maintenance and address changes all the time; if you could pin one, that would be a visible outage for you instead of a routine swap you never notice.
Does the app need my location to pick a server?
No. A round trip measured from your phone to each city says more than a location does, because it includes your carrier's routing. Culvert VPN does not ask for location permission.
What happens if the server it picked is bad?
A good app verifies the tunnel carries traffic after connecting, and if it does not, tries another connection method and then another server rather than reporting connected.
All 12 guides in Speed, battery and reliability · Every guide