Caught at 99%: The 50-Millisecond Crack That Exposes Even the Best Residential Proxies

We resell hellworld.io’s full lineup — 14 residential brands, 3 mobile pools, Static ISP and 2 unlimited tiers. So when we write about residential-proxy detection, the framing has to be honest: every customer of ours who relies on residential exits has a real interest in this paper. We don’t pretend otherwise. The point of this article isn’t to scare anyone away from residential proxies. It’s to explain a specific server-side detection method that’s quietly accurate, and what it does and doesn’t mean for the way these tools get used in 2026.

For most teams running scrapers, sneaker bots, ad verification or pricing intelligence, residential proxies feel like the safest bet. The source IP looks like a normal home broadband subscriber on a normal ISP — not a datacenter, not a known proxy provider — and that’s exactly what defeats most IP-reputation lists.

Until it doesn’t. A 2022 academic paper, BADPASS: Bots Taking ADvantage of Proxy as a Service (ISPEC 2022, by researchers from EURECOM, KAUST and Amadeus), showed that you can identify residential-proxy connections with 99.01% accuracy using a single trick: compare the TCP RTT and the TLS RTT of the same HTTPS connection, server-side, during the handshake itself.

No JavaScript. No IP reputation database. No fingerprinting library. Just two timing numbers the server already has.

If you operate a high-value site that’s being scraped, this is one of the cleanest detection methods published. If you run scrapers, it’s worth understanding because the providers you trust today probably all have this problem.

Why Residential Proxies Got So Hard to Block

Datacenter proxies are easy to filter. AWS, GCP, Azure, DigitalOcean — the ASNs, IP blocks, hostname patterns, TLS stack signatures and historical abuse data are all well-known. Most commercial bot-detection services flag traffic from these ranges automatically.

Residential proxies are a different beast. The exit IP is a real home broadband line, a mobile device, or a piece of consumer hardware that’s been recruited into the proxy provider’s pool (sometimes through an SDK bundled with a free app). To the destination server, it looks indistinguishable from a regular paying customer in Ohio, Tokyo or São Paulo.

This is why e-commerce, ticketing, travel and airline platforms are constantly losing the cat-and-mouse game with scrapers — and not coincidentally, one of the paper’s authors works at Amadeus, the global travel IT infrastructure giant. These aren’t ivory-tower researchers theorizing about “what if bots used proxies.” They’ve been getting hammered by exactly that for years.

Traditional anti-bot detection leans heavily on IP reputation, request rate, device fingerprint and behavior trails. Residential proxies blur the IP-reputation signal almost completely. The natural question becomes: can the server figure out it’s a proxy without looking at the IP at all — just from the connection itself?

The paper answers: yes, by measuring two RTTs.

The Core Insight: Residential Proxies Split TCP, but Not TLS

This is the cleanest part of the paper.

When a user connects directly to a website, the picture is simple. The browser opens a TCP connection straight to the server, and then negotiates TLS over that TCP connection. The TCP three-way handshake and the TLS handshake both happen between the same two endpoints. The server-measured TCP round-trip time and TLS round-trip time should be nearly identical — they’re measuring the same path.

Residential proxies don’t work that way. Most operate in a “backconnect” architecture: the client connects to the provider’s superproxy, which then schedules a residential gateway, and the gateway opens the TCP connection to the destination server. From the server’s perspective, the TCP peer is the gateway — not the original client.

But HTTPS proxies typically forward the TLS session as an opaque tunnel rather than terminating and re-establishing it. That means the TLS session is still negotiated end-to-end between the original client and the destination server. The gateway just shuffles encrypted bytes.

This produces a structural mismatch:

• TCP RTT measures the distance from the gateway to the server.
• TLS RTT measures the distance from the real client through the superproxy and gateway to the server.

For a direct connection, these two numbers are the same. For a residential-proxy connection, the TLS RTT is almost always meaningfully larger than the TCP RTT, because the TLS handshake packets travel the entire proxy chain while the TCP handshake doesn’t.

In one sentence: the residential proxy splits the transport layer in two, but TLS still pretends to be end-to-end, and that lie has a measurable latency cost.

Why This Detection Method Is Especially Dangerous

Server-side timing measurements have four properties that make them very inconvenient for proxy users:

1. It runs entirely on the server. No client cooperation, no consent dialog, no JavaScript execution. If you can capture packet timing on the load balancer or origin, you can implement it.

2. JavaScript-blocking doesn’t help. A lot of bot detection ships browser-side probes — WebRTC, localhost connection attempts, performance-API quirks. Sophisticated bots disable JavaScript, run headless, or strip these probes. This method bypasses all of that, because the relevant signal is captured before any HTML is delivered.

3. It doesn’t care about IP reputation. Residential IPs rotate constantly. New ones appear daily. Any detection based on labeling specific IPs as bad is in a perpetual losing race. This method ignores the IP entirely — it only looks at connection structure.

