Two of you are in Europe, one is in Texas, and one moved to Singapore for work. You want to play together on the same server, and somebody has to take the ping.
There is no configuration that makes this problem disappear. But the intuitive solutions are mostly wrong, the trade-offs are more forgiving than people assume in some games and much less forgiving in others, and there is a fairly clear method for deciding.
The midpoint is usually the worst option
The instinct is to find something in the middle. Two players in Europe and one in North America, so you look for a server in Iceland.
This is almost always worse than picking one end. Instead of two players at 20ms and one at 130ms, everyone is at 70ms, you have taken a good experience away from two people to slightly improve it for one, and the total amount of latency in the group has gone up rather than down.
The exception is when the midpoint crosses a threshold that matters. If a game becomes unplayable above 150ms and the far player is at 200ms from your local server, moving to a midpoint that puts them at 130ms may bring them from unplayable to playable while leaving you at merely worse. That is a real trade. Shaving 40ms off someone who was already fine is not.
Distance is not the variable
The single most useful thing to know: ping is determined by routing, not by geography.
Two servers the same physical distance away can differ by 60ms because one has a direct path and the other goes via a peering point somewhere unhelpful. This is why the "closest" datacentre is sometimes not the fastest one, and why the only reliable method is to test rather than to reason about a map.
Why routing beats distance covers the mechanism properly, and ping and latency explained covers what the number is measuring. The practical consequence for a group is that you should test several candidate regions rather than assuming which will be best.
Test with the person who is furthest away. Their number is the constraint. Everyone else's is a detail.
Ping matters very differently by game
This is the part that decides how hard your problem is, and it is where groups waste the most effort: agonising over 40ms in a game where it is irrelevant, or ignoring 120ms in one where it is fatal.
Brutal, every millisecond is felt: competitive shooters where duels are decided in a few frames. Counter-Strike 2, Counter-Strike 1.6, and any game with peeker's advantage. Here 100ms is a genuine handicap and no amount of goodwill fixes it. If your group is playing this competitively, someone is going to have a materially worse time and it is better to acknowledge that than to pretend the setup is fair.
Noticeable but workable: most modern shooters with decent netcode, tactical games, Rust-style survival PvP. 100–150ms is playable and you will notice it in fights.
Largely irrelevant: co-op games, building games, Minecraft survival, most PvE, roleplay, simulation. 200ms is fine. Blocks place a beat late and nothing about the experience is damaged. A huge proportion of cross-region group play falls in this category, and groups routinely over-engineer for a problem they do not have.
Actively better with a distant server, occasionally: games where the deciding factor is which server has people on it rather than latency. Joining a busy server at 120ms beats an empty one at 20ms, every time.
Netcode, ping and interpolation explains why the same latency feels wildly different across games, and it is worth reading before concluding your group has a problem.
The methods that actually help
Pick the region with the most of you
Boring and correct. Four in Europe and one elsewhere means a European server. The one person takes the hit, everyone acknowledges it, and it is the arrangement that maximises total enjoyment.
Where this gets uncomfortable is when it is two and two. In that case, alternate — one session in each region, and everyone takes a turn.
Choose games that tolerate it
If your group is spread across three continents, the choice of game matters more than the choice of server. A co-op or building game removes the problem entirely; a competitive shooter guarantees it.
This is not a compromise so much as a recognition. Groups that play across regions successfully over years are almost always playing something in the tolerant category.
Rent rather than join
For a private group, hosting your own is worth considering. It is cheaper than most people expect; what a server costs is often ten to twenty a month split several ways, and it lets you place it exactly where the testing says is best rather than choosing from wherever public servers happen to be.
It also gives you the option of moving it, which is useful if your group's composition changes. Choosing a region covers the decision, and moving a server between hosts covers doing it without a fuss.
Look for the second peak
If you are joining public servers rather than hosting, a server's peak-hours chart sometimes shows a secondary bump from a group on the other side of the world. A server with a European primary peak and an Asian secondary one is a place where your Singapore friend has people to play with when the rest of you are asleep, which is a different and often better solution than trying to make everyone play simultaneously.
The compromise nobody suggests
If the group is split and the game is latency-sensitive, there is a third option that gets overlooked: play two games.
One latency-sensitive game on a server in the region where most of you are, accepting that the distant player sits that one out or plays at a disadvantage they have agreed to. And one tolerant game — co-op, building, survival PvE, where everyone is equal and the distant player is not carrying a handicap.
Groups that stay together across continents for years almost always end up here without planning it. The competitive thing becomes what the local majority does, and the shared thing becomes something where 180ms is irrelevant.
It is less satisfying than a single answer, and it is more honest than pretending a midpoint server makes everyone equal. The alternative; one person quietly playing worse every session, is how scattered groups break up.
What does not help
A VPN. VPNs add a hop and usually add latency. The exception is the rare case where your ISP's default route is bad and the VPN happens to take a better one — worth testing, not worth assuming. Note also that some servers block VPN connections outright, so the fix can cost you access entirely; should you block VPN players explains why servers do it.
"Gaming" routers and network optimisers. These reduce local buffering, which is real but small. They do not affect the transit time across an ocean, which is physics.
Paying for a faster connection. Bandwidth and latency are different things. A gigabit line does not make packets arrive sooner.
Blaming the server's response time on a listing. That figure is measured from wherever the measurement was taken, not from you: what a server list measures is explicit about this. Your ping is your own to test.
Test properly, in five minutes
Reasoning about this is unreliable. Measuring it takes almost no time and settles it.
Have the furthest player test, not you. Their number is the binding constraint and yours is a detail.
Test the actual server, not the datacentre. Ping the address on the listing. A provider's marketing page about their network tells you nothing about the path from one specific house to one specific machine.
Test at the hour you will play. Routes congest in the evening. A 60ms reading at 11am and 110ms at 9pm is a completely normal difference, and the second number is the one that matters.
Test more than once. A single reading catches a moment. Three readings across an evening catch the pattern, and a wildly variable number is worse news than a consistently high one, jitter is more damaging to how a game feels than latency is, because prediction cannot compensate for something unpredictable.
Compare two or three candidate regions. This is where the surprises are. Groups routinely discover that the region they assumed would be worst is fine, because the route happens to be direct.
Then just play a session before committing. Thirty minutes on a candidate server tells you more than any number, because the question is not what the latency is but whether it is noticeable in this specific game. In a co-op or building game, a number that looks alarming on paper frequently turns out to be invisible in practice.
Deciding, in order
- Work out whether the game cares. If it is co-op or building, stop here; pick whatever server has people on it.
- Test candidate regions from the furthest player. Actual numbers, not a map.
- Pick the end where most of you are, unless the far player crosses into unplayable.
- If it is an even split, alternate rather than compromising in the middle.
- Consider hosting your own if the group is stable and the game is latency-sensitive.
And be direct about it with each other. The arrangement where one person quietly plays at 160ms and does not mention it is the one that ends with them drifting away from the group. Naming the trade — "you're taking the ping this month, we'll move next month", is the part that keeps a scattered group playing together.
Common questions
- Can using a VPN lower my ping to an overseas server?
- A VPN usually adds latency by introducing another hop, making ping worse. The rare exception occurs when your provider has a poor default route and the VPN routes traffic more efficiently. However, you risk losing access entirely, as some game servers actively block VPN connections.
- How do you pick a server when a group is split evenly between two regions?
- Alternate hosting locations between sessions instead of picking a server in the middle. Giving each region a turn ensures everyone takes the ping penalty equally. Choosing a midpoint usually ruins the experience for all players by needlessly increasing the group's total latency.
- Why does a closer server location sometimes have higher latency?
- Ping is determined by network routing rather than physical geography. Two datacentres at identical distances can differ by 60ms because one uses direct paths while the other routes through poor peering points. Because routing determines speed, testing actual server addresses is the only reliable measurement.
Published · 7 min read