If you’ve shopped for proxies in the last year, you’ve seen the same three labels everywhere: residential, ISP, datacenter. The labels are familiar enough that most teams pick a category and move on. The mechanics underneath are less familiar, and that’s where most production problems originate.
This is a walkthrough of what an IP actually is, what target sites read from it, and why “residential” is more like a spectrum than a binary classification.
What an IP address actually represents
An IP address is a routing number. It points to a network interface on a machine connected to the public internet. That’s the entire functional definition.
Everything else, the residential-vs-datacenter distinction, the geographic association, the “reputation” of the IP, is metadata layered on top by external parties. The IP itself doesn’t carry any of that. It’s looked up against databases that say “this IP belongs to network X, which is owned by entity Y, which the database has classified as type Z.”
The two most important pieces of metadata are:
ASN (Autonomous System Number). Every block of IPs on the internet is registered to an ASN. ASNs belong to organizations: Comcast (AS7922), Verizon (AS701), Cloudflare (AS13335), Amazon AWS (AS16509). When a target site receives a request, the first thing its anti-bot layer does is look up the source IP’s ASN and check what kind of organization owns it.
Geolocation. A separate database (MaxMind GeoIP2, IP2Location, in-house equivalents) maps IP blocks to geographic coordinates. The accuracy ranges from country-level (very reliable) to city-level (mostly reliable) to street-level (mostly fictional). The site uses this to determine where to claim the visitor is, what currency to show prices in, what local results to surface.
Both of these are external databases. The IP doesn’t know what country it’s in. The IP doesn’t know who owns it. Everyone is reading from the same set of providers, and those providers occasionally disagree with each other.
The three IP categories, mechanically
Now the labels.
Datacenter IPs. ASN belongs to a hosting provider, AWS, GCP, Azure, OVH, Digital Ocean, Hetzner. The IP block is registered to “hosting” in the major reputation databases. Geolocation maps to wherever the colo facility is. These IPs are cheap to acquire and have ~zero residential reputation, so target sites with active defenses treat them with high suspicion by default.
Residential IPs. ASN belongs to a consumer ISP, Comcast, Spectrum, Deutsche Telekom, BT, Free, NTT, plus thousands of regional providers. The IP block is registered to “residential” or “consumer” in the reputation databases. Geolocation maps to the household area the ISP serves. These IPs have years of “real consumer” behavior associated with them (someone in that household streams Netflix, browses Twitter, plays Steam) so the reputation databases have positive prior on them.
ISP IPs. ASN belongs to a consumer ISP, BUT the actual machine the traffic egresses from is sitting in a datacenter. The ISP has allocated a block of their address space to a colocation customer, who routes traffic through it. The ASN lookup says “residential ISP.” The reputation databases say “residential.” The traffic moves at datacenter speeds. This is the “ISP proxy” category, and it exists precisely because target sites’ anti-bot decisions are made on ASN lookup, not on the actual hosting reality.
The labels aren’t lying. They map to real, observable differences in what the upstream lookups show. They just don’t map to “where the physical machine is”, and target sites mostly don’t check that.
What the target site reads, step by step
When a request hits a defended site, the anti-bot layer typically runs through this sequence:
1. ASN lookup. Source IP gets looked up against an ASN database. Result: name of the owning network and its classification (residential / hosting / business / mobile / unknown).
2. IP reputation lookup. Source IP gets cross-referenced against a reputation database that aggregates signals from the rest of the web. Has this IP been involved in credential stuffing? Comment spam? Scraping? The reputation score is per-IP, fed by data from sites that share signals (Cloudflare runs the largest pool; smaller players consume from it or pay specialists).
3. Geolocation lookup. Source IP gets mapped to a country, often a city. The site uses this to localize the response (prices, language, regulatory disclosures, available products).
4. Fingerprint check. This is independent of the IP but the site does it in parallel. The request’s User-Agent, TLS handshake order (JA3/JA4), browser-emitted signals (canvas, fonts, WebGL) all get fingerprinted and compared against known bot fingerprints.
5. Behavioral history. If the session has continuity (cookies, fingerprint match across requests), the site looks at the multi-request pattern. How many pages per minute? How natural is the click cadence? Did the visitor scroll? Did they hover?
A clean residential IP gets past steps 1, 2, and 3 with flying colors. The site sees “Comcast, residential, US-East, neutral reputation” and serves the real page. The fingerprint and behavioral checks happen but the prior is much more forgiving than for a datacenter IP.
A datacenter IP triggers immediate suspicion at step 1. The site can already justify serving a degraded version, blocking, or pushing a CAPTCHA before it even reads the request body.
An ISP IP looks identical to a residential IP at the ASN level, so it gets past step 1 the same way. Reputation databases sometimes catch it (some specialists detect that “this IP block has hosted requests with very unhuman timing patterns”) but most still classify it as residential.
Why “residential” isn’t enough
A residential ASN gets you past the gate. It doesn’t guarantee anything past that.
What the site can still see, on a residential IP:
- Request volume per IP. A residential IP making 500 requests per minute to the site’s product pages doesn’t match “household visitor.” Even with a clean ASN, the rate alone is a signal.
- TLS fingerprint. Real browsers produce specific TLS cipher orderings, extension lists, and ALPN values. A scraper using Python’s
requestslibrary produces a different TLS fingerprint that’s been catalogued and recognized for years. Residential ASN + Python TLS = obvious bot. - Header anomalies. Real browsers send dozens of headers in a specific order with specific values. Missing Accept-Language, mismatched Sec-Ch-Ua, an order that doesn’t match Chrome’s actual emission order, all signals.
- Behavioral signature. Real visitors hover, scroll, abandon, come back. Bots fan out across pages in a straight line. Pages-per-session, time-on-page, the presence or absence of mouse events, are all measured.
A scraper running on a residential IP without addressing any of the above will get classified eventually. The IP just buys time, not invisibility. The teams that succeed at sustained data collection invest in the rest of the stack too: realistic User-Agents, hardened headless browsers, sane request cadences, plausible session shapes.
What this means for picking a network
A few practical implications:
Pool size is one signal, not the whole signal. A pool of 200 million residential IPs gives you more replacement options when individual IPs get burned. It doesn’t make each individual IP harder to detect. What matters as much is the network’s ability to rotate burned IPs out, surface fresh ones in, and maintain ASN/geographic diversity over time.
Sourcing matters more than buyers usually realize. IPs sourced through transparent opt-in agreements with consenting users behave more like real consumer traffic on the wire (because they ARE real consumer traffic, intermittently used). IPs sourced through less transparent channels often have behavioral fingerprints that anti-bot systems have specifically learned to recognize.
The right network for one workload isn’t the right network for another. A fan-out scraping pipeline against tolerant targets benefits from a giant pool with per-request rotation. A long-lived account-management workflow needs pinned ISP IPs with session persistence. An AI agent doing multi-step browsing needs sticky residential sessions per run. Picking a single “best” network is the wrong frame.
The IP is one of many signals. Even a perfect residential IP can get a request blocked if the request itself looks robotic. Conversely, a less-perfect IP can succeed when the surrounding request shape is plausible. The IP layer is necessary but not sufficient.
The take-away
When you’re picking a residential proxy network, the question isn’t “is it residential” (every credible network’s IPs are residential by ASN). The questions are:
- How is the network sourcing its IPs?
- How quickly does it rotate burned IPs out?
- How geographically and ASN-diverse is the pool?
- How well does the gateway preserve session state when you need it?
- What does the request shape look like when it leaves the gateway?
These are answerable questions, and the answers matter more than headline pool size. The mechanics underneath the “residential” label are where the actual quality lives, and where the actual production behavior is determined.