Ask three free lookup services where an address is and you will often get three answers: one says the city, one says the province capital, one says the country and nothing more. A tool flags the address as a crawler; the ISP's own whois says consumer line.
This is not a bug in any single service. "Geo-IP" names three different datasets that happen to share an output format, and most disagreements come from comparing the wrong one. Knowing which layer answered turns a confusing result into a diagnosis.
Three layers, three sources of truth
Registration data comes from RIR records — who holds the block, which country it was allocated in. Authoritative for the holder, weak for the user: a block allocated to a German subsidiary can be routed to Singapore tomorrow.
Routing data comes from BGP: which ASN announces the prefix, and where peers see it. It tells you where traffic physically lands, and it responds within hours to a network change.
Observed data comes from panels that record where real users of that address appear. Most accurate for consumer geography, slowest to update — a static residential IP that changes hands can keep its old city for months.
| Layer | Owner of the truth | Typical failure |
|---|---|---|
| Registration (whois/RDAP) | RIR | Block allocated in one country, operated in another |
| Routing (BGP/ASN) | Network operator | Anycast: one prefix, many locations |
| Observed (panel-based) | Data vendor | Thin samples, stale history, over-generalised centroids |
A vendor's answer is usually a blend, weighted by what its own customers observed. That weighting is proprietary, which is why two vendors disagree and both claim 99% accuracy.
Why the answers diverge
Anycast. A CDN prefix is announced from dozens of sites. Which one your lookup resolves to depends on where the query comes from, not where the address is.
Registration lag. Blocks are re-allocated faster than databases update: a /24 sold to a hosting provider in March may still read as a residential ISP in June.
Country-level fallback. With no city-level confidence, a vendor returns the country centroid — a specific coordinate that looks precise and means nothing. In testing, some services return the same national coordinate for every address in a country while still reporting the correct region name.
Heuristic side effects. Provider-maintained "datacenter" lists are the worst offender: they are built from ASN lists, and ASN lists leak. In our own spot checks, one widely copied list included 16 Chinese carrier ASNs, which misclassifies consumer lines wholesale. A lookup that says "datacenter" often means "someone's ASN list says so", not "this is a server".
Make the disagreement measurable
Query three independent sources and compare country, region, and city separately; aggregate agreement hides the case where all three agree on country and none on city.
import json, urllib.request
SRC = {
"ipapi.is": "https://api.ipapi.is/?q={ip}",
"ip.sb": "https://api.ip.sb/geoip/{ip}",
"ipinfo": "https://ipinfo.io/{ip}/json",
}
def look(ip):
out = {}
for name, tpl in SRC.items():
try:
req = urllib.request.Request(tpl.format(ip=ip),
headers={"User-Agent": "geo-probe/1.0"})
with urllib.request.urlopen(req, timeout=8) as r:
d = json.loads(r.read())
out[name] = (d.get("country") or d.get("country_code"),
d.get("region"), d.get("city"),
d.get("is_datacenter") or d.get("org", "")[:24])
except Exception as e:
out[name] = ("ERR", type(e).__name__, "", "")
return out
for ip in ["1.1.1.1", "8.8.8.8"]:
print(ip, look(ip))
Run it against addresses you already know, not random ones: you need a control. If one source is the outlier on the same field across every address, its dataset is stale for your region — not merely imprecise.
Reading the disagreement
| Symptom | Likely layer at fault | What to trust |
|---|---|---|
| Country differs | Anycast or BGP change | Routing data, checked today |
| Region correct, city is a national centroid | Observed data with country fallback | Region name; discard coordinates |
| Country/region right, "datacenter" flag wrong | Provider ASN heuristic | ASN holder type from RDAP, not the flag |
| Everything right except ISP name | Registration lag after re-allocation | Routing data (ASN) again |
| Different answer per request | Load-balanced vendor backends | Pin one endpoint for reproducibility |
Two rules follow. Never mix fields from different sources in one decision — country from vendor A and city from vendor B is how a consistent result becomes inconsistent. And record which vendor answered: a comparison with unknown provenance is unreproducible.
Five mistakes worth avoiding
- Treating country-centroid coordinates as data. If region is right and city is the capital of a huge country, the coordinates are a placeholder.
- Trusting a "datacenter" boolean over the ASN. The flag is a list lookup; the ASN is a fact.
- Comparing vendors at different times. Datasets update weekly; a run from last month is a different experiment.
- Judging a proxy by one lookup. Check it against the platform you target.
- Assuming a mismatch means the proxy is bad. Often the database is late and the session is healthy.
FAQ
Which database should I trust for a proxy exit?
None single-handedly. Use routing data (ASN, prefix) to establish what the exit is, and observed data to establish where the platform thinks it is. When they conflict, the platform's vendor decides your outcome — even when it is wrong.
Why does one service report a precise city and another only a country?
Precision is a claim about confidence, not an extra fact. Services with thin panel data fall back to country centroids and label them as cities; the coordinate looks exact but is a national placeholder.
Can a residential IP be flagged as a datacenter?
Yes, regularly. The usual cause is a provider-maintained ASN list that includes carrier blocks, or a hosting reseller announcing consumer space. Check the ASN holder type first.
Does geolocation affect whether an account gets flagged?
Indirectly. Platforms score consistency: the region your session claims must match the region your exit resolves to in their database. An accurate IP their vendor misplaces is still a mismatch to them, which is why the fix is a different exit, not a better lookup tool.
Reading query results correctly matters most when a proxy "looks wrong" but behaves fine — the note on why router-level IP lookups report crawlers covers those false positives, and the proxy knowledge base covers exit selection generally.
Top comments (0)