Where Your IP Says You Are: Why Four Databases Give Four Answers (2026)

A VPN gives you an address. Where the internet believes that address is located is a completely separate question, and it is not answered by the address itself. It is answered by commercial databases that guess — and they guess differently, sometimes by two thousand kilometres, occasionally by a whole geopolitical category.

This is why the same connection can pass one service and fail another, why a bank asks for confirmation while a streaming catalogue behaves normally, and why the country in one lookup tool disagrees with the country in the next. Nothing is broken in any of those cases. They are simply reading different books.

Nobody knows where a server is

No mechanism in IP reports physical position. An address is a routing identifier, and a database that claims a city has assembled that claim from indirect evidence:

• Registry records. The regional registry knows which organisation holds a range and what postal address that organisation gave. That is a legal address, frequently a head office in another country from the rack.
• Routing announcements. BGP shows which network announces the range and where its peers are. Reliable at the country level, useless at the city level for a network present in twelve cities.
• Latency triangulation. Probes measure round-trip time from known points and solve for a position. Accurate to a few dozen kilometres at best, and defeated by any address that answers from more than one place.
• Self-published geofeeds. An operator can publish a file mapping its own ranges to locations (RFC 8805). This is the only source that involves someone who actually knows, and the only one most operators never publish.
• Behavioural signals. Corrections submitted by users, timezone and language observed in traffic, application telemetry. Excellent for consumer broadband, weak for datacenter ranges where nobody lives.

Five servers, four sources, one day

We ran our own five exits against three public databases on 28 August 2026, plus a fourth source: the geolocation a large hosting platform applies to incoming requests, which is what a website actually reads when it decides where you are. The results are not a scandal, they are the normal state of affairs:

• Germany. Three sources of three say Frankfurt am Main. No disagreement at any level.
• Netherlands. Three of three say Amsterdam. Same.
• United Kingdom. Three of three say London — and the fourth source places that same address in Iran, with the time zone reported as Asia/Tehran.
• France. Two of three say Paris. The third puts the server in Eygelshoven, in the Netherlands, roughly five hundred kilometres away, while the network holding the range is French.
• United States. One of three, in the sense that no city won: two sources say Dallas, one says Buffalo. Those are two thousand kilometres apart, so we publish no city for that location at all.

The British case is the instructive one. Every consumer-facing lookup tool agrees on London; the database sitting in front of a service you are trying to use says Iran. A visitor on that exit is not treated as British by that service. They are treated as Iranian — a country that many platforms restrict outright. The user experiences this as “the VPN is broken”, and no amount of reconnecting will change it, because nothing about the connection is wrong.

Why the errors cluster where they do

1. 1Ranges move and records lag. IPv4 is traded and leased constantly. A block that served Tehran two years ago and serves London today keeps its old record until each database re-derives it, which can take months.
2. 2Leasing hides the user. Much of the IPv4 market is rental. The registry still names the lessor, who may be in a different country from every machine using the range.
3. 3Sub-allocations are invisible. Many databases work at /24 granularity. A hoster splitting a /24 across two cities produces one answer for both, and it will be wrong for one of them.
4. 4Correction pipelines are asymmetric. Consumer broadband ranges get corrected quickly because millions of people generate signals. Datacenter ranges generate almost none, so an error there can sit for years.

What actually breaks

• Regional catalogues and licences. The service reads its own database, not the one you checked.
• Anti-fraud in banking. A country change between sessions is a strong signal; a country change into a sanctioned jurisdiction is a stronger one.
• Captchas and challenge pages. Reputation is scored per range; a wrong country adds a second reason to distrust it — the mechanics are in IP reputation and captchas.
• Prices, currency and tax. Shops pick both from geolocation, and the checkout that follows may not match your card.
• Time zone mismatch. A browser reporting Europe/London against an address the site believes is Iranian is exactly the inconsistency described in the timezone leak article.

Checking an address yourself

1. 1Look it up in at least three sources, not one: curl https://ipinfo.io/<ip>/json, curl http://ip-api.com/json/<ip>, curl https://ipwho.is/<ip>.
2. 2Compare three fields: country, city and ASN. If the countries agree and the cities do not, you have a normal, healthy address whose city nobody can pin down.
3. 3If the countries disagree, note which source the service you care about is likely to use. Large platforms overwhelmingly use MaxMind-derived data rather than the friendly lookup site you just opened.
4. 4Check what a site sees from your browser rather than from a terminal — address, resolver and time zone together — with our connection leak test.

Getting a wrong record corrected

It is possible, it is unglamorous, and it takes weeks. MaxMind, IP2Location and ipinfo all accept correction requests for a specific range with evidence of where it is operated. An operator can go further and publish a geofeed under RFC 8805, which several databases ingest automatically; that is the only fix that scales beyond a single range. As a user, your practical options are to ask your provider to raise it, or to use a different exit while they do.

FAQ