A Handful of Cities Host Most of Online Gaming

Game servers are not spread evenly across the world. They cluster in a short list of cloud and colocation hubs — Frankfurt, Amsterdam, London, Ashburn in Virginia, Los Angeles and Oregon, São Paulo, Singapore, Tokyo, Sydney, Mumbai, Bahrain — because that is where the fibre, the peering, and the affordable capacity already are. Your ping is largely decided by how far you live from the nearest of those hubs and how directly the internet routes you there. Distance is physics, and no setting on your router negotiates with it.

Why Publishers Concentrate Servers

Running a game region is not just renting machines. It means capacity that can absorb a launch weekend, low-latency links to the major transit networks, DDoS mitigation at scale, staff who can reach the site, and enough concurrent players in that region to fill matches quickly. Those requirements point at the same small set of locations every time.

Existing interconnection. Cities like Frankfurt, Amsterdam, and London host enormous internet exchange points where hundreds of networks meet. A server there is a short, cheap hop from most European ISPs.
Cloud region availability. Publishers increasingly rent from the large cloud providers, so their map of possible locations is the providers' map. Where there is no cloud region, there is usually no game region.
Player density and matchmaking. A region needs enough concurrent players to build balanced matches at reasonable queue times. Splitting a modest population across more regions produces lower ping and worse matchmaking, and publishers generally choose matchmaking.
Cost and power. Data centre space, electricity, and cooling vary enormously by geography. Ashburn became a hub partly through historical accident and then compounded, because everyone else was already there.

The result is a map that reflects infrastructure economics rather than population. Large gaming populations far from a hub — much of central Asia, inland South America, most of Africa — end up connecting across long distances to somewhere else's region.

The Physics Floor

Light travels through fibre at roughly two thirds of its speed in a vacuum, which works out to about 5 microseconds per kilometre in each direction. A round trip therefore costs roughly 10 microseconds per kilometre, or about 1 millisecond per 100 km of straight-line distance. That is the absolute floor. It assumes a perfectly straight cable, zero routing, zero queueing, and infinitely fast switches.

Reality is worse for two structural reasons. Fibre follows roads, railways, coastlines, and seabeds rather than great-circle paths, so the physical route is commonly 1.3 to 2 times the map distance. And every router, amplifier, and switch along the way adds its own small processing and queueing delay. In practice, achievable latency tends to land somewhere between 1.5 and 2.5 times the theoretical floor on a well-connected route.

Straight-line distance	Theoretical round-trip floor	Realistic well-routed range	Example pairing
100 km	About 1 ms	Roughly 2 to 6 ms	Same metropolitan area to its nearest data centre
500 km	About 5 ms	Roughly 8 to 15 ms	Neighbouring countries in western Europe
1,000 km	About 10 ms	Roughly 15 to 28 ms	Madrid to Frankfurt, Chicago to Ashburn
2,000 km	About 20 ms	Roughly 30 to 50 ms	Istanbul to Frankfurt, Los Angeles to Dallas
5,000 km	About 50 ms	Roughly 70 to 120 ms	New York to London, Mumbai to Singapore
10,000 km	About 100 ms	Roughly 140 to 220 ms	Europe to east Asia, US west coast to Australia
17,000 km	About 170 ms	Roughly 230 to 320 ms	Roughly antipodal pairs, such as Europe to New Zealand

These are physics-derived approximations for orientation, not measurements of any specific route. Use them to sanity-check what you see: if you are 800 km from your server and reading 90 ms, the distance is not the problem and something in the path is. If you are 9,000 km away and reading 160 ms, your routing is close to as good as it gets, and the only real fix is a closer server.

Why the Route Is Longer Than the Line

Internet traffic does not go where you would draw it. Several forces bend the path.

Submarine cables define the possibilities. Intercontinental traffic runs through a finite set of undersea cables with fixed landing points. Traffic between two African cities may transit Europe because that is where the cables converge. When a major cable is cut for repair, latency across an entire region shifts for weeks.

Peering economics decide the handoff. Your ISP hands traffic to another network at a specific exchange point, and the choice is commercial as much as technical. A smaller regional ISP without local peering may carry your packets to a distant hub before handing them off, adding tens of milliseconds compared with a neighbour on a better-connected network.

Tromboning. Traffic between two nearby points sometimes travels far away and comes back because that is where the two networks interconnect. Two players in the same city on different ISPs can have their packets meet several hundred kilometres away.

Last-mile technology. The access network adds a baseline before your packets reach the internet at all. Fibre to the home adds very little; cable a bit more; DSL more again; older wireless and satellite links substantially more. Geostationary satellite adds several hundred milliseconds purely from the trip to orbit and back, regardless of where the server sits.

This is why two players the same distance from a hub can read very different ping. Same physics, different route quality, different last mile. A traceroute is the tool that makes the difference visible — it shows you where your packets actually go and where the latency accumulates.

What to Do About It

Find out which region you are actually on. Many games show it, and many default to automatic selection that occasionally picks badly. Manually pinning your closest region is often worth 20 to 40 ms in games that allow it.
Compare regions before committing. Measure several before choosing rather than guessing from the map. Our game ping test hub compares regional latency in the browser, measuring warm HTTPS round trips to cloud endpoints in each region — a proxy rather than in-game packets, but measured identically everywhere, so the ranking is reliable.
Fix the last mile before blaming geography. Wired instead of wireless, queue management enabled, background transfers paused. These are worth real milliseconds and they are entirely under your control.
Ask your ISP about routing, with evidence. If a traceroute shows your traffic taking an obviously indirect path to a nearby hub, that is a peering issue, and it is occasionally fixable when reported with a specific trace attached. Other causes are covered in our guide to what causes high ping.
Adjust expectations to the physics. If the nearest hub is 6,000 km away, sub-50 ms is not attainable and no product sold to you will change that. Aim instead for stability, and choose genres and games whose netcode tolerates distance — the thresholds in our guide to good ping for gaming vary hugely by genre.

The Honest Outlook for Underserved Regions

Things do improve, slowly, and mostly through infrastructure rather than consumer purchases. New submarine cables shorten paths. Cloud providers open regions in places like Bahrain, Mumbai, Johannesburg, and Santiago, and games follow once the player base justifies it. Local internet exchanges keep domestic traffic domestic, which cuts latency for everyone on the participating networks and is one of the highest-leverage investments a country can make for its players.

What does not help is the category of products promising to "reduce ping" by routing you through additional servers. A gaming VPN can occasionally beat your ISP's default path when that path is genuinely poor, because it substitutes a better-peered route. It cannot beat physics, and on an already-direct route it adds distance and hops. Treat any such claim as a hypothesis and test it: measure your baseline with a browser latency test, enable the product, measure again under identical conditions, and keep it only if the improvement is real and repeatable. In most cases where the default route is already sensible, it will not be.

The practical summary is unglamorous but useful. Find your nearest hub, confirm your route to it is sane, clean up the part of the chain inside your home, and then accept the remainder as the cost of where you live. Players who do all four consistently sit at the good end of the range their geography allows, which is the only target worth optimising towards.