City and ASN targeting is table stakes. It is usually the wrong knob.

Checked on 27 July 2026, the ISP proxy page at Decodo carries a banner reading "City, state & ASN targeting is now live: Precision geo and network-level targeting for datacenter & ISP proxies." Proxyway's news index dates that launch; Decodo's own page carries no date on the announcement, so treat the timing as Proxyway's reporting rather than something the vendor has published. What the vendor page does state plainly, on the same screen, is the shape of the offer: "Country-level targeting is included in all plans." Finer than country is the new thing being sold.

The same page puts Decodo's ISP footprint at 17 countries. Seventeen countries of coverage, and the upsell is precision below the country line.

Everyone ships it now

Fine targeting has stopped being a differentiator across the proxy networks category. On 27 July 2026, Oxylabs advertises "Filter by country, city, state, continent, ZIP, coordinates, and ASN" against a claimed pool of 175M+ IPs in 195+ countries. Bright Data advertises targeting at "city, state, country, ZIP code, and ASN level" against a claimed 400M+ residential IPs across 195 countries. SOAX offers "Target by region, city, or ASN" on a claimed 155+ million addresses. IPRoyal lists country, state and city targeting on a claimed 64M+ IPs. NodeMaven goes furthest in the marketing copy, promising "ZIP-level targeting in 150+ locations" and 1,400+ locations worldwide. ProxyRack advertises "Access IPs from 140+ different countries (plus target city and ISP)."

All of those are vendor claims read off vendor pages. None is an audited measurement, ours or anyone else's, and pool-size figures in this market have never been independently verified in a way I would build a budget on.

The interesting outlier is MarsProxies, whose comparison chart on the same date says "Country only" for the standard datacenter, ISP, mobile and residential tiers, with "Geo-targeting down to city level" reserved for the API product. That is an honest presentation of a tradeoff most vendors bury.

The arithmetic nobody puts on the pricing page

Every targeting filter is a WHERE clause against the pool. They compose multiplicatively. Country narrows it, city narrows what is left, ASN narrows that again, and a ZIP filter narrows it to whatever remains. The pool you actually draw from at request time is the intersection, not the headline number on the homepage.

Do the division on a vendor's own published figures and the result is sobering. MarsProxies publishes 1M+ residential IPs across 195+ countries. Spread evenly, that is roughly five thousand addresses per country, and residential pools are never spread evenly. NodeMaven publishes a US residential figure of 299,783 IPs. The United States has on the order of forty thousand postal codes. Even distribution would put roughly seven addresses behind each ZIP filter, and even distribution is not what a consumer ISP footprint looks like. Real pools cluster in dense metros and thin out to nothing in rural prefixes.

This is arithmetic on numbers the vendors publish, not a measurement of any pool. But the direction is not in doubt, and it explains a failure mode that looks mysterious from the application side. A crawl targeting US succeeds. The same crawl with US + city + ASN starts collecting blocks, and the engineer's instinct is that the proxy quality got worse. It did not. The addressable set got small enough that individual IPs began repeating across requests, and a rotating proxy that cannot actually rotate is just a static IP with extra latency. Reuse rate is what an anti-bot system is built to notice. Precision bought at the wrong layer degrades success directly.

There is a procurement version of the same trap. Vendors quote per-GB rates against the full pool. On 27 July 2026 Bright Data lists residential pay-as-you-go at $4.00/GB with a promotional discount running, and IPRoyal lists subscription rates from $7.00/GB at 1GB down to $4.90/GB in bulk. You pay those rates per gigabyte transferred whether the filter left you a hundred thousand addresses or eleven. Retries against an exhausted sub-pool bill at the same rate as successful requests. Geonode at least states its billing basis in plain terms, advertising "We charge per request, per page, per query, or per GB. Never per credit. Never with hidden multipliers," which makes the retry cost legible. Most of the market does not. The mechanics of these models are worth reading closely before signing anything, and we cover them in the proxy pricing models guide and in the post on what replaced per-GB billing.

Where fine targeting genuinely earns it

The cases where the cost is worth paying share one property: the data itself differs below the country level, so a coarse filter returns a wrong answer rather than a slow one.

Localized pricing and assortment is the clearest of them. Retailers and marketplaces vary catalog, stock and price by delivery region, and if the store shows different SKUs in Dallas than in Newark, a country filter samples an arbitrary one and the dataset is silently wrong.

Ad verification is the same argument with money attached. Campaigns are bought against geographic segments, so confirming a creative served in the DMA it was purchased for needs resolution at the DMA level. There is no coarser substitute.

Geo-gated inventory is where ASN targeting stops being decoration. Streaming catalogs, ticketing, betting lines and regional promotions gate on the network a request appears to come from, and the gate reads the network rather than the location.

Sub-national search variation is the last one, and it is the case most often overstated. Results do shift by locale for local-intent queries, but the localized SERP collection guide covers the parameter handling, which matters more than the proxy filter does.

Everywhere else, the default should be inverted: use the coarsest filter that returns correct data, keep the pool large, and spend the savings on volume and retries. That choice belongs in the same conversation as picking a proxy type by target, because pool size and IP type trade against each other constantly.

What geo targeting does not fix

A residential proxy in the right city with the wrong TLS signature fails as fast as one from the wrong continent. The network layer is one of several signals, and it is not the one that usually gives you away.

Anti-bot systems fingerprint the client. TLS handshake ordering, HTTP/2 frame settings, header order and casing, the JavaScript execution environment, canvas and WebGL behavior, and timing patterns across a session all contribute. A geo filter changes none of them. Neither does it fix session handling, which is where a lot of collection actually breaks: rotating the exit IP mid-session while carrying the same cookie jar is a contradiction the target can read directly. That binding problem is the subject of the post on antidetect browsers and session binding, and the broader signal inventory is in the guide on why scrapers get blocked.

The practical sequence matters. If a crawl is failing, tightening the geo filter is close to the last thing to try, because the most common effect is a smaller pool and a higher block rate. Check the fingerprint, then the session model, then request pacing, and only then the location. Vendor differences at the top of the market are covered in more depth in the Bright Data and Oxylabs comparison.

What this means for a team collecting web data

Write down which of your targets actually vary below country level, target by target. For most crawls the honest answer is none of them, and that list is your entire justified budget for fine targeting.

Instrument the pool you are really drawing from. Log distinct exit IPs per thousand requests, broken out by the filter combination in use. When that number falls, you have found your block-rate explanation, and you can tell it apart from a vendor quality problem.

Treat ASN and ZIP filters as features you switch on for a named job and switch off afterwards, not as a default in your client configuration. The cost of leaving them on is invisible until success rates drop.

Ask a vendor for the addressable count under your specific filter combination before you sign, not the headline pool. If they will not answer, that is information. Keeping a second supplier configured is cheap insurance against exactly this, and the mechanics are in the multi-vendor failover guide.

Targeting granularity is the easiest thing for a proxy vendor to ship and the easiest thing for a buyer to compare on a feature grid. That is why the whole market has converged on it. It is a poor proxy for whether the pool underneath will hold up.