Don't Ban the Whole ASN: Why Network-Level Proxy Blocklists Miss Residential Exits

#api #security #networking #devops

A common abuse shortcut is to treat an ASN like a verdict: if the network shows up in proxy telemetry, ban the whole AS. That works when a network is almost entirely hosting space. It fails on the networks that carry most of today's proxy exits — the big broadband ASNs where residential, gateway, and datacenter segments sit side by side.

IP99 publishes per-ASN usage mix (residential vs datacenter vs gateway) and a free per-IP risk lookup. Use the ASN page to understand the network; use the IP lookup to decide on one address.

Why ASN denylists feel attractive

Autonomous System Numbers are stable, cheap to store, and easy to enforce at the edge. One rule can cover millions of addresses. For a cloud-hosting ASN that is almost all datacenter space, that bluntness is sometimes acceptable: you are mostly cutting VPN exits, scrapers, and VPS proxies, and the collateral is other hosting traffic.

The problem is that the proxy market moved. Commercial residential and dial-up pools sell exits that sit on ordinary ISP address space. Those exits share ASNs with home subscribers, CGNAT pools, and enterprise gateways. An ASN that "appeared in a proxy feed" is often the same ASN that carries tomorrow morning's login from a real customer.

Two ASNs, two shapes (live 2026-10-18)

AS15169 (Google) in the IP99 ASN view: about 90% datacenter segments and 10% gateway / NAT, across 189 countries (~1.7M IPv4 addresses in located segments). A hosting-heavy AS is where datacenter proxies and VPN exits tend to live — network-level suspicion is at least directionally coherent.

AS4134 (a large China telecom ASN): about 44% residential broadband, 26% datacenter, 23% gateway / NAT, covering ~100M IPv4 addresses, ~99.9% in China. Ban-the-ASN here means cutting ordinary home and CGNAT users along with any exits that happen to ride the same network.

Numbers above are from ip99.com/en/asn/15169 and ip99.com/en/asn/4134 as of 18 October 2026. Shares are by located IPv4 segment, not BGP announcement counts — so they can differ from a routing table.

This week's proxy-exit window (11–17 Oct 2026 UTC) still landed ~80% in residential broadband and only ~2% in datacenter — so an ASN blocklist aimed at hosting space is pointed at the thin end of the feed. Source: ip99.com/en/proxy-exits (50 upstream sources; not a world census).

The same weekly page lists AS4134 first among networks that held newly captured exits (~8.6% of the window). That is not an invitation to ban AS4134. It is evidence that the highest-volume exit traffic rides mixed broadband space — exactly where ASN bans do the most collateral damage.

Same ASN, opposite IP stories

Look up one address at a time. No key:

curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/ip/27.22.66.200

Live shapes re-fetched 2026-10-18 (Asia/Shanghai):

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

{
  "ip": "27.22.66.200",
  "evidence_state": "active",
  "network": { "asn": 4134, "usage_type": "DYN" },
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624"
  },
  "risk": {
    "score": 37,
    "level": "medium",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Notes that matter in a pipeline:

network.usage_type: IDC vs DYN (residential) vs GTW (gateway/NAT). Network type is not a proxy verdict by itself — datacenter is not "malicious", and residential is not "human".
risk.signals: hosting on 8.8.8.8 means the address sits in hosting space; it is not the same as an active proxy / dialup_pool observation.
evidence_state: active means fresh proxy-class evidence is scoring; none means no current verifiable evidence — score 0 is not "safe".
ASN alone: 27.22.66.200 sits on AS4134 residential space and currently carries dial-up / hijacked-proxy evidence. Neighbors on the same AS may be ordinary subscribers with score 0.
What the score is not: IP99's score measures freshness and strength of evidence. It is not "the probability that this address is an attacker".

Collateral damage you actually feel

On mixed broadband ASNs, a permanent ASN denylist tends to hit:

Home broadband (DYN) — the same space residential proxy networks sell, and the same space real customers use.
Gateway / NAT egress (GTW) — office and campus exits where one public address sits in front of many people.
Mobile / CGNAT-adjacent pools — where one address can sit behind a large share tier; blocking the IP (or the whole AS) is closer to blocking a neighborhood than blocking one actor.

That is why "this ASN appeared in last week's exit list" is a research hint, not a production firewall rule. Prefer time-stamped evidence on the exact address, and let that evidence decay when the address changes hands.

A practical triage order

Read evidence_state and risk.signals for the exact IP.
Use network.usage_type + ASN page mix as context (how surprising is a proxy on this network?).
Prefer decaying, time-stamped evidence over permanent ASN denylists — especially on mixed broadband ASNs.
Treat any single feed — including this one — as one input among several. No source sees the whole proxy market.

Anonymous quota is 500 lookups/day per public IP (X-Daily-Limit / X-Daily-Remaining on the response). Free account raises that to 5,000/day. Docs: ip99.com/api.

Try it

Per IP: curl https://ip99.com/v1/ip/<ip> or omit the IP to ask about your own egress.
Per ASN: ip99.com/en/asn/ (usage mix + country mix).
Weekly proxy-exit aggregates (no address lists): ip99.com/en/proxy-exits.

IP99 is a ThreatHunter product. The point is not "block every ASN that ever appeared in a feed" — it is to act on fresh evidence on one address, and to know when the network around it is too mixed for a blunt ban.

DEV Community