Geolocation and proxy targeting: city-level vs ASN-level
When people start buying proxies, most think in countries. “I need a US proxy” or “get me something in Vietnam.” That’s the coarsest possible way to think about it, and it’s why a lot of scraping and account work breaks in ways that look random but aren’t. The two variables that actually decide whether a proxy passes as legitimate are where the IP is geolocated (down to city) and which network owns it, the ASN, or autonomous system number. These are separate systems maintained by separate organizations, and conflating them is one of the most common mistakes I see people make when picking proxies for scraping, ad verification, or account management.
I run proxy infrastructure out of Singapore and spend a lot of time on the diagnostic side, figuring out why a target site is blocking a proxy that “should” work. Nine times out of ten when someone says “the proxy is in the right country, why is it still getting flagged,” the answer is that the country, or even the city, was fine, but the ASN gave it away. This piece breaks down what city-level and ASN-level targeting actually are, how the underlying data gets built, and where operators get it wrong.
what it is
IP geolocation is the practice of mapping an IP address to a physical location, typically down to country, region, and city. Vendors like MaxMind maintain databases (GeoIP2 is the standard one most anti-fraud and ad-tech stacks license) that assign a lat/long and city name to IP ranges. When a proxy provider advertises “city-level targeting,” they mean they can hand you an IP that resolves, in these databases, to a specific city, say Osaka instead of just Japan.
ASN targeting is a different axis entirely. Every block of IP addresses on the internet is registered to an autonomous system, a network operated by an ISP, mobile carrier, hosting company, or enterprise. The ASN tells you who owns and routes that IP space, not where a device sits. IANA delegates number resources to five regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), who allocate ASN and IP blocks to network operators, per IANA’s number resources registry. Singtel, Comcast, OVH, DigitalOcean, and Vodafone each operate under their own ASN, and that ASN is publicly queryable in BGP routing tables and WHOIS.
So city-level targeting answers “where does this IP appear to be.” ASN-level targeting answers “what kind of network is this IP sitting on.” A proxy can nail the city and still fail because the ASN belongs to a known datacenter operator instead of a residential ISP.
how it works
Geolocation databases are built primarily from RIR allocation records (which registry, and often which country or region, a block was assigned to), WHOIS registration data, and increasingly from active measurement, triangulating latency to known reference points, plus user-submitted corrections. This is why geolocation accuracy degrades below the city level. A database can usually get country right, is decent at city for fixed-line residential and business IP space, and gets noticeably worse for mobile carrier ranges, because carriers route large blocks of subscriber traffic through a small number of gateway points regardless of where the phone physically is. MaxMind documents this limitation directly in its own accuracy disclosures for mobile and satellite ranges.
ASN assignment works differently and is more precise because it’s a routing fact, not an inference. When an operator wants to run its own network, it applies to a regional registry for an ASN and a block of IP space. That assignment is recorded and published, and the internet’s routing protocol, BGP, relies on it to move traffic. Cloudflare’s explainer on autonomous systems covers the mechanics if you want the network-engineering version. The practical upshot for proxy work: any target site can look up which ASN an incoming IP belongs to and immediately know whether that IP sits inside a residential ISP’s subscriber pool, a mobile carrier’s network, or a datacenter provider like AWS or OVH. Anti-bot vendors maintain their own labeled ASN databases specifically to flag “hosting/datacenter” ranges as higher risk, independent of what city the geolocation database reports.
This is why the two systems produce different failure modes. A residential proxy in the right city can still get flagged if its ASN belongs to a provider known for reselling proxy IPs. A datacenter proxy with a “perfect” city match on paper will still read as a datacenter connection to any site doing ASN lookups, because MaxMind’s city assignment and the RIR’s ASN assignment come from entirely different data pipelines.
why it matters
Anti-bot systems weight ASN more than city. A site like an e-commerce platform or ticketing service cares less about whether you’re in the right neighborhood and more about whether the connection looks like a real subscriber. A residential or mobile ASN carries baseline trust that a hosting ASN doesn’t, even when the hosting IP’s registered city is a dead-on match for the target audience.
Localized pricing and content depend on city accuracy. Ride-share pricing, local search results, and regional promotions are generally driven by the geolocation database, not the ASN. If you’re doing local SEO or local search visibility checks, city-level precision is what you’re actually paying for, similar to what I’ve covered in best proxies for scraping local search results.
Multi-account and ad-verification work needs both to line up consistently. If two accounts share an ASN but claim different cities, or share a city but sit on wildly different ASN types, one residential, one datacenter, that inconsistency itself becomes a fingerprinting signal. The folks at multiaccountops.com write a lot about this from the account-management side, worth a read if that’s your use case.
Geo-fencing and licensing enforcement usually happens at the city or region level, not ASN, because that maps to legal jurisdiction. I’m not a lawyer and this isn’t legal advice, but if you’re touching age-gated content, regional licensing, or anything with a compliance requirement attached, know that the geolocation database is what’s typically being checked, and getting that right doesn’t mean you’ve satisfied any actual legal obligation.
common misconceptions
“A proxy in the right country is good enough.” Country is the coarsest signal available and the one that matters least to a well-built anti-bot system. Sites that actually care about fraud or bot traffic are looking at ASN type and city consistency, not just country match.
“Residential proxy means accurate city.” Not always. Residential proxy networks route through real ISP subscriber IPs, but the geolocation database’s city assignment for that IP block might reflect the ISP’s regional gateway or billing address rather than the device’s literal location, especially for mobile and satellite ranges where MaxMind’s own accuracy documentation flags wider error margins.
“ASN and geolocation come from the same data, so if one’s right the other is too.” They’re built by different organizations for different purposes. Regional registries like ARIN and RIPE NCC assign and publish ASN and IP block ownership as routing facts. Geolocation vendors like MaxMind separately infer physical location from a mix of registration data and measurement. You can have a perfectly consistent ASN and a wildly wrong city, or the reverse.
“Picking a city in my VPN app defeats ASN-based detection.” It doesn’t. Most consumer VPNs run out of datacenter ASN space no matter what city label the app shows you. The city selector changes the geolocation output. It does nothing to the ASN, which is still registered to the VPN provider’s hosting infrastructure.
where to go from here
If ASN and city consistency is a new concept, the next practical step is learning to read the symptoms of a mismatch when a target site starts blocking you. I’ve written about how to tell whether a block is coming from the proxy’s network reputation or from your browser fingerprint in diagnosing IP bans: when it’s the proxy vs when it’s your fingerprint, which is the natural follow-up to this piece. From there, debugging 429 errors: rate limits, proxy quality, and behavioral patterns covers what happens after you’ve got the geolocation and ASN right but are still getting rate-limited on volume. If you’re running proxies against sites with active bot defenses, cookie and session handling at scale across rotating proxies is worth reading next, since session consistency and network consistency are two halves of the same trust signal. And for the full picture of what’s live on the site, the blog index has the rest of the scraping and proxy operations series.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-07-24.