What an address says, and what it does not
5 October 2026 · figures measured 5 October 2026
One address, put to two geolocation services in the same minute. One answered with a city in central Germany. The other answered with a different city, about 150 kilometres away.
Neither service was broken, and neither was guessing wildly. The disagreement was the most informative thing either of them returned.
What the lookups said
| Field | Service A | Service B |
|---|---|---|
| Country | Germany | Germany |
| Region | Hessen | Hesse |
| City | one city | another, ~150 km away |
| Network operator | same hosting company | same hosting company |
| Proxy / hosting flags | not offered | both true |
The two agreed on everything that was actually knowable and disagreed on the one field people quote. Service B also answered a question service A was not asked: the address belongs to a hosting range, and traffic from it is proxied.
Why a datacentre has no city
A geolocation database maps addresses to places using registration records, routing announcements and whatever the operator publishes. For a consumer connection that chain ends at a subscriber somewhere, and the answer is roughly meaningful.
A hosting range has no subscriber. It has a rack, and the rack's address is not the address of whoever is renting it this month. Services fall back to the operator's registered address, or the midpoint of an announced block, or the last place the range was seen behaving like a consumer one. Those are different fallbacks, so they give different cities — which is precisely why the two answers diverge, and why the divergence is the signal rather than the noise.
Two facts that look like one
There is a second address-shaped fact that often sits next to the first and is not the same thing. A country reported by the network in front of an application — a CDN or a load balancer — is derived at request time from routing, and it is usually right at the country level. A city from a geolocation database is derived from a dataset, after the fact.
Storing both in one row makes them look equally solid. They are not. The country is reasonable; the city, on a hosting range, is somewhere between a guess and an artefact.
The language header is not a country either
The same row carried a language preference that did not match the country at all — a browser asking for one language, connecting from a network registered in a country that speaks another. That is not a contradiction and not a tell. It is ordinary: people travel, emigrate, use a VPN endpoint wherever it is cheapest, and set their browser to the language they read in.
Read as corroboration it produces a confident story about who somebody is. Read honestly it says one thing: this browser prefers this language.
Why this matters for a swap
Everything above is the raw material of the correlation this project exists to make harder. A provider sees an amount, a time, a deposit address and whatever the network in front of it reports. Join enough of those and separate transfers stop being separate.
The useful conclusion is not that geolocation is worthless. It is that the confident fields are the weak ones. A country is weak evidence and reads as weak. A city with a postcode reads as strong evidence and, on a hosting range, is manufactured — which makes it worse than nothing, because it invites a conclusion the data cannot support.
The same asymmetry runs through splitting: the signals that look decisive are rarely the ones that do the work.
Method
One address from this deployment's own records, queried against two public geolocation services on the date above, within the same minute. The address itself is not reproduced here and neither is the customer it belonged to; the cities are described rather than named for the same reason. What this deployment records, and why, is set out on the privacy page.
Every figure above can be checked against the providers yourself — no account, no sign-up, and nothing is held for you at any point.