IP geolocation, honestly explained — why your VPS may show up in the wrong country

An IP address is just a 32-bit (IPv4) or 128-bit (IPv6) number. It contains zero geographic information. There is no country code in the bits, no city in the structure, no coordinates anywhere in the format. The geographic association you see in tools like Speedtest, Google, YouTube or weather widgets is entirely external — somebody, somewhere, decided that this number probably belongs to that country, and shipped a database saying so.

An IP address has no inherent country

Compare with a phone number. A phone number really does carry geography in its structure: +49 means Germany, +1 means US/Canada, +7 means Russia, the next digits identify the carrier and often the city. That information is built into the number by the international standard, allocated by regulators, and updated through a public registry. You can derive country and operator from the number itself, with confidence.

An IP address has none of that. When IANA delegates a block to RIPE, ARIN, APNIC or another regional registry, that registry then assigns it to whoever asks — a hosting provider, an ISP, a corporation, a government — anywhere inside its huge geographic footprint (RIPE alone covers Europe, Russia, Central Asia and the Middle East). The block 87.76.179.0/24 and the block 87.76.180.0/24 might be in completely different countries, owned by completely different organizations. The number alone tells you nothing.

How geolocation actually works (it's all third-party guesses)

Every IP-geolocation database is built by combining several signals, each imperfect, into a best guess:

• WHOIS records — the registered owner of the IP block, with a postal address. Often correct for the company HQ but not for the actual datacenter where the IPs live.
• BGP announcements — which network (autonomous system) is announcing the prefix to the global routing table. Tells you the operator but not the city.
• Latency triangulation — measure RTT from many vantage points (e.g. RIPE Atlas) to the IP, infer geographic distance.
• Reverse DNS — hostnames like vps-fra-23.example.com hint that the IP is in Frankfurt.
• Direct submissions from network operators — we, as a provider, can tell each database "this /24 lives in Frankfurt now".
• Web logs and crawl data — if a site sees an IP submit a form with a German postcode, that's a weak signal.

Different databases weigh those signals differently and arrive at different answers. They also update at very different speeds.

Thousands of databases, all out of sync

There are roughly a dozen authoritative IP-geolocation databases. Below them are thousands of secondary services that mostly re-license or scrape data from the big ones, then ship it on their own (often slower) schedule. Some of those secondary databases haven't been updated in months. A few have been silently abandoned for years. No provider on Earth — not us, not Google, not Cloudflare — can force a third party's database to be current.

Update cadence of the major databases (typical):

What we do every time we add a new IP block

When a new /24 enters one of our locations, we don't sit and wait for the databases to discover us. We submit accurate geolocation data to every authoritative provider on day one. Each of them has a public correction form:

• MaxMind GeoIP correction form
• IPinfo corrections
• DB-IP
• IP2Location update form
• Ipregistry
• IPGeolocation.io
• GeoMyIP

Why a 'wrong' geolocation usually isn't a real problem

If your VPS is physically in Frankfurt but Speedtest, Google, YouTube or a weather widget says it's in Amsterdam — or Hong Kong, or São Paulo — what's almost always happening is that one specific database hasn't picked up our submission yet. The server is exactly where you ordered it. The number on the network interface is the same. Only one third party's CSV file is out of date.

Things that may look broken because a database is stale:

• Speedtest auto-selects a test server in the wrong country (it picks based on the IP's geolocation, not on actual latency), so the result looks worse than it is.
• Google search results, YouTube recommendations or ad targeting localize for the wrong region.
• Weather, news or sports widgets show the wrong city.
• Geo-restricted streaming services (Netflix, BBC iPlayer, etc.) behave inconsistently.
• Payment processors flag the IP as 'unusual region' for the cardholder.

None of those are caused by anything wrong on our side. The server is in the country where you ordered it. The fix — wait for the database to catch up — is in someone else's hands. We've already done the only useful thing we can do, which is submit the correction the day the block came online.

How to verify the actual physical location

If you want to confirm where your server really is, don't rely on a single GeoIP lookup. Cross-check:

1. Run a traceroute to your VPS from 2–3 different cities. The last few hops will be inside our datacenter's transit and city — those are physically anchored, no GeoIP database can fake them.
2. Compare 3 different geolocation providers (e.g. ipinfo.io, db-ip.com, MaxMind). If two out of three agree, that's the answer; if all three disagree, it's a propagation issue.
3. Measure RTT to a public iperf endpoint or a well-known service in the city you expect. ~5 ms to a Frankfurt iperf server from a 'Frankfurt' VPS is consistent with reality.
4. Ask us. We have hard data on which /24 lives in which physical rack — much more reliable than any external lookup.

Related context: how port speed and end-to-end internet speed relate to all this is covered in our explainer on shared 1 Gbps ports and the deeper article on internet speed. Geolocation accuracy and bandwidth are independent problems but get mixed up surprisingly often in support tickets.