Blog / IP & privacy

Why IP Geolocation Is Inaccurate: 11 Databases, 11 Answers

2026-10-20cdnping editors9 min read

Inaccurate IP geolocation is the norm. An IP address carries no coordinates, so every "location" is an inference a database makes from registration records, routing and measurements. Each provider uses different sources and updates on a different schedule, so results differ. Country-level answers usually agree. City-level answers often land in a neighboring city, or even in another province. To judge which result to trust, check whether several databases agree and whether the registration record and network type fit, rather than relying on any single provider.

This article covers the data sources, why they disagree, how to verify a location yourself, and finally how to read the "11-database vote" and confidence score on the cdnping IP and environment check page.

#Does an IP address contain location information?

No. An IPv4 address is a 32-bit number and an IPv6 address is 128 bits. No field in the protocol says "this address is in Shanghai."

Addresses are allocated level by level. IANA hands large blocks to the five Regional Internet Registries (RIRs; APNIC covers Asia-Pacific). RIRs allocate to ISPs, cloud providers or enterprises, and ISPs then assign to specific metro networks, data centers or home broadband lines. Only the final user knows where the address is actually used, and that layer is usually not public.

So an IP geolocation database pieces together the most likely location from public clues. Different clues and different methods give different answers.

#Where does IP geolocation data come from?

There are roughly four common sources, and each provider combines and weights them differently.

#1. Registration data (RIR / WHOIS / RDAP)

RIR databases record who each network block was allocated to, including the organization name, country code and sometimes an address. Most country-level decisions start here.

The catch is that registration data records where the holder is registered, not necessarily where the block is used. A cloud provider headquartered in country A can use the same registered block in a data center in country B, and a national ISP's block may simply be registered at its headquarters city.

#2. Routing data (BGP and ASN)

The BGP routing table shows which autonomous system (ASN) announces a prefix and from which locations. The ASN's owner helps distinguish data centers, home broadband and mobile networks, and the announcement locations provide geographic hints.

But one prefix can be announced from many places at once (Anycast) and can move at any time. Routing only tells you where traffic enters and leaves, which is not the same as where the user is.

#3. Active measurement (latency and traceroute)

Some databases send packets to the target IP from probes around the world, measure round-trip time, and use the upper limit of light's speed in fiber to work out a distance range. Cross-referencing several probes narrows the result to a rough region.

This method is good at establishing that "this IP cannot be in that place," but for a specific city it can only give a range. Targets that do not answer ping, detoured paths and tunnels in between can all skew the result.

#4. Operator self-reporting and user feedback

Some network operators publish a geofeed (a CSV format defined in RFC 8805) stating which country and city each of their prefixes is used in. Some databases adopt geofeeds and some do not, and the timing of adoption varies.

Another source is user corrections and application-side data, such as someone submitting "this IP is actually in city X." This data is sometimes very accurate and sometimes only reflects a single point in time.

#Why do different IP databases give different locations?

Putting the four sources together, disagreements come mainly from the following situations:

Update lag is the easiest to overlook. Many IP geolocation databases publish new versions on a fixed cycle, and websites that consume them may cache them for a while. When a block moves from a data center in location A to one in location B, the databases update one after another, leaving a transition period in which they disagree.

The difference between broadcast IPs and native IPs also bears directly on geolocation: a broadcast IP is registered in one country and announced for use in another, which is exactly where databases split into two camps. For details, see Native IP vs broadcast IP.

#How accurate can city-level geolocation get?

Providers describe their own accuracy differently and there is no unified public benchmark, so no specific percentages are given here. By level, the picture is roughly this:

• Country level: in most cases databases agree. Disagreements cluster around broadcast IPs, Anycast and recently moved blocks.
• Province / state level: home broadband and mobile networks can usually be matched. For data center IPs it depends on whether the data center's registration is accurate.
• City level: this is inference at heart. A home broadband IP often resolves to the city of the ISP's aggregation node, not the district where you live. Mobile networks are coarser, and an entire province may resolve to one city.
• Latitude/longitude: many lookups return coordinates with several decimal places, which does not imply precision. They are usually a city center or a database's internal default point, and the accompanying "accuracy radius" is worth more attention than the coordinates themselves.

If a website shows your IP in a neighboring city, in most cases nothing is broken. City-level geolocation is simply this precise.

#Check an IP's location yourself: five steps

These steps do not depend on any particular database and suit the question "why does this website think I'm in another region?"

#Step 1: Confirm which egress IP you are checking

