Residential proxies are detected by correlating signals that a rotating IP cannot hide: attribution of the exit address to a known proxy pool, the gap between server-observed TCP and TLS round-trip times, fingerprint and telemetry mismatches, and per-IP behaviour over time. No single check is reliable — the stack is.
What you are actually detecting
A residential proxy network is a backconnect system: the client authenticates to a gateway, the gateway forwards the request to an exit node sitting on a consumer ISP or mobile connection, and the exit node makes the final request to your server. From your logs, the request looks like a home broadband user in the right city. That is the entire product. If you want the mechanics from the operator side, our residential proxies page covers rotation, sticky sessions and country targeting in detail.
Exit nodes are recruited in several ways. Some are consenting bandwidth-sharing participants. Many are not: the FBI's public service announcement on residential proxy networks lists embedded mobile SDKs, free VPN apps with buried terms of service, malware bundled with pirated content, and compromised IoT devices such as streaming sticks and digital picture frames (FBI, 2026). That mix matters for detection because it means a proxied IP is usually also a real household IP with real users behind it.
Scale sets the difficulty. Academic measurement work has enumerated 6.18 million unique residential proxy IPs across more than 230 countries and 52,000 ISPs in a four-month crawl, and a separate Chinese-provider study found 91% of exit-node lifetimes lasted under 10 days (Barnes and Vezich Tamayo, Stanford CS244C). Pools that large and that transient make static blocklists structurally hopeless.
Five signal families, ranked by what they actually buy you
1. IP attribution and ASN context
Commercial intelligence feeds map addresses to known proxy services, and separate dynamic residential pools from ISP/static allocations, mobile carriers and datacenter ranges. One vendor reports observing 230 million-plus anonymised IPs per 90 days and attributing traffic across 1,000-plus VPN and proxy services (Spur). Attribution is the cheapest signal to deploy and the fastest to go stale — the pool churns weekly.
2. Network timing
The strongest single-request signal. A proxied connection creates two TCP sessions while preserving one end-to-end TLS session, so the two round-trip measurements diverge at the destination. Details below.
3. Fingerprint and telemetry mismatch
Browser locale, timezone, accept-language and font stack versus IP geolocation. TLS ClientHello and HTTP/2 frame ordering versus the claimed user agent. Session fingerprints changing while a login session persists. Impossible travel inside one authenticated session. These catch the automation, not the proxy — which is usually what you want.
4. Per-IP behaviour over time
Cloudflare's write-up on residential proxy bot detection describes exit nodes showing distinct behaviour during peak activity windows, and notes that over a 24-hour sample roughly four out of five requests from active residential proxy IPs were ordinary direct traffic from real users on those networks (Cloudflare). That ratio is the whole argument against blocking the IP rather than scoring the request.
5. Machine learning over aggregates
Production systems combine single-request features, per-fingerprint global aggregates and high-cardinality per-IP aggregates in a gradient-boosted model, then validate against customer-reported misses. Cloudflare states its bot detection model scores an average of over 46 million HTTP requests per second. You cannot rebuild that from a lookup API, but you can copy the shape: features at three cardinalities, labels from your own confirmed abuse.
What does not work
Country blocks, ASN blocks, IP blocklists and per-IP rate limits — used alone. Every one of them is defeated by rotation, and each one produces collateral damage on residential networks where a single device is running a proxy SDK.
| Signal | Catches | False-positive risk | Evasion difficulty for the proxy |
|---|---|---|---|
| Proxy/VPN IP attribution | Known pools, static residential, VPN exits | Medium (shared household IPs) | Low — rotate to unlisted nodes |
| TCP vs TLS RTT gap | Any relay that forwards TLS untouched | Medium (satellite, PEPs, CGNAT) | Medium — requires per-flow ACK timing control |
| Fingerprint/telemetry mismatch | Automation and geo-spoofing | Low | Medium-high — full stack consistency needed |
| Per-IP behavioural aggregates | High-activity exit nodes | High if used to block | Low — slow the request rate down |
| ML over combined features | Campaign-level patterns | Low-medium, tunable by score | High — but degrades without retraining |
Timing: the TCP versus TLS round-trip gap
In a direct connection, the TCP handshake and the TLS handshake happen between the same two endpoints, so both round-trip estimates reflect the same path. Through a backconnect proxy, your server completes TCP with the residential exit node while the TLS records are relayed from the original client without being terminated. The server-observed TCP RTT measures the short exit-to-server hop; the TLS timing measures the long client-to-server path. The published BADPASS technique classifies a connection as proxied when the difference exceeds an empirically chosen 50 ms threshold, with low false positive and false negative rates in multi-region measurement (Stanford CS244C, citing Chiapponi et al.).
You can prototype this from a packet capture on your own edge before buying anything. The commands below are illustrative — field names vary by capture setup:
# TCP handshake RTT per stream (SYN-ACK to completing ACK)
tshark -r edge.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==1' \
-T fields -e tcp.stream -e tcp.analysis.ack_rtt
# TLS handshake timing per stream (server flight to client response)
tshark -r edge.pcap -Y 'tls.handshake' \
-T fields -e tcp.stream -e frame.time_relative -e tls.handshake.type
# join on tcp.stream, compute delta = rtt_tls - rtt_tcp, flag > 50msKnow the failure modes before you ship it. Regions on satellite links or behind performance-enhancing proxies show high latency on almost everything, which is exactly why Cloudflare reported abandoning latency as a standalone signal. And the same Stanford work demonstrated a working evasion: a relay that measures the client round trip with a pre-flight probe, then delays the final outbound ACK by that amount, suppresses the timing gap without terminating TLS. Treat the RTT delta as a strong feature, never as a verdict.
How to detect residential proxy IP addresses: a working pipeline
- Define the risk surface first. Login, signup, checkout, coupon redemption and password reset deserve scrutiny. Static content does not. Detection you apply everywhere is detection you will be forced to tune down.
- Log the raw material. Per request: TLS ClientHello fingerprint, HTTP/2 settings order, header order, timing deltas, ASN, geolocation, and a stable client hint bundle. If you are not storing fingerprints, no amount of IP data will save you.
- Add attribution as an enrichment, not a gate. Query a proxy/VPN intelligence source, store the answer with a timestamp, and score it. Free lookup endpoints are useful for spot checks; they will not have current dynamic pool coverage.
- Compute aggregates at three cardinalities. Per IP, per fingerprint, per ASN — over rolling windows. Campaign detection lives here: a spike towards one sensitive endpoint from hundreds of unrelated residential ASNs sharing one fingerprint is unmistakable.
- Score, then act by tier. Elevated score triggers a challenge, step-up authentication or a tighter rate limit. Reserve outright blocks for confirmed, high-confidence cases.
- Label and retrain. Feed confirmed fraud, chargebacks and analyst decisions back as labels. Measure false positives explicitly, per country and per network type.
One number to keep in view: in comparative analysis, 86% of residential proxy IPs appeared on threat denylists, yet only 0.27% were tied to verified attacks, versus 6.97% for open proxies (Stanford CS244C). Presence on a list is a weak prior. Residential proxy abuse tends to be low-and-slow, which is exactly what per-request blocking is worst at catching.
Residential proxy vs VPN: why a generic VPN detection tool misses
A VPN concentrates all its subscribers behind a small set of provider-owned exit servers, usually in hosting ASNs, often with announced netblocks and predictable service fingerprints. That makes VPN exits enumerable — which is why a free "check if IP is VPN or proxy" lookup is reasonably good at VPNs and poor at residential pools.
Residential proxies invert every one of those properties: consumer ISP ranges, real household geolocation, organic churn, and legitimate user traffic sharing the same address. Mobile proxies are harder still, because carrier-grade NAT puts thousands of subscribers behind one public IP, so blocking is near-guaranteed collateral damage. ISP proxies sit in the odd middle: registered to a consumer ISP but hosted in a datacenter, so they can be flagged by careful ASN-plus-hosting analysis where dynamic residential cannot.
If you are on the collection side, read detection as a cost model
Everything above is the reason "just buy the best residential proxies and run your own scraper" quietly gets expensive. You are not paying for bandwidth; you are paying for retries, headless-browser fingerprint maintenance, and engineering time spent chasing whichever signal changed this month. Bandwidth-metered proxies charge you for failed attempts too.
Do the arithmetic on a concrete job — 100,000 product pages. Self-hosted with rendering, at roughly 500 KB of transfer per page, is about 50 GB: $40 at $0.80/GB on top of the browser fleet, and more once you count the third of requests that get challenged and retried. The same 100,000 pages through our Web Scraping API is $20 at $0.0002 per page, or $100 with JS rendering at $0.001 — and failures are billed at zero, so the retry tax is on us, not you. Async crawl and batch jobs are charged up front on requested volume and auto-refund the unfetched share.
curl https://api.quanticdata.io/v1/scrape \
-H "Authorization: Bearer $QD_API_KEY" \
-d '{ "url": "https://example.com" }'
{ "success": true,
"data": { "markdown": "# Example Domain\n…" },
"usage": { "cost_usd": 0.0002 },
"retries": [ { "attempt": 1, "outcome": "ok" } ] }For agent workflows the same endpoints are exposed as tools through our MCP server, so a model calls search, scrape, map or crawl directly and gets one predictable envelope back instead of a pile of proxy configuration. If you are still mapping out what you need to collect, what web data actually is is a useful starting point.
False positives, ethics and the legal line
The hard constraint in residential proxy detection is that the address usually belongs to someone innocent. Block the IP and you may be blocking a household whose smart TV joined a proxy network without informed consent. Score the request instead, act on the session, and keep a documented appeal path for users you challenge.
On the collection side, the ethical question is where exit nodes come from. Pools built on malware or hidden SDK enrolment implicate you in the abuse the FBI advisory describes; that is one reason our residential network uses consenting, ethically sourced peers. Detection and collection are two views of one system, and both are improved by knowing how the other works.
This article is technical guidance, not legal advice. Proxy use, automated access and traffic inspection are governed by contract terms, computer-misuse statutes and data protection law that vary by jurisdiction — consult qualified counsel before deploying either detection or collection at scale.