Germany Proxies: How IP Geolocation Really Works When the Site Sees the Netherlands

A scenario that repeats for anyone who works seriously with proxies. You take a residential IP with the geo "Germany." You open a checker — it honestly states Germany, Frankfurt. You visit the target website — and it shows Dutch currency, Dutch results, and a Dutch cookie banner. A second checker indicates that the IP is actually in Belgium. Who is lying?

No one. The problem is that an IP address has no coordinates. Geo-tagging is not a property of the address, but rather a judgment of a specific database that it has collected through indirect methods. There are several databases, they are independent, and they diverge — systematically and predictably. Below, we will analyze where this data comes from, how significant the actual error is based on recent measurements, and what to do about it in practice.

IP has no geography — only estimates

In the packet itself, there is no field for "country." Everything the internet knows about the address is to whom it is assigned according to the registrar's documents and where the BGP routes lead. From this, commercial databases (MaxMind, IPinfo, IP2Location, DB-IP, and others) gather guesses by combining five sources:

• RIR and whois records. The country in the record is the jurisdiction of the organization to which the block is allocated, not the physical location of the machines. A German provider can easily deploy addresses in Amsterdam.
• Geo feeds. The format of self-published geo-data is specified by RFC 8805 (2020), which was replaced by RFC 9632 in 2024 — with validation and detection through RDAP. The operator declares where their subnet is located. This is the only authoritative source, but the coverage is minimal: by the end of 2023, geo feeds published about 2,800 autonomous systems — approximately 34 million IPv4 addresses, or 0.8% of global allocations.
• Routing and BGP prefixes. If one address's location is known, the database extrapolates it to the entire prefix. This is where most errors arise.
• Latency measurements. Triangulation based on RTT from known points works well in densely populated Europe but falls apart where there are few measurement points.
• Partner data. Signals from applications and services that correlate IPs with GPS coordinates of devices.

Each vendor mixes this in their own proportions and according to their own rules. The results do not have to match.

How significant is the error: measurements from 2026

On May 21, 2026, researchers from Virginia Tech (Syed Tauhidun Nabi, Jocelyn Bliton, Tijay Chung, Shaddi Hasan) published a paper titled "Lost in the Prefix: Revisiting IP Geolocation Accuracy Across Networks and Geographies." They compared four databases — MaxMind GeoLite2, IPinfo, IP2Location DB11, and DB-IP Lite — against a benchmark of 16,010 probes from RIPE Atlas in 175 countries and 21,292 pairs of "IP — school" from the UNICEF Giga project. In total, there were 37,302 observations, of which 74.7% were IPv4 and 25.3% were IPv6.

Key figures:

• Fixed networks: median error of 3–16 km depending on the provider. For home wired internet in a developed country, geo works well.
• Mobile networks: median error of 179–207 km. This is more than a tenfold gap compared to fixed networks, and it is consistent across all four databases.
• Rate of gross errors (over 100 km) by region: Europe 9–20%, Americas 8–22%, Asia 53–61%, Africa 66–72%.
• Reason: about 70% of mobile prefixes are physically stretched over more than 100 km. The larger the prefix, the higher the error — regardless of vendor, network type, or region.

An important detail: all four databases make mistakes in roughly the same way and in the same places. This is not "bad vendor versus good" — it is a common limitation of the method. In Global South countries, there are 2–3 times more "gross" prefixes, which is why errors are higher there.

MaxMind itself honestly defines its boundaries: 99.8% accuracy at the country level, about 80% at the state/region level in the USA, and 66% at the city level — with "city" meaning being within a 50 km radius. It is also noted that addresses in mobile networks are used by phones over large distances, and in the case of VPNs or proxies, the database geolocates the server, not the end user.

Why the checker and the website see different things

Here lies the clue to the initial scenario. The checker you opened shows data from its database. The target website looks at its own. These are different answers to the same question, and both are "correct" in their own coordinate systems.

Three specific mechanisms of divergence:

