How IP Geolocation Works — and Why It Gets It Wrong

IP geolocation databases map IP addresses to physical locations. Every time a website serves you region-specific content, a CDN routes your request to a nearby edge node, or a streaming service enforces licensing restrictions by country, it is consulting an IP geolocation database. Understanding how these databases are built — and where they fail — is essential for anyone operating internet infrastructure or interpreting geolocation data.

How Geolocation Databases Are Built

Major providers like MaxMind, IP2Location, and IPinfo build their databases from multiple independent data sources, then resolve contradictions through proprietary confidence-scoring logic.

RIR Allocation Data

The foundation of any geolocation database is allocation data from the five Regional Internet Registries. When an RIR allocates a block to an organization, the WHOIS and RDAP records contain the organization's registered country and address. This gives a coarse country-level signal for the allocating organization's headquarters. For large ISPs that operate nationally, this is often correct. For multinational corporations or cloud providers, the registered country may bear no relation to where the IP addresses are actually deployed.

Latency Triangulation

More precise geolocation uses active measurements. A geolocation provider pings an IP address from many globally distributed vantage points and uses the round-trip times to triangulate the likely position. If a target responds in 2 ms from New York, 80 ms from London, and 150 ms from Tokyo, the target is almost certainly in the northeastern United States.

The precision of triangulation is limited by several factors: speed-of-light constraints (1 ms corresponds to roughly 150 km in fiber), asymmetric routing (packets may take different paths in each direction), and the geographic distribution of measurement vantage points. Triangulation typically achieves city-level accuracy for well-connected targets and degrades to regional accuracy or worse for remote locations.

User-Submitted Signals

MaxMind and others operate networks of opt-in users who submit their IP addresses alongside verified location data (typically GPS coordinates from mobile devices). This provides ground truth that can be used to calibrate and correct database entries. The coverage is uneven — major metropolitan areas have dense signal; rural areas in developing countries have sparse signal.

BGP Route Data and AS Metadata

The AS path to a prefix, combined with the origin AS's registered geography, provides another geolocation signal. An IP address originated by a regional ISP in Chile is almost certainly physically in Chile. Route collectors like RIPE RIS and RouteViews expose this routing data; geolocation providers use it to assign country-level confidence to large blocks.

Geofeeds (RFC 8805)

RFC 8805 defines a simple CSV format called a geofeed that allows IP address holders to self-publish accurate location data. A geofeed file lists IP prefixes alongside their country, region, and city codes. The file is published at a URL that operators register in their RDAP or WHOIS records using the Geofeed: field.

# Example geofeed (RFC 8805 format)
# ip-prefix,alpha2code,region,city,postal
2001:db8::/32,US,US-CA,San Jose,95101
203.0.113.0/24,DE,DE-BY,Munich,80331

Geofeeds give network operators direct control over how their address space is geolocation-mapped. Cloud providers, CDNs, and large ISPs increasingly publish geofeeds because inaccurate geolocation creates support burden and breaks geo-fenced services. MaxMind, IPinfo, and Google (for Google Maps IP location) all consume geofeeds. The anycast nature of many cloud deployments makes geofeeds especially important — without them, the geolocation database might map an anycast prefix to a single city when the same prefix is actually served from dozens of locations worldwide.

Why Geolocation Is Often Wrong

VPNs and Proxies

A user connecting through a VPN endpoint in another country will appear to be in that country. VPN providers deliberately use IP addresses registered in their operating countries to ensure the geolocation database returns the desired location. Streaming services maintain blocklists of known VPN and proxy IP ranges, but this is an ongoing arms race — new VPN egress IPs are added regularly. There is no reliable technical mechanism to distinguish a genuine user in a country from a proxied user using an IP address registered there.

CGNAT and Carrier Address Space

CGNAT (Carrier-Grade NAT) aggregates thousands of residential customers behind a single public IP address. The geolocation of that IP is the geolocation of the CGNAT infrastructure — typically a central exchange point, not the customers' actual locations. An ISP running CGNAT from a data center in Chicago will have all its customers appear to be in Chicago regardless of whether they are in suburban homes 200 kilometers away. As IPv4 exhaustion drives broader CGNAT deployment, this problem worsens.

Anycast Prefixes

