In this guide we explain how city targeting actually works, how to test it, and what to do when a metro is under-supplied. For fundamentals, see proxy IP geolocation and targeting basics.
What “city-level targeting” really means
City-level targeting means your exit IP resolves to a named city in common geo databases and behaves as if it is in that metro on the sites you care about. In practice it is an approximation that can drift by 10 to 80 km.
City targeting is not a legal guarantee of being inside a city boundary. It is the outcome of routing, registration, and how the destination classifies location.
When city targeting is useful
Use city targeting when a country label is too broad and the task is bound to a metro. Typical cases include local SERP or Maps checks, city-gated marketplaces, and testing city-specific pricing or availability.
Further examples:
- Preview Google Maps and local packs as seen by users in the target city.
- See delivery zones, fees, or time slots that load only for certain metros.
- Post to classifieds that enforce city geofences.
Accuracy by network type
City accuracy depends on how IP space is sourced and routed, plus the freshness of geo databases. For a refresher on networks, see overview of proxy network types.
Datacenter proxies
Datacenter city targeting is “best effort.” Hosting ASNs centralize traffic through a few PoPs and subnets get reassigned, so labels often skew toward the DC hub.
What to know:
- Centralized PoPs can collapse several metros into one hub city.
- Geo databases may lag after subnet moves, so labels drift.
- Good for coarse metro testing, weaker for strict city geofences.
ISP or static residential
ISP-labeled ranges usually align better with cities than hosting space because the owner of record is an internet service provider. Supply is uneven and smaller cities can be scarce.
What to know:
- Better city fidelity than DC in major metros.
- Inventory often favors big cities and commuter belts.
- Not 100 percent consistent across destinations.
Residential rotating
Residential pools can match well if the provider has density in the target metro and keeps geo data fresh. Results vary by city size and pool depth.
What to know:
- Best odds in large, well-covered metros.
- Smaller cities may have sporadic supply.
Mobile
Mobile IPs often look consistent at metro level but can pin to a carrier aggregation point due to CGNAT and carrier mapping. You may see the nearest big-city PoP rather than the tower’s city.
What to know:
- Useful for broad metro presence.
- Carrier PoP mapping can override fine city detail.
How to verify a city before you commit
Test with both geo APIs and the target site or app, then judge by your real use case rather than a single database label. Expect some disagreement among databases.
A quick checklist:
- Ask the provider for a current city inventory list and minimum pool size for your metro. Inventory usually skews to major cities.
- Run 2–3 IP geolocation APIs and record city, region/state, ASN, and any “last updated” fields.
- Validate inside the destination: look for city-specific UI like delivery coverage, local ads, or price differences.
- Repeat over several hours to catch re-labeling after rotations.
Sticky sessions and multi-step flows
Use sticky sessions to keep the same IP identity for multi-step flows like login, browse, add to cart, and checkout. Without stickiness, a rotation can quietly hop you into another city.
Practical tips:
- Set session duration to match your flow length, not longer than needed.
- If city supply is thin, extend stickiness to avoid unplanned hops.
Fallbacks when the exact city is scarce
If you cannot source enough IPs in your target city, try adjacent options that still meet the business rule.
Options to try:
- Neighboring-city targeting if the app treats the metro as a single market.
- ASN or ISP targeting for the dominant local provider when strict city is not enforced.
- Time your runs for periods when residential pools are denser.
Typical drift and how to budget for it
Plan for 10 to 80 km drift between a reported city and a metro boundary. The tighter the geofence, the more sampling you need. Budget extra IPs and retries when a site is strict on city.
A simple rule:
- Strict city match required: over-provision by 2x to 3x and pre-filter candidates.
- Metro-level acceptance: 1.2x to 1.5x usually covers drift and rejections.
Requesting and reading a city inventory
When you request inventory, ask for: city, region/state, ISO country, estimated available IPs or threads, network type, and the update cadence of geo labels. Match this to your needed concurrency and session lengths.
What to confirm with the provider:
- Minimum pool size per city to maintain your concurrency.
- Replacement and refresh policies if labels shift after you start.
- Whether city targeting is routed by registration data, latency probing, or internal mapping.
Table: City-targeting reliability by network
| Network type | City match likelihood | Typical issues | Best for |
| Datacenter | Low to medium | Centralized PoPs, moving subnets | Broad metro presence, non-strict checks |
| ISP / Static Res | Medium to high | Uneven supply outside big cities | City-focused tasks in major metros |
| Residential rotating | Medium to high | Pool density varies by city | City checks with known dense pools |
| Mobile | Medium | CGNAT mapping to carrier PoPs | Metro presence, not precise neighborhoods |
Interpretation note: always validate inside the actual app, not only in an IP database.
Testing workflow you can reuse
A standard flow reduces guesswork and helps you compare providers fairly.
- Define success: which site signals prove you are “in city.”
- Pre-filter: sample 50–200 IPs; keep ones where 2 of 3 geo APIs agree on the city.
- App validation: run your full flow on a random subset of the pre-filtered IPs using sticky sessions.
- Monitor drift: recheck labels after several hours and after rotation events.
- Scale: buy only when the pass rate holds at your target concurrency.
Procurement tips that save time
Align expectations with your provider before the trial.
- Share the cities, required concurrency, and session times.
- Ask which cities have reliable supply now, not just “supported” on paper.
- Confirm geo-data update cadence and the policy for swapping IPs if labels are off.
- For rotating plans, confirm how often you can refresh your list or gateway to re-sample the pool.
FAQs
Is city targeting ever 100 percent accurate?
No. It depends on routing, registration, pool density, and how sites classify location. Sticky sessions and pre-filtering raise success rates but do not guarantee perfection.
Why does a “City A” IP sometimes show up as “City B”?
Geo databases lag behind subnet changes, hosting PoPs centralize, and mobile carriers may map to core PoPs. Validate inside the target app.
Which network type gives the best city match?
In large metros, ISP or residential often beats datacenter. Mobile is good at metro level but may pin to the carrier PoP. Supply varies by city.
How do I keep my city identity for multi-step flows?
Use sticky sessions with durations aligned to your flow. Avoid needless rotations that can move you mid-journey.
What if my exact city has no inventory today?
Try a neighboring city in the same metro or ASN targeting, and sample more during high-density hours for residential pools.