ASN Targeting: Real Engineering Use Cases for Network-Level Data Collection

Most people discover "ASN targeting" as a checkbox in a proxy provider's dashboard: pick an autonomous system number, get exits only from that network. It sounds like a niche feature. In practice, ASN-level targeting is one of the more powerful knobs in serious data collection, because the ASN is where network topology, corporate infrastructure, and regional economics all intersect. Country targeting gets you the right border; ASN targeting gets you the right network.

This post is about the real engineering uses — the cases where "any IP in Germany" is wrong and "an IP in this specific network" is right.

Why ASN Is the Natural Unit of the Internet

Quick grounding. The internet's routing layer is a set of ~75,000 autonomous systems, each a network under single administrative control, identified by an ASN, announcing IP prefixes via BGP. Every IP you ever request from lives inside one of these. AS15169 = Google. AS16509 = Amazon AWS. AS3320 = Deutsche Telekom. AS4837 = China Unicom.

Two consequences matter for collection:

First, content and infrastructure often vary by ASN, not just by country. CDNs route you to edge nodes by your network path; some sites serve different infrastructure to different networks; and geo-detection fallbacks (when GPS/headers are absent) often resolve to the ASN's registered location, not the IP's actual city.

Second, behavior baselines are partly per-ASN. Traffic from a university network looks statistically different from traffic from a mobile carrier. Anti-bot systems calibrate per-network expectations; matching your collection to the network a target's real users come from makes your traffic blend into the right baseline.

The Real Use Cases

1. Testing your own infrastructure's CDN behavior. Your site sits behind a CDN. Where do requests from AS3320 (China Unicom) actually land — your Singapore PoP or the one in Hong Kong? Do they get edge-cached content or origin fallbacks? You can't answer that from one geography; you need one request per relevant ASN through exits in those networks. Same for debugging "users in Brazil report our API is slow": which Brazilian ISPs? AS28573 (Claro), AS18881 (Telefônica), AS26599 (Vivo) may route to different PoPs with wildly different latency. ASN-targeted requests are how you reproduce the exact path, not just "South America-ish."

2. Ad verification and pre-bid diagnostics. When an advertiser says "our ad isn't showing in Germany," the question is which German networks — display networks, carrier bundles, and programmatic deals are often network-scoped. Verifying through exits in AS3320, AS6805 (Vodafone DE), and AS8881 (1&1 Versatel) tells you whether the delivery gap is regional or network-specific. Similarly for detecting DNS-level ad hijacking: if your ad calls resolve differently on one ISP than others, that's an ASN-scoped anomaly.

3. Competitive intelligence on network-scoped services. Some content is only meaningful inside certain networks: ISP-branded portals, carrier zero-rated bundles, intranet-ish services exposed to specific networks. Collection requires being routed inside the ASN — which is exactly what ASN-targeted exits give you.

