City-Targeted Proxies: When You Need Them and What They Cost

Buy city targeting when all three of these are true:

• The page content differs between two cities in the same country when you load it from local connections.
• The difference comes from the IP address, not from a location the user types in, a store picker, or a cookie.
• The data you need lives in that difference (the local pack, the local ad, the delivery slot, the store stock).

If any one of them is false, country or state targeting will do, and you can often use datacenter IPs instead of residential ones. That switch is usually the biggest cost lever in the whole project, far bigger than which vendor you pick.

City targeting means the provider picks your exit IP from the subset of its pool that a geolocation database places in the city you asked for. You normally express it in the proxy username or as a request parameter, and the provider filters its pool accordingly.

Two details matter more than the marketing suggests.

The city is the database's opinion. Your provider labels an IP as "Chicago" using the geolocation data it licenses. The site you are scraping may use a different database, or its CDN's own data, and place the same IP in a suburb or in a different city entirely. MaxMind, one of the largest geolocation vendors, publishes an accuracy comparison that reports city accuracy as the share of IPs located within a radius of their true position, broken down by country. The fact that the metric is a radius at all tells you city-level location is an estimate, not a registry fact the way country usually is.

City labels on datacenter IPs describe where the rack is. A datacenter IP geolocates to the metro where the hosting company operates the facility: Ashburn, Dallas, Frankfurt, Amsterdam, Singapore. You can sometimes pick those hub cities, but you cannot get a datacenter IP that looks like a home connection in Tucson, because no data center hosts a proxy fleet there. For most smaller cities, city targeting is a residential or mobile product by construction.

This is the check that saves the most money, and almost nobody runs it before buying.

Many sites that look city-aware do not use your IP for the city part. They use:

• A ZIP or postcode field. Grocery, pharmacy and home improvement sites commonly ask for a delivery postcode or store, then store the choice in a cookie.
• A store selector cookie. Once set, the cookie decides stock and pricing, whatever IP sends it.
• An account address. Logged-in pricing follows the saved address.
• A search parameter. Search engines and SERP APIs accept an explicit location, so local results do not have to depend on the exit IP.
• Browser geolocation. The JavaScript geolocation API reads the device, not the IP. A proxy cannot change it, although a headless browser can be configured to report coordinates.

In all of those cases the fix is to set the location inside the request, then send it through country-level IPs. You get the city-specific page without paying for city-specific IPs.

A quick way to tell: load the page from two IPs in the same country but different cities, with cookies cleared, and compare. Then set the store or postcode and load it again from both IPs. If the second pair matches, the site localizes by input, not by IP. Our guide on proxies for grocery and delivery prices goes deeper on the store-cookie pattern, which is the most common case.

Country-level IPs cover the large majority of geo-sensitive scraping. Typical examples:

• Ecommerce prices and currency. National retailers usually price per country, sometimes per state for tax or shipping, rarely per city.
• Content and catalog availability. Streaming catalogs, app stores and licensing restrictions are almost always set per country.
• Localization QA. Language, currency formatting, cookie banners and legal notices change at country or region level. See proxies for localization testing.
• Travel fares. Fares often vary by point of sale country and currency. City of origin is part of the search itself, not the IP.
• National search rankings. If you track rankings for a country rather than a neighborhood, country IPs plus a location parameter are enough.

State targeting sits in between. In the US it is useful when shipping, tax display or licensed services (insurance quotes, sports betting availability) change at state lines. Before paying for city, ask whether state already captures the variation.

These are the cases where the IP city really does change the data and there is no request parameter that replaces it.

Ad verification is the clearest case, because the advertiser literally bought a location. If you verify a campaign targeted at Houston from a Dallas IP, you will see nothing and conclude, wrongly, that the ad is not running. See how brands use proxies for ad verification for the full workflow.

Local SEO is less clear-cut. If your tooling can pass a location parameter to the search engine, you may not need city IPs at all. If it cannot, or you want to confirm what a real local searcher sees, city-targeted residential IPs are the honest answer. Our guide to proxies for SERP scraping at scale covers the volume side.

One caveat on mobile: carrier-grade NAT means many users share one public IP, and geolocation databases often place carrier IPs at a regional gateway rather than the user's town. Mobile is excellent for trust, less so for pinpoint city accuracy. Test it rather than assuming.

Where SparkProxy fits. SparkProxy is datacenter-first: 1M+ datacenter IPs across 80+ countries, including 50,000+ US IPs, sold as USA and worldwide rotating plans with country targeting on every plan. It does not sell residential or mobile plans and does not offer city-level targeting. For country-level work it is a flat-rate option (Starter is $75/mo for 100 threads with unlimited bandwidth), and for the city-level share of a project you would pair it with a residential provider, as described below.

Here is the part most "geo proxy" pages skip: on the big residential networks, city targeting itself is usually not a surcharge any more. The cost is that city targeting pushes you onto per-GB residential pricing, and then pool depth pushes your retry rate up.

