A proxy server sits between a client and a destination server. The destination sees the proxy's IP address instead of the client's real IP. At the TCP level, the connection originates from the proxy — the destination server has no direct visibility into where the original request came from.

This is straightforward at the network layer. The complexity comes from how websites have learned to classify and score incoming IP addresses based on signals far beyond the IP address itself.

Datacenter Proxies: How They Work

Datacenter proxies are hosted on servers inside commercial data centers — AWS, Google Cloud, DigitalOcean, Hetzner, OVH, and hundreds of smaller providers. The IPs assigned to these servers are owned by the hosting companies, not by internet service providers that serve residential customers.

At the infrastructure level, datacenter IPs have several characteristics:

ASN ownership — the IP belongs to an Autonomous System Number registered to a hosting company, not a consumer ISP. When you query the WHOIS record for a datacenter IP, the organization field typically shows a cloud provider or hosting company name.

Subnet density — datacenter IPs are allocated in large, contiguous blocks. A single hosting provider might own millions of IPs in sequential ranges. This density is unusual for residential allocations, which tend to be smaller and more fragmented.

Latency patterns — datacenter servers have very low and consistent latency. Residential connections have higher and more variable latency due to the last-mile infrastructure of consumer internet.

No PTR record variation — datacenter IPs often have predictable reverse DNS patterns. A residential IP typically has a PTR record that reflects the ISP and geographic region in a pattern specific to consumer infrastructure.

Datacenter proxies are fast, cheap, and easy to provision at scale. A single provider can offer millions of IPs for fractions of a cent per request.

Residential Proxies: How They Work

Residential proxies route traffic through IP addresses assigned to actual residential internet connections — home routers, mobile devices, and consumer ISPs. The IPs are owned by consumer ISPs like Comcast, BT, Deutsche Telekom, or regional carriers.

The technical path is more complex than a datacenter proxy:

1. The client sends a request to a residential proxy network's gateway

2. The gateway routes the request through a device on a residential network — typically a device where the owner has installed software that shares their bandwidth

3. The destination website receives a request originating from a genuine residential IP address

4. The response travels back through the same path

ASN ownership — residential IPs belong to consumer ISPs. WHOIS lookups return ISP names, not hosting companies.

IP allocation patterns — residential IPs are dynamically assigned via DHCP by ISPs. The same household may have a different IP after a router restart. This dynamic allocation pattern is detectable and actually helps residential proxies appear legitimate — static IPs are unusual for consumer connections.

Geographic accuracy — residential IPs map accurately to physical locations because ISPs assign IPs regionally. Datacenter IPs can be geographically inconsistent because providers may route traffic through distant PoPs.

Latency characteristics — residential connections have the variable latency profile of real consumer internet: slightly higher average latency, more jitter, and patterns consistent with last-mile infrastructure like DSL, cable, or fiber to a home.

How Websites Detect Proxy Type

Modern anti-bot and fraud detection systems don't just check an IP address — they score it across multiple dimensions simultaneously.

ASN-Based Detection

The first and most fundamental check is ASN classification. Every IP address belongs to an Autonomous System, and every AS has a registered organization. Detection systems maintain databases that classify ASNs as:

• Consumer ISPs (residential)

• Mobile carriers (residential/mobile)

• Hosting providers (datacenter)

• Content delivery networks

• Corporate networks

• Known proxy or VPN providers

A request coming from an IP in a hosting provider's ASN is immediately flagged as high-risk regardless of what the IP itself has done previously. This is why simply rotating datacenter IPs doesn't solve detection — the entire IP range is classified by ASN.

Services like IPinfo, MaxMind, and ip-api.com provide ASN classification as a commercial API. Most major platforms integrate at least one of these.

IP Reputation Scoring

Beyond ASN classification, IPs accumulate reputation scores based on historical behavior across multiple platforms.

Shared abuse history — datacenter IPs are reused across many customers. An IP that was used for spam or credential stuffing three months ago carries that history even when assigned to a new customer.

Request volume anomalies — a residential IP that suddenly sends thousands of requests per hour is anomalous. Detection systems track per-IP request rates across their network, not just per-session.

Cross-platform signals — fraud detection companies aggregate signals across many websites. An IP seen on 50 different sites in an hour, even for legitimate-looking requests, scores differently than an IP that visits two or three sites in the same period.

Honeypot exposure — some detection systems operate honeypot URLs that are invisible to human users but accessible to automated scrapers. An IP that hits a honeypot is flagged network-wide.

Behavioral Signals

IP classification is only one layer. Detection systems also analyze behavioral patterns that don't depend on the IP at all:

TLS fingerprinting — the TLS handshake contains information about the client's cipher suite preferences, extension ordering, and supported protocol versions. Different HTTP clients (curl, Python requests, Go's net/http, a real browser) produce detectably different TLS fingerprints. JA3 and JA4 fingerprinting can identify the underlying HTTP library even when the User-Agent header claims to be Chrome.

HTTP/2 fingerprinting — similar to TLS fingerprinting, HTTP/2 clients have characteristic patterns in their SETTINGS frames, window sizes, and header ordering. A request claiming to be Chrome but with the HTTP/2 fingerprint of a Go HTTP client is inconsistent.

Timing patterns — human browsing has natural variation in timing. Requests that arrive in perfectly regular intervals, or that have zero think time between page loads, are statistically anomalous.

JavaScript execution — browser-based detection runs JavaScript to probe the environment. It checks for properties like navigator.webdriver, analyzes canvas rendering, checks WebGL renderer strings, tests audio context output, and probes dozens of other browser APIs. A client that doesn't execute JavaScript at all is immediately identifiable as non-browser.

When Each Type Fails

Datacenter proxies fail when:

• The destination platform uses ASN-based blocking (blocks entire hosting provider ranges)

• The IP has accumulated abuse history from previous tenants

• The platform cross-references against commercial IP intelligence databases

• TLS or HTTP fingerprinting reveals a non-browser client

Residential proxies fail when:

• The specific IP has been previously flagged on that platform

• Request rates are anomalous for a residential connection

• Behavioral signals (TLS fingerprint, JavaScript probe results) are inconsistent with a real browser

• The residential proxy network itself has been identified and blocklisted

Neither proxy type is a complete solution in isolation. Detection systems have moved beyond IP classification to multi-signal scoring that weighs IP type, IP history, TLS fingerprint, browser behavior, and request patterns together.

Choosing the Right Tool for the Job

The practical difference comes down to the threat model of the destination:

Use datacenter proxies when:

• The destination doesn't use ASN-based blocking

• Speed and cost are the primary constraints

• IP reputation history is not a significant factor

• Volume is high enough that residential proxy cost is prohibitive

Use residential proxies when:

• The destination actively blocks datacenter IP ranges

• Geographic accuracy matters

• The use case requires appearing as a real consumer connection

• Request rates are low enough to stay within normal residential patterns

Neither works reliably when:

• The destination uses full browser fingerprinting

• JavaScript-based detection probes the client environment

• The complete request signature (TLS + HTTP/2 + behavior + IP) needs to be consistent

In those cases, the IP type is the least important variable. What matters is whether the entire stack — from TCP handshake to JavaScript execution — is consistent with a real browser on a real connection.