Geo targeting in proxies means choosing the country, city, ASN, or ISP that your traffic appears to come from. This guide shows how providers implement geo at the gateway and IP pool level, what accuracy to expect, and how to test and control drift. For the bigger picture of network families and where geo fits, see our core guide to proxy services.
Geolocation basics for proxies
The short version: proxy “geo” is a routing promise about the egress IP address, not your device. Providers deliver it by assigning you to gateways, ports, or segmented IP pools tied to a region or network.
In more detail, a provider maps gateway hostnames or specific ports to groups of IPs that belong to a target country or city. When you connect, the system selects an address from the mapped pool. Accuracy depends on how that pool was sourced, how often the mapping is refreshed, and which IP intelligence database the destination relies on.
How providers enforce geo
Vendors bind geo to endpoints by using region‑scoped gateways and ports, and by segmenting their IP pools per country or city.
Common enforcement patterns:
- Region hostnames. Example: fr.pool.example.net or city-ams.pool.example.net points you at France or Amsterdam IP ranges.
- Per‑region ports. One domain, different ports map to different regions, for example :10001 for US, :10002 for DE.
- Pool segmentation. IP pools are tagged with country, city, ASN or carrier metadata, and the gateway selects from the right slice.
- Sticky vs rotating. Sticky preserves the same IP across requests for a period, rotating picks a new IP per request or per interval. This changes how consistent the geo looks across a session.
Tip: if a vendor documents both “gateway” and “pool,” the gateway is the access point you connect to and the pool is the inventory it can allocate from.
Why geolocation labels disagree
Geo labels come from third‑party IP databases that do not agree, and sites choose different ones.
Two providers can serve the same IP and get different country or city verdicts from different databases. Edge cases include recently moved IP blocks, new allocations, or corporate VPN ranges that still look like the old owner. Expect some disagreement at the city level and occasional flips at the country border when blocks are re‑announced.
Country‑level targeting
Country targeting guarantees your egress IP resolves to the requested country in common IP databases, with high but not perfect consistency.
Country is the most stable and widely supported control in every proxy stack. Vendors achieve it by mapping gateways or ports to country‑tagged pools. Success rate depends on pool size, freshness of tags, and how the destination validates geo.
Popular vs long‑tail countries. Popular countries have larger pools that refresh often. Long‑tail options can be present but shallow: a small pool means more reuse, faster depletion, and a higher chance that a target has seen those IPs already.
Operational notes. If you automate at scale, prefer country gateways over manual IP whitelists. Document the fallback policy for when the pool is temporarily exhausted, for example auto‑retry within the same country or fail fast.
For hands‑on configuration and edge cases, continue with Country‑Level Targeting.
City‑level targeting
City targeting narrows the pool to IPs labeled for a specific city, which improves locality at the cost of smaller inventory and more frequent mismatches.
City precision is where database errors show most. IPs near metro borders, multi‑city ISP ranges, or recently reassigned blocks can drift between cities in different datasets. Some vendors emulate city targeting by selecting IPs from nearby locations when exact matches are scarce. This usually looks fine for radius‑based checks but can fail on exact string matches.
When to use. Pick city scope when you truly need metro‑level context, for example local listings, delivery zones, or language defaults that differ by city. Otherwise stay at country level for better throughput and stability.
If you require strict metro scope and routing patterns, see City‑Level Targeting.
ASN or ISP targeting
ASN or ISP targeting attempts to match the egress IP so that its owner of record equals a given autonomous system or provider name.
Providers do this by tagging IPs with ASN or carrier metadata and selecting from those slices. It matters when a destination treats consumer ISPs differently from hosting ASNs. For example, some sites apply softer friction controls to IPs that belong to retail ISPs than to datacenter ranges.
Limits and gotchas. AS ownership changes, mergers, and sub‑allocations make names and numbers churn. A block announced by an ISP but routed from a hosting facility can pass an ISP check while still behaving like a server‑hosted IP in other heuristics. Always validate against the same source your target uses if possible.
For matching strategies and verification tips, continue with ASN or ISP Targeting.
Random or mixed geo
Random or mixed geo selects IPs from multiple regions on purpose, useful for broad sampling, A/B distribution, or avoiding patterns tied to a single country.
This setting usually means the gateway draws from a world‑mix pool or from a list of countries you specify. Expect less predictability at the session level. If stickiness is required, pin a country or use a per‑session rule like “lock after first IP.”
For pool composition examples and scheduling tips, see Random / Mixed Geo.
Accuracy, testing, and drift control
Test geo with the same data sources your targets rely on, set accept boundaries per scope, and monitor drift with small canary checks.
Practical checklist:
- Pick your verifier. Decide which data source is authoritative for your workflow. Mixing sources wastes time.
- Define pass criteria. Country must match exactly. City can allow a nearby metro within a clear radius when exact strings are unreliable.
- Check on login not ping. Validate through the actual protocol or site flow rather than ICMP echo.
- Watch recency. Ask how often the vendor refreshes pool tags and rotates stale subnets out.
- Track drift. Run periodic canary calls that record the seen geo and flag changes.
A simple CSV with timestamp, IP, country, city, ASN and the gateway you used is enough to catch regressions.
Pool size, scarcity, and success rates
Larger country pools improve uniqueness and retry odds, while niche cities or ASNs trade volume for specificity.
When vendors talk about “pool size,” they mean the count of distinct IPs that a gateway can allocate over time. Country pools in popular regions renew quickly. City slices and specific ASNs can be thin, so concurrency and stickiness burn through them fast. If your workflow needs both city scope and sticky sessions, plan for lower parallelism or accept more frequent IP reuse.
Mobile carriers and CGNAT specifics
Mobile carrier targeting relies on tags for carrier ASNs and APN profiles, but heavy CGNAT makes single‑IP identity noisy and fast‑changing.
Mobile networks aggregate users behind shared addresses. Even if the ASN matches the carrier, the same IP may represent many devices at once and change hands rapidly. Session‑level heuristics like user agent, TLS fingerprint, and request timing often dominate how sites score traffic, so mobile ASN alone does not guarantee a “mobile user” profile.
Sourcing and ethics
Good providers state how they sourced IP inventory and consent, and they remove questionable ranges when abuse shows up.
Residential or mobile pools often come from SDKs or opt‑in programs. Ethical sourcing means clear user consent, the option to opt out, and active curation of blocks reported for abuse. Datacenter inventory is simpler but still needs stewardship when ASNs change hands.
So what? Availability is constrained by consent and law. This is why certain countries, cities, carriers, or ASNs may be missing from a pool or get retired over time — the provider cannot include them without proper rights. Lack of a specific geo is an expected outcome of ethical sourcing, not a platform bug.
Implementation patterns and examples
Put geo selection in configuration, not code, and isolate country or city choice per job, session, or request.
Common patterns:
- Job‑level geo. Each job runs under a country gateway, for example a daily task for US, another for DE.
- Session‑level stickiness. New session picks a country, locks it for N minutes, then releases.
- Request‑level rotation. Each request draws from a selected geo. Use this for broad sampling.
- Failover. If city slice is exhausted, retry within the same country rather than silently crossing borders.
FAQs
How accurate is city targeting compared to country?
Country is usually stable across datasets. City depends on the database and recent IP moves, so expect more variance and set tolerant checks.
Why does a site think I am in a different city than a checker shows?
The site likely uses a different IP database or a cached view. Validate with that source if possible.
Can I combine ASN filtering with city targeting?
Yes, but inventory shrinks fast. Expect more reuse and consider lowering concurrency or session length.
What causes sudden geo flips for the same IP?
Ownership changes, route updates, or database refreshes. Track drift and replace affected subnets when it matters.
Does mobile ASN targeting guarantee a mobile fingerprint?
No. CGNAT and fingerprinting signals dominate. Mobile ASN helps but does not define the identity alone.