What Geographic Targeting Actually Resolves To

Every proxy dashboard has the same widget: a country flag, sometimes a city name, sometimes a slider for “state” or “ZIP.” You pick United States, New York, hit connect, and get an IP. What that IP actually is, geographically, depends on a chain of database lookups that nobody in that dropdown is showing you. Understanding that chain is the difference between trusting a label and knowing what you’re actually running through.

I run proxy infrastructure across residential, mobile, and datacenter stock daily. The gap between “targeted country” and “actual location” is one of the most misunderstood parts of the business, on both the buyer and seller side. This is a breakdown of where geo targeting data comes from, why it degrades at finer granularity, and how to check what you’re actually getting instead of taking the label on faith.

IP geolocation isn’t GPS, it’s inference

An IP address doesn’t carry a location. There’s no lat/long baked into IPv4. Every “this IP is in Chicago” claim is an inference, built from a handful of overlapping sources:

Regional Internet Registry (RIR) allocation records. ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC assign address blocks to ISPs and organizations, and those records (WHOIS) usually list a country, sometimes a city, for the registrant. This is the most reliable layer for country-level accuracy because it’s tied to who legally holds the block, not where a specific packet originated.

Commercial geolocation databases. MaxMind’s GeoIP2, IP2Location, DB-IP, and similar vendors build their own maps by combining RIR data with ISP-submitted records, traceroute topology, and crowdsourced signals (apps and SDKs that report GPS alongside the IP the request came from). These databases are what almost every website, ad network, and fraud system actually queries when they say “this visitor is in Ohio.” They update on a schedule, not in real time, so an IP that gets reassigned to a different city can show the old location for weeks.

BGP and ASN routing data. Autonomous System Numbers tell you which network operator announces a given block, and large ISPs’ ASNs are often tied to a specific service footprint (a regional cable provider’s ASN might only ever serve three states). This is a strong country signal and a moderate region signal, but it says nothing about the individual subscriber’s city.

None of these sources know where a device physically is. They know where an address block was registered, and they infer the rest from patterns. That’s the ceiling on accuracy before you even get to proxy-specific issues.

Why datacenter IPs are geographically boring but honest

Datacenter proxy geo is, mechanically, the most trustworthy kind. A cloud provider spins up capacity in named regions (us-east-1, ap-southeast-1, eu-central-1) and the IP ranges assigned to that region are static, documented, and consistent with the RIR records. If a datacenter proxy says Singapore, it’s almost always actually routed out of a data center in Singapore, because the whole point of regional cloud infrastructure is that it lives where it says it lives.

The tradeoff isn’t geographic accuracy, it’s the plain fact that the IP is recognizably a datacenter IP. Hosting-range ASNs are well known and widely cataloged, so a site checking whether traffic is coming from a residential ISP versus a cloud provider can make that distinction from the ASN alone, independent of geolocation. Datacenter proxies give you honest country-level targeting and a network fingerprint that’s easy to classify as non-residential.

Why residential and mobile geo drifts

Residential and mobile pools are where the label starts to diverge from reality, for reasons that are structural, not shady:

Carrier-grade NAT pools. Mobile carriers route enormous numbers of subscribers through shared IP pools, and those pools are frequently regional rather than local. A subscriber’s device physically in one city can be assigned an egress IP whose geolocation database entry reflects a carrier hub two or three hundred kilometers away. This is a property of how mobile networks allocate addresses, not a proxy provider trick.

IP churn and stale databases. Residential IP assignment changes constantly, ISPs reassign blocks between regions as demand shifts, and commercial geolocation databases lag behind those changes. An IP correctly mapped to a city last quarter can now belong to a different subscriber in a different part of the same state, with the database not yet updated.

Exit infrastructure versus device location. In a peer-based residential network, the “location” reported is wherever that peer device’s ISP-assigned IP resolves to in the geolocation database, which is a proxy for the device’s location, not a direct measurement. Most of the time this is accurate at the country level and reasonably accurate at the region level. City-level claims are the least reliable, because that’s the granularity where database staleness and CGNAT hub effects matter most.

This is why serious providers publish country and sometimes state or region targeting with confidence, and hedge harder on city-level guarantees. Anyone promising exact ZIP-code precision on residential or mobile stock is making a claim the underlying infrastructure can’t consistently back up.

What a geo mismatch signals to the site on the other end

This matters beyond just “did I get the right country.” Sites doing fraud and bot detection cross-reference IP-inferred location against other signals in the request: browser timezone, Accept-Language headers, payment card issuing country, TLS/JA3 fingerprint patterns typical of the claimed region. When those signals disagree, that inconsistency itself is a detection input, independent of whether the underlying IP is a proxy at all.

This is worth understanding defensively, not as a checklist to game. A scraper that requests a US-geo IP but leaves a browser timezone set to Europe, or serves a UI in the wrong language for the targeted locale, isn’t fooling a detection system, it’s handing it a second, cheap signal to correlate against. The fix isn’t a set of tricks to align every header, it’s recognizing that geo accuracy is one input among several coherence checks, and a proxy pool with poor geo accuracy makes that coherence harder to maintain honestly, not easier to fake.

How to actually check what you’re getting

Don’t take the dashboard’s country flag at face value. A basic verification pass, run against your own connections:

Query the exit IP against two or three independent geolocation sources (a commercial API and a couple of free WHOIS/IP lookup services) and see if they agree at the country and region level. Disagreement at city level is common and usually not a red flag on its own. Disagreement at country level is.
Check the ASN and organization name tied to the IP. A residential ASN belonging to a known ISP in the target country is a stronger signal than the geolocation label alone.
If region or city targeting matters for your use case, test a sample of IPs from that pool over time rather than a single connection, since churn means one good result doesn’t guarantee the next one.
Compare what the provider’s dashboard claims against what the lookups return, on a sample large enough to see a pattern, not one lucky or unlucky IP.

None of this produces a guarantee. It produces a realistic picture of how tight a given pool’s targeting actually is, at the granularity you need, so you can plan around real accuracy instead of marketing accuracy.

The honest baseline

Country-level targeting, across datacenter, residential, and mobile proxy types, is generally reliable, because it’s anchored in RIR allocation and ASN data that doesn’t move much. Region and city-level targeting is progressively softer, especially on mobile and residential stock, because it depends on geolocation databases inferring from patterns that lag real-world changes. No provider, including the ones with the cleanest dashboards, can promise pinpoint city accuracy on IP types that are inherently churny. Anyone who does is selling you a label, not a location.

If you’re comparing proxy providers for geo work, we break down what different proxy types actually deliver, how to test claims instead of trusting them, and where residential, mobile, and datacenter targeting tends to hold up or fall apart. Start at the homepage for the rest of the series.

Get new guides and videos first — join the Telegram channel.

The dropdown lies a little, on purpose