One machine can have several egress paths: IPv4 and IPv6 may take different routes, the browser and the command line may use different proxies, and different websites may be routed to different egresses. Look at each separately first:

# IPv4 / IPv6 egress as seen from the command line
curl -4 https://cloudflare.com/cdn-cgi/trace
curl -6 https://cloudflare.com/cdn-cgi/trace

In the output, ip= is the egress address, loc= is the country code Cloudflare determined, and colo= is the Cloudflare data center you connected to. To see the browser-side egress, open /en/ip, which also runs multi-egress detection. If your IPv4 and IPv6 egresses differ, start with IPv6 proxy not working: troubleshooting mismatched egress on dual-stack networks.

#Step 2: Look up the registration record (RDAP)

RDAP is the structured replacement for WHOIS and returns JSON, which is easier to read. The example below uses 203.0.113.10, an address reserved for documentation; substitute your own egress IP:

# Query APNIC's RDAP service; if the address is not managed by APNIC, follow the redirect to the right RIR
curl -sL https://rdap.apnic.net/ip/203.0.113.10 | jq '{name, country, startAddress, endAddress}'

# Or use traditional whois
whois 203.0.113.10 | grep -iE 'netname|country|descr|org'

Focus on country (the registered country) and name / netname (the block name). Block names often include a marker for a data center, cloud provider or broadband service.

#Step 3: Look up the ASN to determine the network type

whois -h whois.radb.net 203.0.113.10 | grep -iE 'origin|descr'

Once you have the ASN, see who owns it: a home broadband ISP, a mobile carrier, a cloud provider or a CDN. Data center IPs and home broadband IPs behave very differently in geolocation databases; see Datacenter IP vs residential IP: what's the difference for how to tell them apart.

#Step 4: Compare several databases and trust only the part they agree on

Put the results of several databases side by side and read them level by level: country, then province, then city. Wherever disagreement starts, trust only down to the level above it.

#Step 5: Use latency as a reverse check

Suppose a database says the IP is in Tokyo, but your round-trip latency to it from within China is about the same as to the US West Coast. That city conclusion does not hold up. Latency cannot pinpoint a location, but it can rule out impossible ones. For the principle, see How websites detect proxy use from latency.

#How to read cdnping's 11-database vote and confidence

The "Egress IP intelligence" section on the /en/ip page queries 11 geolocation databases at once, votes on the result to produce a location, and attaches a confidence score. Here is how to interpret it:

• The vote result is the location most databases agree on, not any single provider's answer. When most of the 11 databases return the same country and city, it is more reliable than a single-database lookup.
• Low confidence means the databases clearly disagree. In that case, expand the page to see each database's individual result.
• Country agrees, cities scatter: the most common case. As described above, trust only the country or province.
• Country splits into two camps: suspect a broadcast IP or a recently moved block first, and read it together with the RDAP registration data and the "native IP / broadcast IP" verdict on the page.
• IP type shows as data center: geolocation for data center blocks mostly comes from registration records, so city-level results more often mix up the headquarters city and the data center city.

The data definitions behind each check are on the methodology page. Note that agreement across databases does not prove the result is the true location: if several databases rely on the same upstream data, they will be wrong together.

#A website thinks I'm in another region. What now?

First tell apart two situations:

1. The geolocation database is wrong: you really are browsing directly from location A, but a website thinks you are in B. You can submit a correction to the relevant database (most providers have a public correction form), or ask your ISP whether it publishes a geofeed. Corrections take effect only after the database publishes a new release, and the website may also cache the old data.
2. Your egress is not what you think it is: routing rules, IPv6 or DNS sent some traffic through a different egress. Use the multi-egress detection and DNS leak test at /en/ip to investigate, then read How Chinese websites see your real IP to understand the routing results.

Some online services offer or restrict features by region, and the basis for that is often more than an IP geolocation database. When you see such a notice, follow the service provider's official guidance and comply with the terms of service and local regulations.

#Are geolocation and IP reputation the same thing?

No. A geolocation database answers "where is this IP," while a reputation database answers "does this IP have an abuse history, and is it a proxy or data center?" Their data sources differ and each can disagree internally. The same IP can easily get consistent locations across databases while reputation scores differ widely; see Why IP purity checkers disagree for the reasons.

To check your egress IP, DNS, IPv6 and API connectivity in one pass, work through the Developer network self-check checklist (2026 edition), then use the homepage speed test to see actual connection conditions to each AI API.

The checking order fits in one sentence: confirm the egress first, then look at RDAP and the ASN, then compare several databases and stop at the level where they start to disagree, and use latency to rule out impossible locations when needed.