4. Detection happens before the response. The RTT gap shows up during the TLS handshake itself. You can decide to refuse, slow-walk, or rate-limit a connection before serving the first byte of HTML. From a defense perspective, that’s huge — you’re not letting the scraper exfiltrate anything while you make up your mind.

Inside the Experiment

The authors weren’t satisfied with theory. They built a global testbed to prove the gap is real and consistent:

• 4 commercial residential providers purchased: Bright Data (formerly Luminati), Oxylabs, ProxyRack and Smartproxy. 40–50 GB of bandwidth per provider per month.
• 22 servers distributed worldwide via Amazon Lightsail (16) and Azure (6). Locations included India, Australia, Japan, Germany, Ireland, Canada, US East/West, South Africa, UAE and Brazil.
• Each server acted as both client and server. From every server, the team sent HTTPS GETs to every other server: once direct, and once through each of the four proxy providers — five paths per pair.
• The campaign ran 110 days (January 12 to May 1, 2022). The server-side TLS version alternated daily between TLS 1.2 and TLS 1.3, so the dataset covers both.

After culling broken captures, scanner noise and brief downtime, they kept 92,712,461 complete connection records — about 95% of the nearly 98 million connections attempted. That’s a serious dataset.

How the Two RTTs Are Measured

The TCP RTT is straightforward. The server sends SYN-ACK, and waits for the client’s final ACK. The time between those two is the TCP RTT as seen by the server. On a direct connection, that’s client-to-server. On a residential-proxy connection, that’s gateway-to-server.

The TLS RTT is slightly trickier. The authors pick a pair of TLS handshake records where the server has sent something it must wait for the client to respond to before proceeding. For TLS 1.2 that’s around ServerHelloDone → ClientKeyExchange; for TLS 1.3 it’s after ServerHello and the encrypted handshake messages → the client’s change_cipher_spec / second flight. The exact records aren’t the point — the principle is “find a point where the server emits and must wait for a reply before continuing.”

Regardless of TLS version, this round-trip travels the full TLS path: client → superproxy → gateway → server. On a direct connection, that’s just client → server.

Then you compute one number: TLS RTT − TCP RTT. Small means direct. Persistently large means there’s an extra hop the TCP layer can’t see.

The Results Are Brutal

The paper’s results show the distribution of TLS RTT − TCP RTT for direct vs. proxied connections, and the two populations barely overlap.

• 97% of direct connections show a difference of ≤ 20 ms.
• The same axis on the proxied connections has to be drawn 100× wider — 0 to 2000 ms — because the proxied gaps are routinely hundreds of milliseconds.

Some connections show a negative difference (TCP RTT bigger than TLS RTT). This happens when the SYN-ACK or final ACK happens to be delayed by jitter while subsequent TLS packets aren’t. It’s rare:

• Direct: 2.9% negative
• Bright Data: 0.9%
• Oxylabs: 1.8%
• ProxyRack: 0.2%
• Smartproxy: 1.4%

Jitter exists. It doesn’t destroy the separability.

50 ms: The Threshold That Catches 99%

The authors landed on 50 ms as a practical threshold. They picked it by separately analyzing how much per-connection RTT naturally jitters: in 53% of connections, the max-minus-min RTT swing within a single connection is ≤ 50 ms. So 50 ms accommodates normal jitter while still being far below the typical proxy gap.

With that rule — “if TLS RTT − TCP RTT > 50 ms, flag as residential proxy” — the results are:

Metric	Value
False positive rate	0.04%
False negative rate	1.93%
Overall accuracy	99.01%

A 0.04% false-positive rate means almost no legitimate users get caught in the dragnet — critical, because misclassifying real customers is far more expensive than missing a few scrapers. A 1.93% false-negative rate means almost no proxied traffic slips past.

Even the Worst Case Is 92.78%

Suspicious researchers will object: what if the very first TCP RTT measurement happens to be the maximum on that connection? That would inflate TCP RTT, shrink the gap, and let some proxied traffic through.

The authors stress-tested that worst case. About 29% of connections have their first TCP RTT equal to the connection’s maximum. If you assume every single one of those is unluckily skewed, you’d expect the worst possible detection performance. With the same 50 ms threshold:

• False positive: 0.01%
• False negative: 9.68%
• Accuracy: 92.78%

Even under pessimistic jitter assumptions, this is still a very strong classifier. Real production deployments wouldn’t see worst-case-everywhere; reality sits much closer to 99% than to 92%.

“What If the Gateway Is Close to the Server?”

The natural countermove for a proxy provider is to route the gateway as close as possible to the destination, shrinking the gateway-to-server TCP RTT. If that hop is tiny, won’t the gap collapse?