• Different vendors. A website behind Cloudflare gets the country from the CF-IPCountry header — this is Cloudflare's own data, and it regularly diverges from what MaxMind provides for the same address at the same moment. Streaming services and payment systems maintain their own lists, supplemented by behavioral history.
• Different data age. The free GeoLite2 City and Country databases are updated twice a week — on Tuesdays and Fridays. Commercial GeoIP2 databases are released every weekday. A site based on a year-old snapshot of the database will see last year's picture. This also explains why new subnets "settle" for weeks.
• Different levels of detail. Vendors have different policies: some provide city information, while others deliberately round to region or country if confidence is low. The absence of a city is not an error but a refusal to guess.

Four situations where divergence is almost guaranteed

1. Mobile proxies. The worst case by definition: CGNAT, one prefix covering half the country, median error close to 200 km. Expecting precise city information from a mobile IP is pointless — the network is not structured that way. It is also useful to check whether the IP is actually mobile and not a data center with a substituted ASN: the methodology is discussed in the article how to distinguish a real 4G proxy from a fake ASN.
2. Resold and relocated blocks. After an IPv4 subnet is transferred to a new owner, the old country remains in databases for months. The secondary address market is active, making this a common phenomenon rather than an exotic case.
3. Anycast and clouds. The same prefix is announced from dozens of points around the world. The database is forced to reduce this to one location — and any choice will be incorrect for most requests.
4. Registration at the headquarters. The provider is registered in one country but maintains infrastructure in another. The database uses the documents because there is no other data.

What to do in practice

1. Check where it matters, not in the checker. The only meaningful test is to open the target website and see what country and currency it displays. If the task is local Google results or regional prices, the checker is not a criterion for acceptance at all.
2. Cross-reference at least three databases. If MaxMind, IPinfo, and DB-IP agree — the target website will likely see it the same way. Divergence among them is a signal that the address is questionable and will have issues.
3. Separate the requirements for "country" and "city." The country with a decent provider is reliable (99.8% according to MaxMind). The city is a probabilistic measure with a radius of about 50 km even in the best case. Building business logic based on city data can only be done with a margin for error.
4. Look at the prefix, not the address. Check whois and the size of the announced block. If the IP is in a /16 stretched over half the country, no one will have precise localization.
5. Do not confuse geo with reputation. A correct country does not indicate whether the address is marked as a proxy. This is a separate check across different databases — thoroughly discussed in the article about myths about "clean" IPs and reputation checkers.
6. Ask the provider about the geo feed. If the subnet operator has published a geo feed according to RFC 9632, the country and city come from them, not from guesses. This is the strongest argument in favor of a specific pool. Corrections via geo feed are imported and verified by MaxMind once a working day, while one-time corrections take 1–2 working days, after which they enter the next database release.

How this affects the choice of proxy type

From the measurements, a simple rule emerges. If the task requires precise geography — local search engine results, regional prices, geo-targeted advertising — opt for residential proxies on fixed lines: there, the median error is measured in single kilometers. If the task requires trust from the platform regarding the type of network — social networks, messengers, mobile applications — choose mobile proxies, but keep in mind that the point on the map will fluctuate within the region. Combining both requirements in one IP is physically impossible: this is a limitation of mobile network architecture, not the quality of the pool.

For regions with a high share of gross errors — Asia, Africa — plan at the country level, not the city level. There, according to the study, every second or third address deviates from the actual location by more than a hundred kilometers for any vendor.

Conclusion

"The wrong country is determined" almost never means that you were deceived with the proxy. More often, it means that you compared responses from two different databases and were surprised that they did not match. The correct course of action: find out which database the target platform reads, check the geo specifically on it, cross-reference questionable addresses across multiple sources, and do not expect city-level accuracy from mobile networks, which they do not have and will not have.

And keep in mind the main figure of this year: 3–16 km on fixed lines versus 179–207 km on mobile. This explains most of the complaints about geo with proxies even before you open a support ticket.