ASN targeting picks the network behind the IP, not the place. What it costs, when it is the only thing that works, and why exclusion is the better half.
· 13 min read · Targeting
Every proxy filter you add narrows the set of addresses that can serve your request. Country narrows it. City narrows it further. ASN targeting narrows it to one network operator, which is the tightest filter most proxy networks expose — and on AnonEdge it is billed as an advanced Target Filter at 2x the standard per-GB rate. So the only question worth asking about ASN targeting is not what it is. It is when the result justifies doubling your rate against a pool you just made smaller.
That question has four good answers and a lot of bad ones.
Run this before reading the definition:
whois -h whois.cymru.com " -v 8.8.8.8"
AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
15169 | 8.8.8.8 | 8.8.8.0/24 | US | arin | 1992-12-01 | GOOGLE, US
That is an Autonomous System Number. AS15169 is the identifier for the block of network infrastructure Google announces to the rest of the internet via BGP. Every routable address on the internet belongs to exactly one AS at a time, and the mapping is public, queryable, and updated by the operators themselves rather than inferred by a third party.
Swap 8.8.8.8 for an exit address you already hold and you will get the network
that address actually belongs to. Do that on twenty of your own exits before you
buy any targeting at all — for a lot of workloads the answer is that you are
already landing where you needed to be.
ASN targeting instructs the gateway to select an exit address that belongs to a specified autonomous system. Where country targeting asks "where is this address located," ASN targeting asks "who operates the network this address sits on." Those are different questions and they fail in different ways.
The distinction matters because location is inferred and ownership is declared. An address's country comes from a geolocation database that a vendor compiled by inference and refreshes on its own schedule. An address's ASN comes from the routing table — it is who announced the prefix. Registry records lag reality in their own ways, but ASN is structurally the more reliable of the two attributes, and that is the underappreciated argument for using it.
It is also why ASN targeting produces an honest error rather than a quiet approximation when it cannot be satisfied. More on that below.
The documentation-only SERP behind this topic has produced three names for roughly one capability, and the vocabulary confusion costs people money.
| Term | What it usually means | Resolution |
|---|---|---|
| ASN targeting | Select exits announced by a specific autonomous system number | Exact. One AS |
| ISP targeting | Select exits belonging to a named provider | Approximate. A large ISP operates several ASNs |
| Carrier targeting | Select exits on a named mobile network | Approximate, and often the mobile subset of an ISP's ASNs |
Read that table in one direction: ISP and carrier targeting are ASN targeting with the ASN list hidden from you. A national ISP may announce a dozen autonomous systems covering consumer broadband, business fiber, mobile and legacy acquisitions. Ask for the ISP and you get any of them. Ask for the ASN and you get the one you specified.
If your test needs a specific network path, name the number. If you just need "a real consumer connection on a big incumbent," the ISP-level abstraction is fine and you will find far more addresses available.
Everything else on this list can be done with country or city filters. These four cannot.
1. ISP-differentiated pricing or content. Some operators bundle content, zero rate their own services, or price differently for subscribers arriving on their own network. You cannot reproduce that from a neighboring network in the same city. The variable under test is the network, so the network is what you have to control.
2. CDN edge selection. Which edge node serves you is a function of BGP and peering relationships, not of how many miles away you are. Two addresses in the same metro on different ASNs can be answered by different points of presence, with different cache contents and different origin behavior. If you are debugging why one population of users sees stale assets, ASN is the only lever that reproduces it.
3. QA against a specific carrier's network behavior. Middlebox behavior, path MTU, transparent compression, IPv6 deployment and HTTP-level rewriting all vary by carrier. An app that misbehaves for one carrier's subscribers and nobody else is a network-path bug, and reproducing it means being on that path.
4. Ad delivery and fraud investigation. Ad decisioning frequently keys on the network as a signal, and fraud investigation often needs to reproduce traffic from the exact autonomous system a pattern originated on to confirm whether it came from a consumer connection or from infrastructure.
Notice what is not on this list: general block avoidance. Reaching for ASN targeting because a target keeps blocking you is a common and expensive mistake. It narrows your pool, doubles your rate, and does nothing at all about the fingerprint, header order or cookie state that is more likely to be identifying you.
Each filter is an intersection, and intersections only shrink.
all exits
-> country = US
-> state = Illinois
-> city = Chicago
-> ASN = AS7018
Every arrow discards candidates. By the last line you are asking for addresses that are simultaneously in one metro and on one operator's network — and residential exits are somebody's live connection, so the set is not just small, it changes hour to hour as people close laptops and leave the house.
Nobody can honestly publish a multiplier for that contraction, including us. It varies by country, by operator, by hour of day, and by how many other customers are asking for the same slice right now. Any provider quoting you a fixed "available IPs per ASN" number is quoting a headline, not a measurement.
What you can do is measure your own. The method:
The curve flattening tells you that you are near the practical working set for that filter at that moment. Treat the number as a lower bound with a timestamp, not a census — an address that is offline right now still exists. Run it again at a different hour before you conclude anything, because residential availability follows the sun.
Do that once per filter combination you are considering, and the trade-off stops being theoretical.
AnonEdge charges advanced Target Filters — state, city, ZIP and ASN inclusion — at 2x the standard per-GB rate. Country selection, country exclusion and ASN exclusion are default targeting and carry no premium. The filters are documented under ASN and geo targeting options.
Here is why the premium is not the number that should worry you.
Take residential traffic at $1.99/GB as of 2026-08-06 — check the current per-GB rates before you plan a budget, because rates change. Under an advanced Target Filter that becomes $3.98/GB. Now assume a contracted pool causes some fraction of your requests to fail and retry. The arithmetic, with the failure rate as an assumption rather than a measurement:
| Scenario | Effective rate | Requests that land | Cost per successful request |
|---|---|---|---|
| No advanced filter, hypothetical baseline success | 1x | 1.00 | 1.00 unit |
| Advanced filter, same success rate | 2x | 1.00 | 2.00 units |
| Advanced filter, half the success rate | 2x | 0.50 | 4.00 units |
The rate doubled. The cost per successful request quadrupled. That second doubling is invisible on your invoice, because you are billed for the retries too — they consumed bandwidth and returned nothing.
So the discipline is: measure your success rate with the filter on and with it off, on the same target, in the same hour. If the filter does not change what the target returns, it is costing you 2x for a variable you were not testing.
400 NO_RAYWhen no exit address matches your filter, the gateway returns 400 NO_RAY,
documented under proxy error
codes. No address was available for
the combination you asked for.
That error is a feature, and it is worth understanding why.
The alternative design — the common one — is silent substitution. No exit matches the filter, so the network quietly routes you through the nearest available address and returns a completely normal 200. Your job succeeds. Your dataset is now contaminated with rows that did not come from where you think they came from, and nothing anywhere logged that fact. You find out weeks later, if at all, when a conclusion does not survive contact with reality.
An explicit error costs you a retry. A silent fallback costs you the dataset. The city-targeting case is where that failure mode does the most damage, and how to verify a city filter is built entirely around detecting it.
When 400 NO_RAY fires, widen one level at a time and note which level fixed
it: drop the ASN and keep the city, or drop the city and keep the ASN. Whichever
one you had to drop was the filter that had no supply.
Everyone reaches for inclusion. Exclusion is frequently the better tool, and on AnonEdge it is default targeting rather than an advanced Target Filter — no premium.
The use case: rather than naming the one network you want, name the networks you do not. Hosting providers, cloud platforms and VPN operators announce well-known autonomous systems, and plenty of targets treat traffic from those ranges as non-consumer by default regardless of what a geolocation database says the address's city is. Excluding them removes a class of addresses that were going to fail before you spend bandwidth discovering that.
The workflow that makes this concrete:
That is an empirical exclusion list built from your own traffic against your own target, which beats any generic block list, and it costs nothing extra to apply.
The two get conflated constantly. They answer different questions.
| Your objective | Filter | Why |
|---|---|---|
| Reproduce ISP-differentiated pricing or bundling | ASN | The variable is the operator, not the place |
| Collect localized pricing, tax or currency | City or ZIP | The variable is the place, and the target reads it from a geo database |
| Debug CDN edge or peering behavior | ASN | Edge selection follows BGP, not distance |
| Verify a localized SERP or a store locator | City | The target's own localization is the signal you are testing |
| Test carrier middleboxes, MTU or IPv6 behavior | ASN | You need the network path, and the mobile pool is where carriers live |
| Reproduce ad delivery that varies by network | ASN | Ad decisioning frequently keys on the network |
| Reduce blocks | Neither | Both narrow the pool. Blocks are usually a fingerprint problem |
The last row is the one that saves people the most money.
When you genuinely need both — one city and one carrier — expect 400 NO_RAY
more often, and decide in advance which filter you will drop first. Deciding
that at 3 a.m. while a pipeline is failing produces the wrong answer.
Targeting is applied per session rather than per request, and how you express it determines whether it survives your authentication setup.
Two places carry it. The account default — country selection, country exclusion and ASN exclusion — is configured once and saved, and it applies to every session that does not override it. Per-session targeting rides in the proxy username, appended to your login as structured parameters, because the username is the only free-form field the proxy protocol lets a client send per connection. Read your own parameter format off ASN and geo targeting options rather than copying a string from a blog: the field names and the delimiter are provider-specific, and a mis-delimited username fails as an authentication error rather than as a targeting error, which sends you looking in the wrong place.
The interaction worth flagging regardless of syntax: on networks where targeting parameters ride inside the proxy username, IP whitelisting and per-request targeting are mutually exclusive. Whitelist authentication removes the username field, and the username field is where the parameters were. Teams adopt whitelisting to simplify credential handling, then discover their targeting no longer varies per session. That trade-off is covered in targeting parameters and authentication. Confirm which model applies to your account in your proxy settings before you build tooling around either.
ASN targeting tells the proxy gateway to select an exit address belonging to a specific autonomous system — one operator's network — rather than simply an address in a country or city. Where geolocation is inferred by a database vendor, ASN comes from the routing table itself. Use it when the network behind the address is the variable you are actually testing.
Query Team Cymru's IP-to-ASN whois service:
whois -h whois.cymru.com " -v 8.8.8.8". It returns the AS number, the BGP
prefix, the country code, the registry, the allocation date and the AS name. Run
it against exit addresses you already hold before buying any targeting — you may
already be landing on the networks you need.
On AnonEdge, ASN inclusion is an advanced Target Filter billed at 2x the standard per-GB rate, alongside state, city and ZIP. ASN exclusion is default targeting and carries no premium. The larger cost is usually indirect: a narrower filter means fewer available exits, more retries, and a cost per successful request that rises faster than the rate itself.
No exit address matched your filter combination at that moment. Residential exits are real consumer connections, so availability for one operator in one place changes hour to hour. Widen one level at a time — drop the ASN or drop the city — and note which change fixed it. That tells you which filter had no supply rather than leaving you guessing.
No, and treating it that way is expensive. Both filters narrow your pool, and a narrower pool means each remaining address absorbs more of your traffic. Blocks usually come from TLS fingerprints, header order, cookie state or account linkage — none of which change when you switch networks. Fix the fingerprint before you pay 2x for a filter.
Yes, and the intersection is small. Requiring one metro and one operator
simultaneously produces the tightest filter the network exposes, and 400 NO_RAY becomes routine rather than exceptional. Decide in advance which filter
you drop when supply runs out, and measure your available pool at more than one
hour of the day before committing a pipeline to the combination.
Three steps, in order. Resolve the exits you already have to their ASNs and check whether you were already there. Measure the working pool for the filter you are considering, at two different hours. Then run the same job with the filter on and off against the same target and compare what the target returns — if the response is identical, you are paying 2x for a variable you were not testing.
Check the per-GB rates before you plan a filter-heavy budget, and see which countries are in the pool for the geography side of the decision. For sustained ASN-heavy workloads, talk to sales with your target ASN list first — that conversation is cheaper than discovering supply limits in production.