The authors checked exactly the scenarios where this should hurt most. For Bright Data, with many gateways in the ARIN/RIPE regions, they isolated Virginia ↔ Virginia connections. For Oxylabs and Smartproxy, with heavy LACNIC presence, they looked at intra-Brazil routes. For ProxyRack, with significant AFRINIC pools, they used intra-South-Africa.

The results held. With the 50 ms threshold, the false-negative rate actually dropped to about 0.78% in some of these “best chance to evade” subsets — because even when the gateway is local, the client and superproxy aren’t, and the TLS path still spans the whole chain.

A theoretical attacker who controlled the client, superproxy, gateway and server all in the same metro area could collapse the gap. Commercial residential-proxy scheduling doesn’t work that way; the rotation logic doesn’t care about geographic affinity to the target.

Important: This Method Doesn’t Catch VPNs or NAT

A careful read of the paper is important here. The detection target is specifically: connections that break the TCP layer end-to-end but preserve the TLS layer end-to-end. Backconnect residential proxies fit that pattern. So does some SSH-style forwarding.

Standard NAT, IPsec VPN, WireGuard and similar VPN technologies usually don’t terminate the TCP connection. They rewrite IPs, encapsulate packets, route them through tunnels — but the TCP session is still end-to-end between the original client and the server. As a result, TCP RTT and TLS RTT line up the same way they do on a direct connection.

If you’re trying to detect general “is this user behind a tunnel,” this method is the wrong tool. For VPN and NAT detection, you need MTU analysis, IP reputation, latency baselining or protocol fingerprinting.

But for the specific commercial residential-proxy market — which is the one disproportionately responsible for credential stuffing, scalping, and large-scale scraping — this method is dangerously effective.

Caveats Worth Knowing

The paper isn’t a USENIX/CCS/NDSS/IMC top-tier publication; ISPEC is a respectable but second-tier security venue. The experiments use the authors’ own client and server infrastructure, not production website traffic from a real defender. The detection target is narrow — TCP-splitting, TLS-pass-through residential proxies. And if a provider redesigns its architecture (for example, by terminating TLS at the gateway), the detection signal could shrink.

None of these caveats invalidate the result. They just tell you the method is not a silver bullet for every kind of proxy traffic — only the most popular one.

What This Means If You’re Defending a Site

If you run a target site, this is one of the highest-yield, lowest-cost detection methods you can add. The implementation is mostly: capture timestamps on SYN-ACK/ACK and on the chosen TLS handshake records, compute the gap, threshold at 50 ms, and feed it into your existing risk score.

You don’t have to act on it alone — combining it with rate-limiting, device fingerprinting and behavioral signals reduces false positives further. But as one signal among several, “TLS RTT minus TCP RTT exceeds 50 ms” is high-signal, near-impossible-to-fake at the client layer, and observable on every TLS connection.

For context on what those other detection layers look like in 2026, our Anti-Bot Landscape 2026 field guide breaks down the six anti-bot vendors most likely to be sitting in front of any target you’re trying to reach.

What This Means If You’re Using Residential Proxies

The uncomfortable truth: every commercial residential-proxy provider following the standard backconnect-with-TLS-pass-through architecture is detectable by this method. That includes nearly every premium provider, including the four tested.

The mitigation paths are limited:

• Architectural change at the provider. A provider could terminate TLS at the gateway and re-establish it to the target, removing the structural asymmetry. This requires the proxy to act as a man-in-the-middle, which breaks certificate validation and is not a thing serious users would accept.
• Co-locate the entire chain. If client, superproxy, gateway and server are in the same metro, the gap shrinks. Commercial pool-based scheduling doesn’t allow this.
• Use connection types this method can’t see. VPN and NAT-based exits aren’t affected. Trade-offs apply — they have their own detection vectors.
• Diversify connection types and accept some traffic will get flagged. This is the realistic answer for most teams. Not every request needs a residential exit. Mix static ISP, mobile and residential strategically, lower per-connection request rates, and design the workflow so that flagged traffic costs you a retry rather than a permanent block.

This is not a “residential proxies are dead” article. They still work. They still bypass most current production defenses, because most production defenses don’t yet implement RTT-based detection. The point is that the structural advantage of residential proxies — looking exactly like a real user — has a measurable, fundamental crack that anyone serious about defense can exploit.

If you want to think harder about when residential makes sense versus mobile, ISP or unlimited, the Proxy Tier Decision Tree walks through the trade-offs by use case. And for raw performance numbers across providers, 14 Brands Tested is the most current benchmark we’ve published.

Anyone building serious anti-scrape infrastructure in 2026 onwards is going to learn this trick. Plan accordingly.

---

Reference: Casino, F., Patsakis, C., Lecharlier, B., & Ricci, V. (2022). BADPASS: Bots Taking ADvantage of Proxy as a Service. ISPEC 2022.