Proxy Geotargeting: Country, City and ASN Level Targeting

Geotargeting is the part of a residential proxy service that gets sold as a checkbox and delivered as a probability. The marketing page lists 195 countries and city-level precision. The gateway accepts your city-austin parameter without complaint. What comes back might be an exit in Dallas, or an exit that one geolocation database places in Austin while the site you are scraping places it two states away.

Targeting does work. It works statistically, and the tighter you specify, the more of your pool you throw away to get there. This guide covers how the parameters travel to the gateway, what each level of the ladder is worth, and how to measure what you received instead of trusting what you asked for.

How targeting reaches the gateway

Almost every residential network exposes one gateway hostname and one port for the whole pool. Everything you want to say about the exit gets encoded into the proxy username, because an HTTP CONNECT handshake gives you nowhere else to put it. The password stays constant. The username becomes a small query language, and every vendor invented its own dialect.

# Same intent in three provider dialects: a Chicago exit held for one session
curl -x 'http://user-country-us-city-chicago-session-8f21:[email protected]:7000' https://example.com
curl -x 'http://customer-acct-cc-US-city-chicago-sessid-8f21:[email protected]:7777' https://example.com
curl -x 'http://acct:[email protected]:823' https://example.com

Two other mechanisms show up alongside the username. Work out which one you have before writing the integration.

• Username parameters. The default everywhere. Works with any client that supports proxy authentication, and completely unstandardised across vendors.
• Dedicated ports. A block of ports, each hard-wired to a country or a rotation mode. Handy for tools that cannot set a custom username, useless below country level.
• A targeting API. A REST endpoint listing reachable countries, cities or ASNs with live counts. Rare, and the only mechanism that tells you whether a filter can be satisfied before you spend bandwidth finding out.

The granularity ladder from country to ASN

Five levels are commonly offered, and dependability drops far faster down the ladder than the marketing implies.

Country is the only level that behaves like a genuine filter. Everything below it is a preference expressed against an estimate that somebody else made. Mobile carrier exits behave differently again, because carrier-grade NAT anchors thousands of subscribers to a gateway that may sit hundreds of kilometres from any of them, which is covered in mobile proxies explained.

Why narrow targeting shrinks the pool you can use

The arithmetic of a city filter

Residential exits follow the distribution of the host apps, which tracks population loosely and app-store demographics closely. If a metro holds two percent of a country's broadband subscribers, plan for roughly that share of the live exits and be pleased if it is higher.

Then subtract the exits carrying somebody else's traffic, offline for the night, or already pinned inside a sticky session. What remains is the set you cycle through. Fifty concurrent workers against a city pool of a few hundred reachable addresses means each one takes a request every few seconds, which is the exact signature a rate limiter exists to catch. How pools get counted and marketed is covered in proxy pool size explained.

The latency and failure penalty

A small match set turns exit selection from a lookup into a search, and three symptoms follow in increasing order of damage. Connection setup time climbs. Timeouts rise, because the gateway keeps trying rather than admit it has nothing. Worst of all, some gateways quietly fall back to a neighbouring city or the national pool and serve the request anyway, so your dataset is contaminated and nothing in the response says so.

Where an IP is registered versus where the device sits

Regional internet registries record which organisation holds a block of addresses, along with a postal address for that organisation. That address is a corporate headquarters. An ISP that receives a /16 registered to its head office in Frankfurt is free to hand those addresses to subscribers in a town four hundred kilometres away, and there is usually no public record of the split.

Several other mechanisms pull the apparent location away from the physical one. Carrier-grade NAT concentrates subscribers behind a handful of public addresses in a regional facility. Mobile traffic exits at a packet gateway rather than at the tower. Satellite and fixed wireless subscribers appear wherever the ground station is. A household running a commercial VPN on its router presents an exit with no relationship to the house at all. None of this is an error, and none of it is visible to you.

Why two geolocation databases disagree about one address

Geolocation vendors are not reading a register. They build an estimate from overlapping and partly contradictory signals, then sell the result. Weighting is proprietary and refresh cadence differs.

• Registry records and self-published geofeeds. A machine-readable mapping of a network's own prefixes to locations is the highest-quality input available. Most networks publish nothing.
• Routing and reverse DNS. Hostnames like ae12.chi01.example.net leak a city code, and BGP paths hint at where a prefix is announced from.
• Active latency measurement. Probing from many known locations bounds where an address can physically be. Works well for wired connections, poorly for anything behind a tunnel.
• User and ISP submissions. Corrections and commercial feeds, arriving irregularly and ageing badly when a block is reassigned.
• Handset and application telemetry. Location signals harvested from SDKs, which is the same supply chain that produces the proxy pool.

