ASN or ISP targeting is about the network identity behind an IP, not its street address. If you need a specific provider name or carrier footprint, you are selecting by the owner and route of the IP space rather than the city alone. For a full map of geo layers and what providers actually expose, see proxy IP geolocation & targeting guide.
What is ASN/ISP targeting?
ASN/ISP targeting lets you choose IPs by the autonomous system (ASN), ISP brand, or mobile carrier that announces the IP space. It influences how risk engines and whitelists classify you, but it is not a precise city selector.
In practice, the vendor assigns IPs from netblocks associated with a named operator (e.g., a national ISP or a hosting ASN). Many services judge “hosting vs consumer” identity primarily from this owner record, which can change pass rates even when the geo stays the same.
Synonyms you may see
ASN targeting, AS-level targeting, ISP targeting, carrier targeting, operator targeting.
Vendors and tools mix these terms; always confirm whether they filter by ASN number, ISP brand string, or internal tags mapped to public data.
Where is ASN/ISP filtering actually available?
ASN filters exist most often for datacenter and ISP/static-residential pools, and carrier names exist for mobile pools. Self-serve UI filters are limited; many vendors expose them only via support.
Datacenter: choose known hosting ASNs or brands; sometimes specific subnets or gateways per ASN. ISP/static residential: select major ISPs by name or ASN. Mobile: select by carrier name; MCC/MNC is rarely exposed in retail panels.
Typical availability by network type
- Datacenter: Hosting ASNs, sometimes per-subnet or per-gateway lists.
- ISP / Static Residential: Major consumer ISPs in popular countries; long sessions possible.
- Mobile: Carrier labels like “Carrier X 4G”; results often reflect operator PoPs rather than a small city.
- Rotation model note: Some pools can pin ASN for sticky sessions; others may hop ASNs on rotation.
For how datacenter, ISP, residential, and mobile pools deliver IPs, see proxy network types.
Why choose by ASN or ISP?
ASN/ISP choice reduces “hosting” flags and aligns with whitelists that accept only specific operators. It can also steer CDNs and edge caches toward local catalogs and prices.
Examples: avoid hosting ASNs for ticketing checkouts, match a bank’s “allowed ISP” policy, unlock domestic streaming catalogs that key on ISP identity rather than IP city.
Verification: how to confirm you got the right operator
You must validate labels in multiple sources, because databases disagree and ownership changes over time. Keep the same IP through the entire app flow to avoid mid-journey identity changes.
Steps: obtain the vendor’s ASN/ISP-labeled inventory with pool size and refresh cadence; cross-check ASN/Org and geo in 2–3 databases; test inside the target app; use sticky sessions for flows that span multiple requests.
Minimal test loop
- Request an IP labeled with your target ISP/ASN.
- Check ASN and Org in multiple lookups.
- Run the actual app flow (not just a header check).
- Monitor if rotation changes ASN mid-session.
- Record pass/fail per operator for procurement decisions.
Common pitfalls and how to spot them
Carrier-grade NAT, DS-Lite, anycast, tunnels, and PoP pinning can distort both city and owner perception. Database labels drift when netblocks change hands or when MVNOs inherit upstream ASNs.
Watch for MVNOs showing the parent carrier, re-announced prefixes after M&A, and PoP-based resolution that looks like a big city even if the subscriber is elsewhere.
Red flags
- Inconsistent owner names across data sources.
- Session identity flips after rotation or failover.
- Carrier label matches, city doesn’t: typical for PoP-based routing.
- Aged WHOIS: recent transfers not reflected in commercial DBs.
Configuration patterns that help
To keep identity stable, use sticky sessions and avoid triggers that rotate mid-flow. When rotation is necessary, rotate between full flows, not between steps.
Set session TTL to comfortably exceed your longest flow, and keep concurrency per operator within vendor limits so the pool does not silently spill into different ASNs.
Practical settings to try
- Sticky on: hold up to N minutes per session; renew between full workflows.
- Concurrency: cap threads per operator to the vendor’s documented per-ASN pool.
- Fallback plan: define what to do if the requested ISP is temporarily exhausted.
Procurement checklist (what to ask vendors)
Define the operator list you need, how many parallel sessions, and how long each session must last. Require minimum pool per operator and clear replacement rules when labels drift.
Ask for refresh cadence, pass-rate history per operator, and how they handle ownership changes or wrongly labeled ranges.
Request these specifics
- Target ASN/ISP list, required concurrency, expected session length.
- Minimum pool per ASN/ISP and the refresh policy.
- Replacement rules when pass rate drops or labels change.
- Whether sticky sessions guarantee no mid-session ASN hop.
Managing expectations: limits of ASN/ISP targeting
No provider can guarantee 100 percent recognition of your chosen ISP across all databases or sites. Carrier targeting often resolves to operator PoPs rather than the physical city you expect.
Treat database identity as probabilistic. Build margin for mismatches, and plan for ongoing curation as labels drift.
How providers implement it (UI vs support)
Retail panels rarely expose full operator lists; many providers curate custom gateway lists on request. Some offer per-operator endpoints or tags; others allocate blocks manually.
Expect ASN/ISP targeting to be a premium or custom feature. The more granular the request, the more likely you’ll coordinate via support.
Testing playbook you can reuse
A short, repeatable test saves budget and avoids chasing mislabeled ranges. Always test inside the target application, not just with a single IP info site.
Run a batch per operator, record app-level outcomes, and promote only the operators that meet your threshold.
Example pass/fail matrix (per operator)
| Operator label | Pool size (claimed) | Sessions tested | App passes | App fails | Mid-session ASN hops |
| ISP A | 2,000 | 100 | 92 | 8 | 0 |
| ISP B | 800 | 100 | 70 | 30 | 3 |
| Carrier C | 1,500 | 100 | 81 | 19 | 1 |
Interpretation: keep ISP A, trial more of Carrier C, demote ISP B until pool refresh or replacement.
Troubleshooting quick answers
Most failures come from rotation during the flow, mislabeled ownership, or pools that are too small for your concurrency. Adjust session TTL, lower concurrency per operator, or switch to a larger-labeled pool.
If a site keys on a strict whitelist, collect pass logs and ask the vendor for a different subnet within the same operator or a replacement operator known to pass.
FAQ
Q1. Is ASN targeting the same as city targeting?
No. ASN/ISP targeting selects the network owner identity, not the street-level location. City may be approximate, especially for carriers that egress from PoPs.
Q2. Can I get a guarantee that the IP is from a specific ISP?
You can get best-effort allocation and sticky sessions, but recognition varies across databases and sites. Treat labels as probabilistic and verify inside your app.
Q3. Why did my session start on the right ISP but later fail?
Rotation or failover likely changed the egress to a different ASN mid-journey. Use longer sticky sessions or switch to pools that pin identity per session.
Q4. Do mobile carriers support fine-grained city selection?
Rarely. Many resolve to operator PoPs in major metros. If city precision matters, validate on the specific site and consider static ISP pools.
Q5. What data should I collect during trials?
Operator label, ASN number, session duration, concurrency, pass/fail per step, and whether ASN stayed stable. Keep a matrix per operator for procurement choices.