Massive ASN Targeting

An introduction to Massive ASN identifier targeting for routing requests through a chosen network.
proxy
web scraping
Published

27 Apr 2026 12:00

Massive is a residential proxy service that lets you steer requests through different exit-node pools. In my previous post I looked at its geotargeting feature, routing requests through exit nodes in a specific country, city or postal code. That covers a lot of use cases, but geography is not the only filter that matters.

Some sites treat traffic differently depending on the network it arrives from, not just the location. A residential broadband connection looks different from a mobile carrier, which looks different from a datacentre. Some content is locked to specific carriers. Rate limiting and CAPTCHA thresholds can be set per-network. Anti-bot systems flag traffic from certain networks regardless of where they are located geographically. If you need to appear as a specific type of network then geotargeting alone won’t help.

Massive handles this through ASN targeting. This post looks at how well it works in practice.

TipWhat is an ASN?

An ASN (Autonomous System Number) is a unique identifier assigned to a network operator. Every public IP address belongs to a network associated with an ASN.

An ASN is usually written with an “AS” prefix followed by a number. The number is the unique identifier assigned to that network. It has no special significance, it’s simply an identifier.

Some examples:

In an earlier post we saw that ASN information was returned in the payload from http://ip-api.com/. We’ll make use of that again in this post to verify that ASN targeting is working as expected.

How ASN Targeting Works

The implementation of this feature is similar to geotargeting. You add the required ASN to the proxy username. It can be combined with country targeting if you want to be more specific about the location of the exit node, although most ASNs are associated with a specific country, so country filter is often redundant.

Here are some examples (****** is a placeholder for the actual username):

******-asn-2856                         # bt.com
******-asn-16509                        # amazon.com
******-country-GB-asn-1273              # vodafone.com in the UK

Smoke Tests

I updated the script used in earlier proxy posts to send batches of requests through a few ASN routing rules. The requests were all directed at http://ip-api.com/, so that the responses would include ASN information along with details of the exit node location.

ASN

First I sent requests targeting four specific ASNs, without any country constraint. The results are mixed, which is useful because the failures are as informative as the successes.

Target Countries ASN match Distinct IPs Providers
Vodafone (AS1273) GB: 903 and DE: 97 100.0% 13 2
BT (AS2856) GB: 999 and CA: 1 99.7% 879 8
Aeza (AS210644) NL: 280, DE: 191, FI: 182, RU: 159 and SE: 124 84.1% 19 3
Amazon (AS16509) - - 0 0

Vodafone matched the requested ASN for every response. However, it used only 13 distinct IP addresses from 2 providers: Vodafone Group PLC (995) and Mercury (5). That looks odd at first, because the ASN match is perfect. But these fields are measuring different things. The ASN identifies the network the IP address belongs to, while the reported ISP is a provider or organisation label from the geolocation database. A retail brand, subsidiary, downstream network or legacy allocation can appear under a different provider label while still being announced inside Vodafone’s ASN. So this is not contradictory; it means the ASN targeting worked, but the provider labels are messier than the ASN boundary. The Vodafone ASN is still useful, but it looks like a fairly shallow pool.

For BT 99.7% of the responses reported the requested ASN. The locations were overwhelmingly in the UK. There was also a healthy-looking pool, with 879 distinct IP addresses across 8 providers: BT Public Internet Service (855), British Telecommunications PLC (74), EE Limited (66), Hydra Communications Ltd (1), EE route (1), BSkyB Broadband (1), M247 Europe SRL (1) and BTnet UK Core (1). Why the profusion of providers? Same reason as Vodafone, but with more providers.

Requests via Aeza were unreliable in this sample. The ASN match rate was only 84.1%, and the misses were not random noise. Every mismatch came from requests that were routed through Russia, where Massive returned AS12389 (PJSC Rostelecom) exit nodes instead of the requested AS210644. The rest of the sample did match AS210644, but that does not rescue the overall result: if roughly one request in six lands on the wrong ASN, then the targeting is not dependable for this ASN.

Amazon did not produce any successful results. Is this surprising? No. It makes perfect sense. In fact I’d be astonished if Massive were able to locate a residential proxy on Amazon’s network. Amazon is a cloud provider, not an ISP, and its ASN is not associated with residential IP addresses. I just threw that in as a sanity check, and it failed (or passed, depending on your perspective) as expected.

Requests Via ASN And Country

The country-constrained tests combine an ASN with a specific country. This is a more restrictive request because the proxy has to satisfy both filters.

Target Country Country match ASN match Distinct IPs Providers
SpaceX Starlink (AS14593) US 100.0% 99.8% 457 3
SpaceX Starlink (AS14593) GB 100.0% 99.9% 157 2
Aeza (AS210644) DE 96.1% 96.1% 3 2
Aeza (AS210644) NL 100.0% 100.0% 5 1
Aeza (AS210644) FI 100.0% 100.0% 5 1
Aeza (AS210644) FR 100.0% 100.0% 5 2

The SpaceX Starlink samples in the US and UK are clean country-constrained results: every response was in the requested country and the ASN match was also very high. Based on this I surmise that the country filter has higher precedence than the ASN filter, and that the ASN filter works as expected within the country pool. The Starlink network is global but it appears to be well-segregated by country, so ASN targeting is effective at routing through the requested network and country. Both the US and UK had a healthy pool of IP addresses distributed over a few providers.

The Aeza samples are mixed in a more operationally awkward way. Germany missed both the requested country and the requested ASN on 3.9% of requests, falling back to Rostelecom in Russia. The Netherlands, France and Finland were clean when they worked, but each pool exposed only a few distinct IP addresses. While gathering the data I also saw these combinations disappear intermittently, so even the successful ASN-country pairings looked fragile.

Targeting the Aeza ASN through Russia returned (Unknown Status Code) for every request. Almost certainly Cloudflare simply blocking on country.

Summary

ASN targeting is a genuinely useful feature but it comes with more rough edges than geotargeting. The results split into three tiers: it works well, it works partially or it doesn’t work at all.

At the top end, BT and Vodafone both performed solidly with high ASN match rates. BT had a healthy pool of distinct IP addresses; Vodafone’s pool was shallow (useful if you need that network, but not somewhere you should drive a high volume of requests). Amazon produced nothing, which is the expected result: it’s a cloud network with no residential IPs, and it was only included as a sanity check.

The combined ASN-country tests were the most revealing. SpaceX Starlink was the cleanest result with high country and ASN match, combined with decent pool depth in both the US and the UK. The Aeza combinations exposed the real limitation: one sample fell back to the wrong country and wrong ASN, and the successful combinations still had tiny pools and intermittent availability.

That last point captures the nature of the feature. Massive will route through the requested network when the pool is there, but the pool is not guaranteed. Some combinations simply are not in the inventory at a given time. ASN targeting is best-effort, and knowing that upfront can save a lot of head-scratching.