How IP Geolocation Actually Works (and Where It Breaks)
A practical explanation of how an IP address is mapped to a country, region and city, why city accuracy varies, and how to use geolocation data responsibly.
# How IP Geolocation Actually Works
An IP address is not a coordinate. It is a routing identifier that a regional internet registry (RIR) allocated to an organisation, and that organisation announced to the internet through BGP. Everything you see in a geolocation response is inference built on top of those two facts.
The four layers of evidence
- Registry data. ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC publish the country an allocation was registered under. This is the most stable signal and the reason country accuracy is consistently high.
- BGP routing. The announcing ASN tells you which network actually carries the traffic. A block registered in the Netherlands may be announced by a carrier in Brazil.
- Network measurement. Latency between known probes and a target constrains where the host can physically be. Light in fibre travels roughly 200 km per millisecond, so round-trip time puts a hard ceiling on distance.
- Self-reported and derived hints. rDNS hostnames (
ae1.core1.fra3.example.net), IX peering locations, and published geofeeds from the operator itself.
A good provider fuses all four. A weak one leans on a single stale registry dump.
Why country is easy and city is hard
Country-level accuracy is typically in the high nineties because registry and routing evidence agree. City-level is a different problem:
- Mobile carriers route subscribers through a handful of national gateways, so a phone in a small town can appear in the capital.
- Large ISPs re-use pools across metro areas and rotate them.
- Corporate VPNs and CGNAT concentrate thousands of users behind one exit.
Treat city as a probable metro, not a street address. If a decision would be unfair when the city is wrong by 80 km, do not base it on city.
What to do with the accuracy radius
Every serious geolocation record ships a confidence radius. Use it as a gate: if the radius is larger than the area your rule cares about, fall back to country or to a non-geographic signal. Silently ignoring the radius is how teams end up blocking legitimate customers.
Geolocation and anonymisation are two questions
"Where is this IP?" and "is the user hiding where they are?" are separate lookups. A datacenter IP in Frankfurt is geographically correct and behaviourally suspicious at the same time. Guarda returns both the location fields and the classification (residential, mobile, business, hosting, VPN, TOR) in one response so you never have to guess which one drove a decision.
A sane default policy
- Personalise content on country.
- Price and tax on billing country, never on IP alone.
- Use city only for analytics and soft nudges.
- Escalate on classification and risk score, not distance.
Geolocation is excellent context and a poor verdict. Build your rules that way and the data will hold up.