--- title: "Server locations, latency and geolocation: what a global list actually tells a developer" description: "The ticket says the checkout page shows the wrong currency for users in Germany" author: "Austin Luthar" published: 2026-09-13 updated: 2026-09-13 canonical: https://www.mindstick.com/articles/342638/server-locations-latency-and-geolocation-what-a-global-list-actually-tells-a-developer category: "software" tags: ["software", "geolocation", "latency", "server location"] reading_time: 6 minutes --- # Server locations, latency and geolocation: what a global list actually tells a developer The ticket says the checkout page shows the wrong currency for users in Germany. You open it on your machine in Pune, and it works. You open it again in an incognito window, and it still works. At this point most of us reach for the same tool: connect through a server in Frankfurt, reload, and see what a German visitor sees. That instinct is sound, and providers publish their coverage so you can find out whether the region you need is even available. It takes a minute to [check ExpressVPN's worldwide server coverage](https://www.expressvpn.com/vpn-server) before you assume a location exists. What is worth more of your attention is the gap between what that test proves and what you will end up telling the reporter. Three separate mechanisms can produce the same symptom, and a VPN check only observes one of them cleanly. ## Three questions hiding inside one bug report Before testing anything, it helps to separate what you are actually asking. | **The question** | **What determines the answer** | **What a VPN check tells you** | | --- | --- | --- | | What content gets served to a request from country X? | Your geo-routing logic, plus whatever geolocation database it consults | This is the one it answers well. The response you get is the response that logic produces for that IP | | How fast does the page load for a real user in country X? | Physical path, peering, CDN point of presence, and the client's own network | Almost nothing useful. You have added a hop, and your traffic is taking a route no real user takes | | Why did this specific user see the wrong thing? | Their IP, their resolver, their VPN or carrier NAT, and possibly a stale cache entry | Nothing directly. You are testing your rules, not reproducing their session | Most wasted debugging time comes from answering the first question and reporting it as though it settled the second or third. ## The flag on the server is not the machine Two independent layers of approximation sit between an IP address and a place, and both matter here. The first is that a location label on a VPN server list is a claim about the address, not about the hardware. Providers routinely run virtual locations, where the registered IP geolocates to one country while the server itself sits in another. This is not obscure practice. After India's CERT-In directions in 2022 required VPN providers to retain subscriber records for five years, ExpressVPN removed its physical servers from the country and now offers India locations routed through Singapore and the UK. The IP resolves to India. The packets go to Singapore. If you were using that location to reason about round-trip time for Indian users, every number you collected was wrong. The second layer is that IP geolocation is inference in the first place. There is no field in the packet that says where the sender is. Databases assemble their mappings from registry allocations, latency triangulation, and whatever operators tell them, which is why the IETF published [RFC 8805, a format for self-published IP geolocation feeds](https://datatracker.ietf.org/doc/html/rfc8805). The document exists precisely because network operators had no standard way to correct the record when a database placed their prefixes in the wrong country, and it deliberately limits itself to coarse-grained location. Google folded these feeds into its geolocation pipeline and a meaningful number of ISPs publish them. The practical consequence for your bug: your service and the reporter's browser may be consulting different geolocation sources that disagree about the same address. That is a real cause of "works for me" and no amount of connecting through Frankfurt will surface it. ## The caching problem you cannot express with Vary Here is the part that catches people who are otherwise careful about caching. HTTP lets you tell caches which request headers influence a response. The [Vary header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) exists for exactly that, and it is how content negotiation stays cacheable: vary on Accept-Language, and a shared cache will keep separate entries per language. Client IP is not a request header. There is no Vary: Client-IP. So if your origin inspects the connecting address and returns different HTML for different countries at the same URL, a shared cache in front of it has no way to know those responses are not interchangeable. The first German visitor's response gets cached and served to the next Indian visitor who lands on the same edge node, or the reverse. The symptom is intermittent, unreproducible, and looks exactly like a geolocation bug when it is a cache key bug. The three workable answers are to put geo variation at the CDN edge where the platform can add country to the cache key, to redirect to a URL that carries the locale explicitly, or to serve one document and resolve the region client side after load. Which one fits depends on your stack, and the trade-offs around SEO and first paint are a longer discussion than this article. There is plenty of that discussion in the [MindStick Developer Section](https://www.mindstick.com/developersection) already. ## A routine that does not lie to you Given all of the above, a sensible sequence looks like this: - Reproduce the rule before reproducing the user. Call your own geo endpoint with a spoofed or overridden country parameter first. If the rule is wrong, you have found it without any network games. - Use the VPN to confirm what gets served, and only that. Note the exit IP, look it up in whichever database your application actually uses, and confirm the two agree before you trust the result. - Check the response headers, not just the rendered page. Cache-Control, Vary, Age and your CDN's own cache-status header will usually tell you whether you are looking at a fresh origin response or a stale edge object. - Measure latency somewhere else entirely. Synthetic checks from real regional nodes and real user monitoring from actual traffic are the only honest sources here. A VPN adds a hop by design. - Expect a bot challenge. VPN exit addresses live on datacentre ASNs, and bot management and WAF rules frequently treat them differently. A CAPTCHA your test client hits is often not something a real user in that country would ever see. None of this makes the tool less useful. Connecting through another country remains the fastest way to answer "what does my application decide to send to this address", and for a developer sitting in one city shipping to many, that is a question worth being able to answer in under a minute. Just keep the three questions separate in the ticket. The one you can answer this way is narrower than it feels, and the difference between "I verified the geo rule" and "I verified the user experience" is the difference between closing the bug and reopening it next week. --- Original Source: https://www.mindstick.com/articles/342638/server-locations-latency-and-geolocation-what-a-global-list-actually-tells-a-developer Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.