Guide
Country, city, and ASN targeting on proxies: how to use TR, EU, and US exits
Wrong geography means wrong data. We explain country / city / ASN layers and tie them to WeProxy locations and product coverage.
Wrong geography on a proxy means wrong data: another country’s SERP, wrong currency, wrong ad creative, “sudden country change” risk on accounts. This article explains country, city, and ASN targeting in practical language and ties TR, EU, and US scenarios to WeProxy locations and product coverage. IP basics: https://www.cloudflare.com/learning/network-layer/what-is-an-ip-address/ . ASN intro: https://www.ripe.net/manage-ips-and-asns/as-numbers/ . WeProxy location map: locations . Type choice: residential / mobile / DC / ISP comparison
Why geographic targeting is critical
Target systems read traffic not only via User-Agent but via the exit IP’s geography and network. Local SERP, local e-commerce prices, local ad creatives, consistent account countries — all depend on geo. Doing “global work” with any IP breaks measurement.
The WeProxy network spans 180+ countries; still, coverage varies by product line. Residential often has broad geo while some static / ISP lines have narrower country lists. That is a product reality, not a flaw — read the card with the locations page.
Country targeting: what it gives and what it limits
Country targeting routes traffic through an exit in the country you pick. For TR SERP, DE price pages, US ad previews, that is the minimum bar. The limit: if you do not need in-country diversity (city, ASN), country is enough; if neighborhood / metro locality matters, go down to city.
On WeProxy country selection is via product and plan; highlights such as Turkey (Istanbul), Germany, UK, Netherlands, France, US appear on locations . When the country is clear, open the residential or DC card at weproxy.io and plan on pricing
City targeting: local SERP and ad views
City targeting is for jobs that produce different local results inside one country: local packs, store stock, city-based ads, regional content. Istanbul vs Ankara, New York vs Los Angeles do not always look the same under one “country proxy.”
On residential lines, city / ZIP targeting (when the product allows) covers this. Not every product shares the same city list — again coverage differs. Tie to use cases via SEO / scraping / ads / social use cases and use cases
ASN targeting: when network identity helps
ASN (Autonomous System Number) says which network an IP block belongs to. Some jobs need not only “correct country” but “a specific carrier / network family” — e.g. looking close to a given ISP or staying inside one ASN. ASN can support consistency in sticky sessions and controlled diversity in rotating.
Not everyone needs ASN. Most SEO and scrape work ends at country / city. Treat ASN as an advanced filter; on WeProxy support is product-card dependent. RIPE’s AS Numbers page is a solid external reference.
TR, EU, and US: common scenarios
- TR — local SERP, TR accounts, local ads; country + (if needed) city; residential is a strong candidate
- EU — multi-country scrape / ads; separate country targets; plan DE/UK/NL/FR etc. separately
- US — high volume, state/city sensitivity; country + city; residential city, DC for speed
“180+ countries” is a network statement. On static residential, ISP, mobile LTE and similar lines, supported countries are product-specific. One “EU package” IP does not solve 27 countries. Think IPv4 / IPv6 with geo: if the target wants IPv6, an IPv4-only country list is not enough.
Thinking geo together with IPv4 and IPv6
Some services prefer IPv6 or behave differently on IPv4. Geo targeting must not become “I picked a country” independent of address family: both family (v4/v6) and country/city must be correct. Type comparison: residential / mobile / DC / ISP comparison ; session model: sticky vs rotating guide
Avoiding targeting mistakes
- Is the target market one country or many?
- Is city / local result required?
- Is ASN truly needed?
- Sticky or rotating? (geo fixed, IP changes — or geo+IP fixed)
- Does the product card actually offer this geo?
Country = market accuracy · City = local look · ASN = network identity (product-based). Soft CTA: locations → line → pricing
Geo + session + type: the triple lock
Geo alone is not enough. Using the same TR exit sticky or rotating is different work; using the same US city on residential or datacenter carries different risk.
- Type — appearance / speed / carrier (/blog/residential-vs-mobile-vs-datacenter-vs-isp-proxy)
- Session — sticky / rotating (/blog/sticky-vs-rotating-proxy-guide)
- Geo — country / city / ASN (this article)
Purchase order on WeProxy: scenario (use cases) → line (weproxy.io) → geo check (locations) → plan (pricing).
Practical notes for TR, EU, and US
- TR SERP: rotating residential + TR; city targeting if needed
- TR accounts: sticky residential / ISP + TR consistency
- TR + EU expansion: keep TR sticky accounts separate; EU scrape on separate rotating lines — do not mix geo
- EU: DE, FR, NL, PL… are separate targets; random EU countries pollute SERP
- US: state/city differences can matter for price, stock, and ads; verify city targeting on the residential card
When to skip ASN vs when to use it
- Skip: country / city already give the right result; target shows no ASN rules; sticky residential is enough
- Use: a specific carrier / network family is required; staying in one ASN improves session quality; the product card clearly offers ASN selection
Measurement: verify exit IP country/city, assert language/currency on SERP/price samples, alarm on country drift in sticky jobs. After geo tests pass, put production traffic on the WeProxy line.
Country is the minimum bar; city is locality; ASN is advanced. TR / EU / US are common targets — but verify the 180+ network against product coverage. On WeProxy, locations → product → pricing leads to purchase.