IP Reputation and ASN Detection: Why “Clean” IPs Still Get Blocked

You bought "clean" proxies. The IPs aren't on any blacklist — you checked. Your fingerprints are impersonated, your headers are perfect, and you still get challenged on the first request. The reason is usually one lookup the target site did in under a millisecond: it asked which network your IP belongs to.

This is ASN detection, and in 2026 it's the cheapest, most reliable signal in every anti-bot stack — ahead of TLS fingerprints, ahead of JavaScript challenges. This article explains how IP reputation actually gets computed, why "not blacklisted" means almost nothing, and what to check before you blame your code. It's the network-layer companion to our JA3/JA4 explainer.

ASN: The Signal You Can't Spoof

Every IP on the internet belongs to an Autonomous System — the network that announces it via BGP. AS numbers are public, free to look up, and impossible to fake from the client side. One lookup tells the defender:

• Who runs the network — AWS, Hetzner, Comcast, Vodafone…
• What kind of network it is — cloud/hosting, ISP/eyeball, mobile carrier, education, business
• What that network's traffic historically looks like

The logic is brutal and effective: real shoppers don't browse from inside an AWS data center. An IP from a hosting ASN (AWS, GCP, Hetzner, OVH, DigitalOcean) starts every session with a bot-probability prior of ~90%+. An IP from a residential eyeball ISP starts near zero. No JavaScript, no fingerprinting, no cost — the verdict is largely formed before your request body arrives.

Reputation Is a Score, Not a Blacklist

"My IP isn't on Spamhaus" is answering a 2010 question. Modern IP reputation is a continuously updated score per IP (and per /24, and per ASN), built from signals like:

Signal	What it tells the defender
ASN type	Hosting vs residential vs mobile — the baseline prior
Shared abuse telemetry	Cloudflare/Akamai/DataDome see this IP across all their customers — a ban earned on site A follows you to site B
Request velocity per IP	One household doesn't generate 50k requests/day
Session diversity	Hundreds of unrelated cookies from one IP = proxy exit
Port scanning / open proxy probes	Many vendors actively probe IPs for open proxy ports
IP age & churn	Ranges that recently changed hands or behavior get re-scored fast

Two consequences. First, reputation is shared: you inherit the sins of everyone who used that IP before you — this is why cheap, oversold residential pools underperform. Second, reputation is per-range, not just per-IP: one noisy neighbor can poison the /24 you're on.

The Hierarchy of IP Trust in 2026

1. Mobile carrier IPs — highest trust. CGNAT means thousands of real humans share each IP, so blocking one IP blocks real customers. Defenders are maximally cautious here.
2. Residential ISP IPs — high trust, the standard for serious scraping and account work.
3. ISP/static-residential ("business eyeball") IPs — good trust, stable, but lower plausibility for consumer-shaped traffic.
4. Datacenter IPs — near-zero trust on protected targets. Fine for unprotected APIs, internal tooling, geo-testing your own properties.

(Deep dive with pricing tradeoffs: choosing proxy types for agents covers the same hierarchy from the cost side.)

Check Before You Debug

Before touching your code, interrogate the exit IP itself. Through your proxy, ask: what ASN am I on, what type is it, where does geolocation place me?

# What does the world see when you connect through your proxy?
curl --proxy "socks5h://USERNAME:[email protected]:913" \
     "https://ipinfo.io/json"

# Look at "org": "AS7922 Comcast..."  -> eyeball ISP, good
#         "org": "AS16276 OVH SAS"    -> hosting ASN, you were sold datacenter

Three findings that explain "clean IP, still blocked":

• The "residential" IP is on a hosting ASN. Some providers resell datacenter ranges relabeled as residential. The ASN lookup exposes this instantly — if the org says OVH or ColoCrossing, you were sold datacenter.
• Geolocation mismatch. Your session claims a US storefront, the IP geolocates to Frankfurt — or worse, the IP's timezone contradicts your browser's Intl timezone. Cross-layer consistency checks catch this.
• The IP is fine; the fingerprint isn't. If the ASN is a real ISP and you're still blocked on request one, move up the stack — TLS/HTTP2 fingerprint (fix here) or headless artifacts.

Working With Reputation, Not Against It

• Match IP type to traffic story. Consumer-shaped traffic (social, retail, sneakers, tickets) needs residential/mobile. B2B SaaS dashboards tolerate ISP IPs. Public APIs don't care.
• Spread velocity. Reputation systems track per-IP request rates — rotating across a large pool keeps each exit under the radar; see rotation patterns in Python.
• Don't burn sticky IPs. With sticky sessions you're building per-IP history on the target — keep that history human-shaped, because you are the reputation now.
• Test pool quality before committing volume. Sample 20 exits from a provider, check ASN type and consistency on each. A pool that's 30% mislabeled datacenter will produce mysterious, intermittent block rates that look exactly like a code bug.

Summary

• ASN type is the first and cheapest bot signal — formed before your request is even parsed, unspoofable from the client.
• Reputation is a shared, continuous score per IP/range/ASN — "not blacklisted" is meaningless; history follows the IP across every site the vendor protects.
• Trust hierarchy: mobile > residential > ISP > datacenter. Match the IP type to the traffic you're imitating.
• Verify exits empirically: ASN org, type, geo-consistency. Mislabeled pools are a silent block-rate killer.
• IP clean but still blocked on request one? The problem is a layer up — fingerprints.