IP Geolocation Database
A vendor’s mapping from addresses to places. It is an estimate that different vendors make differently, and sites choose which one to believe.
An address does not contain a location. What exists is a set of commercial databases that map ranges to countries, regions and cities, built from registry records, provider disclosures, latency measurements and inference. Each vendor builds its own, and they disagree.
Country accuracy is high and city accuracy is not. Vendors themselves publish city-level accuracy well below what the interface suggests, and the number varies by country. This is the technical reason city targeting is worth asking for in some markets and a waste in others.
For collection the consequence is direct. The site you are visiting looks the address up in the database it licensed, not the one you checked. Two services can honestly report two different cities for one exit, and neither is lying.
The practical rule follows from that: verify the exit against a lookup, but treat the target’s behaviour as the real answer. If a marketplace shows you prices for the neighbouring region, the marketplace is right about what it will do, whatever your checker says.
How a mapping gets built
Registry data gives the starting point: which organisation holds a range and in which country it was allocated. That is reliable at country level and says nothing about cities.
Providers may publish their own geofeeds describing how they use their ranges internally. Where these exist they are the best source; where they do not, vendors infer from latency, from routing and from observed user behaviour.
Inference is where the disagreement comes from. Two vendors measuring different things at different times legitimately arrive at different cities for the same range, and both update on their own schedules.
What to check and what to trust
Check the exit, then check the target, and record what each of them said:
Two answers about one address
# what a lookup thinks
curl -s -x login_c_DE_city_Munich:password@proxy.sotaproxy.com:10000 https://ipinfo.io/json | grep -iE "city|region"
# what the target thinks, which is the answer that matters
curl -s -x login_c_DE_city_Munich:password@proxy.sotaproxy.com:10000 https://target.example/ | grep -iE "delivery|region|shipping" | head -3- If a city request cannot be filled, the exit falls back to country level. Log that: a silent fallback turns a city dataset into a national one.
- Store both the requested city and the observed region on every row. Without both, a mismatch is undiagnosable a week later.
- For most jobs country level is the honest resolution. City targeting earns its cost where prices or results genuinely differ by region, and the country pages say where that is.
Common misunderstandings
The address does not know where it is
Location is attributed from outside. Nothing in the packet carries a city.
Your checker is not the target’s checker
Sites license their own database. Agreement between yours and theirs is a coincidence, not a rule.
City accuracy is not country accuracy
Country is close to certain; city is a probability that varies by market and vendor.
A wrong city is not always a wrong address
The address may be exactly where you asked while the database has not caught up with the range.
Дивись на практиці
Готовий використовувати ip geolocation database?
SotaProxy надає доступ до ротуючих резидентських, мобільних, дата-центр та ISP проксі. Без мінімальних платежів.
Почати