4. Anti-bot blending. If your target's audience is, say, 60% one national carrier's mobile users, collecting from a mix of that carrier's ASN and a couple of consumer ISPs matches the traffic profile the site's defenses expect. Random global exits can produce a statistically bizarre mix (why is this page's traffic suddenly 30% Singapore datacenter?) that's itself a signal.

5. BGP/anycast and geolocation research. For anyone studying CDN topology, prefix hijacking, or IP-geolocation accuracy, per-ASN vantage points are the instrument of measurement itself — you can't study network-path variance without controlled points inside each network.

Doing It in Practice

Most quality proxy networks let you request exits by ASN in the credentials string (alongside or instead of geo). The pattern:

import requests
from collections import defaultdict

# Thordata-style credential: target a specific ASN with a sticky session
def asn_proxy(asn: int, sessid: str | None = None) -> dict:
    user = f"thor-user-pass-yourpassword"
    if sessid:
        user += f"-sessid-{sessid}"
    user += f"-asn-{asn}"
    url = f"http://{user}:[e-mail]:24125"
    return {"http": url, "https": url}

TARGET_ASNS = {
    "Deutsche Telekom": 3320,
    "Vodafone DE": 6805,
    "1&1 Versatel": 8881,
}

def probe(url: str) -> dict:
    r = requests.get(url, timeout=30)
    server = r.headers.get("x-served-by") or r.headers.get("server", "?")
    cache = r.headers.get("x-cache", "?")
    return {"status": r.status_code, "edge": server, "cache": cache,
            "rtt_ms": round(r.elapsed.total_seconds() * 1000)}

def cdn_view_matrix(url: str) -> dict[str, list[dict]]:
    """One sticky session per ASN, three samples each —
    see which edge each network actually hits."""
    out = defaultdict(list)
    for name, asn in TARGET_ASNS.items():
        s = requests.Session()
        s.proxies = asn_proxy(asn, sessid=f"cdn-probe-{asn}")
        for _ in range(3):
            try:
                out[name].append(probe_via(s, url))
            except Exception as e:
                out[name].append({"error": str(e)})
    return dict(out)

def probe_via(sess: requests.Session, url: str) -> dict:
    r = sess.get(url, timeout=30)
    return {"status": r.status_code,
            "edge": r.headers.get("x-served-by", "?"),
            "rtt_ms": round(r.elapsed.total_seconds() * 1000)}

if __name__ == "__main__":
    import json
    print(json.dumps(cdn_view_matrix("https://example.com/"),
                     indent=2, default=str))

A few practical notes from running this kind of probe in production:

Pair ASN with sticky sessions, not rotation. An ASN probe wants stable vantage points — a session pinned to one IP inside the network, so your three samples measure that network's path, not three different random exits. Rotation is for volume; sessions are for measurement. (I use Thordata's ASN suffix plus a session ID exactly for this — the exit stays put inside the target network.)

ASN + country can conflict — resolve it deliberately. A carrier like Vodafone operates in a dozen countries; ASN 6805 is Germany-specific, but transnational ASNs (Level3/AS3356, Cogent/AS174) exist everywhere and are useless for geo questions. When you need "this network and this country," pick nationally-registered ASNs; when you need transit-path behavior, the transnational ones are the point.

Verify your vantage point, always. Don't trust that the ASN suffix worked — assert it at runtime:

def assert_asn(expected: int):
    r = requests.get("https://api.iptoasn.com/1.2/ip/me",
                     proxies=asn_proxy(expected, "verify-1"), timeout=30)
    got = r.json().get("as_number")
    assert got == expected, f"exit ASN {got} != requested {expected}"

Providers occasionally have gaps in a pool, and silently falling back to the wrong network turns your measurement into noise. This one assert has saved me from publishing wrong CDN-mapping tables more than once.

Sample size per ASN matters. One request per network tells you almost nothing about CDN assignment, because assignment can be per-PoP and anycast-balanced. Three to five samples through a pinned session, repeated at different hours, gives you a defensible claim.

A Note on Coverage Realities

Not every ASN has available exits in every pool — the long tail of small regional ISPs is thin almost everywhere, and a provider's ASN coverage is basically a map of where its real devices or ISP partnerships live. Before you commit to an ASN-targeted design, test coverage for the specific networks on your list: request each ASN, assert the exit (as above), and see the hit rate. National carriers and big consumer ISPs are almost always well covered; a municipal ISP with 40,000 subscribers may not be, and for those cases the fallback is metro-level geo targeting, which approximates the network for most measurement purposes. Design for graceful degradation rather than assuming the checkbox implies universal coverage.

The Mindset Shift

Geo-targeting answers "what does this look like from somewhere in a country." ASN targeting answers "what does this look like from the actual networks where our users/infrastructure live." For CDN debugging, ad verification, carrier-scoped services, and traffic-profile blending, that's the difference between an approximate answer and a reproducible one.

The mental model I'd leave you with: treat the internet as ~75,000 networks, not ~200 countries. Most of your tasks only need the country. But when a task smells like "it works for some users and not others, in the same city" — that's almost always an ASN story, and now you have the tool to tell it properly.

Disclosure: I use Thordata's ASN-targeted proxy sessions for the network-scoped diagnostics described in this post. If you want to try them, they're at thordata.com, and the code **thor020* gets you 10% off.*