As of September 2026, these vendors' own residential pages say the following. Prices change often and promotions come and go, so check each vendor's current page before buying.

So the real pricing question is volume in gigabytes, not a targeting fee.

An illustrative cost model

The numbers below are an illustrative assumption, not a measurement: 1,000,000 page requests a month, about 150 KB per response, which is roughly 150 GB of traffic.

Two things fall out of this. First, the jump from country-level datacenter to city-level residential is roughly an order of magnitude at this volume, and none of it is a line item called "city targeting". Second, the per-GB bill is exposed to page weight. If your city-sensitive pages are JavaScript-heavy and you load them in a browser, the GB figure can multiply. Our breakdown of residential proxy pricing per GB covers how to estimate that before you commit.

Headline pool sizes are national or global. Decodo lists 115M+ IPs, Oxylabs 175M+, IPRoyal 64M+ (all from their own pages, September 2026). Oxylabs also publishes per-country counts for its top locations, such as 10.3M for the USA. None of those figures tells you how many IPs are online in Boise at 3 a.m. when your job runs.

City pools are a small slice of the country pool, and residential IPs are online only while the underlying device is. That creates three problems that grow as the city gets smaller:

1. IP reuse. With fewer addresses available, the same exits come back more often, and per-IP rate limits on the target trip sooner.
2. Slower or failed allocation. Some requests wait for an available exit, or the provider falls back to a broader area. Check what your provider does when a city is empty: fail, wait, or silently widen.
3. Sticky sessions break early. A sticky session needs the same residential device to stay online. In a thin city pool, sessions end sooner, which hurts multi-step flows like adding an address and then loading delivery slots.

The practical rule: concurrency in a city should be sized to the city's available pool, not to your thread count. If a mid-size city gives you a few hundred usable exits at a time and the target tolerates a handful of requests per IP per minute, that is your ceiling, and adding threads just adds blocks. The same logic applies to regional pools in general, covered in regional vs global proxy pools.

Ask vendors directly for the live available IP count in your target cities, at the hours you will run. If they cannot or will not give a number, your trial is the only source of truth.

Most projects that "need city targeting" need it for a minority of requests. Split them.

Route by requirement, not by project.

• Catalog, product detail, national price and availability pages go through country-level datacenter IPs on a flat plan.
• Only the pages whose content truly depends on the IP city go through city-targeted residential.
• Pages that localize by postcode or store cookie go through country IPs with the location set in the request.

Illustrative example. Keep the 1,000,000 monthly requests from the model above, and assume 10% are genuinely city-dependent. That is about 15 GB of residential traffic, around $60 to $110 a month at the published rates listed above, plus a flat country-level datacenter plan for the other 900,000 requests. Compared to routing everything through city-targeted residential, the blend is a fraction of the cost, and the datacenter share does not care how heavy the pages are.

For the country-level share on SparkProxy's plans, the gateway is gateway.sparkproxy.io on port 11000 for HTTP/HTTPS with per-request rotation, 11002 for sticky sessions and 13000 for SOCKS5. If you would rather not run the proxy layer yourself, the Scraping API takes a country code per request:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: YOUR_API_KEY" \
  --data-urlencode "url=https://www.sparkproxy.io/pricing" \
  --data-urlencode "country_code=US"

country_code is an ISO 3166-1 alpha-2 code and adds 5 credits per request. It sets the exit country, not the city.

A simple router makes the split explicit in code:

CITY_SENSITIVE = ("/local/", "/near-me", "/delivery-slots")

def pick_route(url: str) -> str:
    if any(part in url for part in CITY_SENSITIVE):
        return "residential_city"      # per-GB pool, city-targeted
    return "datacenter_country"        # flat plan, country-level

for url in urls:
    route = pick_route(url)
    # send through the matching proxy pool or API

The URL patterns are examples; swap in the paths from your own targets. The point is that the routing decision is written down and reviewable, so city-level spend cannot creep in by default.

Run this during a trial, on your real targets, at the hours your jobs will run.

1. Pick three cities: one major metro, one mid-size city, one small city you actually need.
2. Check geolocation agreement. For a sample of exits per city, look the IP up in two or three geolocation services and note how often they agree with the requested city. Our guide on validating IP geolocation accuracy and fraud scores has the method.
3. Check what the target thinks. Many sites echo the detected location somewhere on the page, in a header, or in a cookie. That is the only geolocation that matters.
4. Count unique exits. Send a few hundred requests per city and count distinct IPs. A small city returning the same few dozen addresses tells you your concurrency ceiling.
5. Measure success rate and bytes. Log status codes, retries and response size. Multiply GB by the per-GB price to get your real cost per successful city-level record.
6. Test a sticky session. Hold one session through your multi-step flow and time how long it survives in each city.

If the small city fails steps 2 to 4, no amount of vendor switching is likely to fix it, because residential pool depth follows population. Consider state-level targeting plus a location parameter, or accept lower frequency for that city.