The consequence is specific. The only geolocation that counts is the one your target uses. If the site runs one vendor's database and you validated against a different vendor's API, you validated the wrong thing. Infer the target's own view from its behaviour where you can: which currency it quotes, which language it defaults to, whether it shows tax inclusive of VAT, what the store locator prefills.

Verifying the exit you actually got

Two independent lookups plus the target's own reaction is enough to work with. Run all three through one session so you are describing a single exit.

PROXY='http://user-country-de-city-berlin-session-2b91:[email protected]:7000'

# Two independent geolocation opinions about the same exit
curl -s -x "$PROXY" https://ipinfo.io/json | jq '{ip, city, region, country, org}'
curl -s -x "$PROXY" https://ipapi.co/json/ | jq '{ip, city, region, country_code, asn, org}'

# The opinion that actually decides what you are served
curl -s -x "$PROXY" -o /dev/null \
     -w 'status=%{http_code} redirect=%{redirect_url} time=%{time_total}\n' \
     https://www.example-shop.com/

Do this at volume rather than once. Log the exit IP, both databases' answers and the target's response for every request, then compute the share that matched your filter. A city filter landing sixty percent of the time is workable if you can discard the misses cheaply, expensive if each miss costs a full page download. Trimming that waste is covered in reduce proxy bandwidth costs.

When the site serves a region your exit did not ask for

Your exit IP is one input into the target's regionalisation logic, and frequently a weak one. An Accept-Language header left at your machine's default, a region cookie from an earlier redirect, an account preference or a CDN edge decision can all override it. Anycast sends your connection to whichever point of presence is closest to the exit, so a site that shards content by edge rather than by client IP will hand a Lisbon exit the Spanish catalogue because the Madrid POP terminated the connection.

The subtle one is DNS. If your client resolves the hostname locally and then asks the proxy to connect to the resulting address, GeoDNS has already answered based on your resolver's location rather than your exit's. In curl, socks5:// resolves on your machine and socks5h:// resolves at the proxy. HTTP proxies handed an absolute URI resolve remotely by default, which is one of the few places where the older protocol has the safer behaviour. The trade-offs between the two are in http vs socks5 proxies.

ASN targeting and when it earns its cost

ASN is the one filter resting on a fact. asn-7922 means the exit's prefix is announced into the global routing table by Comcast, confirmable from public route data without trusting anyone's estimate. That makes it the most reliable filter available and, because it slices the pool by provider rather than by geography, often the most restrictive.

• Ad delivery verification. Campaigns are routinely targeted or excluded by carrier, so checking what one ISP's subscribers see requires an exit inside that ISP.
• Reproducing an ISP-specific fault. Peering disputes, resolver hijacking, transparent caches and CGNAT behaviour differ per network. When a bug report only comes from one ISP's customers, an exit on that ASN is the only way to see it.
• Carrier-bound content. ISP portals, bundled streaming entitlements and zero-rated services check the originating network rather than the country.
• Negative filtering. Excluding autonomous systems that look residential but belong to hosting resellers, a common cause of otherwise inexplicable reputation problems. See proxy fraud score explained.

Combining ASN with a city almost always leaves you nothing. Pick the constraint your use case genuinely needs and let the other float.

What to establish before you pay for geo coverage

Coverage lists are cheap to publish and rarely audited. Four questions separate real capability from a page of flags.

1. Ask for distinct exits observed in the last twenty-four hours in your top three countries, and refuse a global cumulative total as an answer.
2. Measure across the clock. Residential pools breathe with the local day, so a European city at 04:00 is a fraction of its 21:00 size. We test continuously from US and EU infrastructure for this reason, as our methodology describes.
3. Confirm in writing what happens when a filter cannot be satisfied: an explicit error, or a silent fallback you have to detect yourself.
4. Check whether geo-targeted or ASN-targeted traffic is billed at the same rate. Some plans price the narrow filters separately.

The rest is measurement. Our live benchmark table shows how the providers we track behave from US and EU vantage points, the side-by-side comparison tool puts two of them next to each other, and the wider evaluation procedure is in how to choose a proxy provider. If you are still deciding whether a residential pool suits the job, start with what are residential proxies.