Anycast routing announces the same prefix from multiple geographic locations simultaneously. When you send a packet to 1.1.1.1, BGP routing delivers it to the nearest Cloudflare edge node — which might be in Frankfurt, Singapore, or São Paulo depending on where you are. A geolocation database will report a single location for that IP because it has no mechanism to know that the anycast prefix is served from dozens of locations. The reported location is typically based on the address holder's registration data or the location of one specific announcement seen by the database's measurement system.

Stale Allocation Data

IP blocks are reallocated. A block that belonged to a Brazilian ISP in 2015 may have been returned to LACNIC, reallocated to a cloud provider, and now serves customers globally. Geolocation databases update their data periodically, but the update cycle is measured in days to weeks. Businesses that move or reassign address space can find that their new allocations geolocate incorrectly for months.

Satellite and Mobile Networks

Geostationary satellite providers (and increasingly LEO constellations like Starlink) have ground station IP addresses that may be thousands of kilometers from the end user. Mobile network breakout points similarly reflect carrier infrastructure location, not user location. A user in rural Norway connecting through a Starlink ground station in Germany will geolocate to Germany.

IP Geolocation vs. GPS

IP geolocation and GPS measure different things. GPS locates a physical device based on satellite signals with meter-level precision. IP geolocation locates a network interface based on internet routing topology with kilometer-to-country-level precision. They are complementary: mobile devices typically use GPS for user-facing mapping applications and IP geolocation for server-side analytics, fraud detection, and content delivery decisions.

Critically, IP geolocation is not legal evidence of physical presence. A user with an IP address geolocating to France may be in France, may be using a French VPN server, or may be a French ISP customer who is currently traveling abroad. Regulatory compliance based purely on IP geolocation (GDPR territory restrictions, export control compliance) is probabilistic, not definitive.

How CDNs and Anycast Use Geolocation

CDNs don't actually rely on IP geolocation databases for routing — they use BGP routing topology. When your browser makes a request to a CDN-served domain, DNS returns an IP address, and BGP routes your TCP connection to the nearest edge node based on network distance, not geographic distance. The two usually correlate, but not always: a user in Western Ireland might route to a London CDN node despite there being infrastructure in Dublin, if the BGP path to London is shorter in terms of AS hops.

IP geolocation databases are used by CDNs for analytics (where are our users?), content localization (which language to serve?), and geo-fencing (which content licensing applies?). The anycast routing decision itself happens at the network layer without any database lookup.

Correcting Geolocation Errors

If your organization's IP space is geolocating incorrectly — a common problem for cloud workloads, CDN operators, and ISPs that have received reallocated address space — there are several remediation paths:

Publish a geofeed. Register a geofeed URL in your RDAP record (the remarks field with Geofeed: prefix) or via your RIR's portal. MaxMind, IPinfo, Google, and Apple all consume geofeeds. This is the most effective mechanism for bulk corrections.

Submit directly to database providers. MaxMind accepts correction requests through their website for their GeoLite2 and GeoIP2 products. IPinfo provides a similar mechanism. Direct submissions can update records within days rather than waiting for the next scheduled database rebuild.

Work through your upstream RIR. If the error stems from stale allocation data (the RIR record still shows the previous holder's country), filing a resource transfer with the RIR and ensuring the new registration country is correctly set will propagate corrections to databases that use RIR data as their primary source.

For organizations that depend on accurate geolocation — streaming platforms, e-commerce sites with geographic pricing, or services with regulatory compliance requirements — monitoring geolocation accuracy across the major providers on a regular schedule is worthwhile. Tools like Cloudflare's IP geolocation check and MaxMind's own demo tool can verify current database state for any IP.

Explore It Live

Look up IP addresses to see how routing data relates to geolocation signals:

• 1.1.1.1 — Cloudflare's anycast DNS; the prefix is announced globally but geolocates to a single location in most databases
• AS7922 — Comcast; a major North American ISP operating CGNAT; see the scale of their address allocations
• AS16509 — Amazon AWS; a cloud provider whose address blocks serve customers globally despite regional registrations

Enter any IP or ASN in the lookup box to see BGP routing data and RIR registration — the registration country in the RDAP data is the raw signal that geolocation databases start with.