Two round trips on one connection
Every TCP connection starts with SYN, SYN-ACK, ACK. The server can time the gap between its SYN-ACK and the ACK, which is the round trip to whatever opened the connection. Through an HTTP CONNECT proxy, a SOCKS proxy or a residential proxy network, the proxy opens a new TCP connection to the server, so the handshake only measures the last hop.
An echo is different. If the page sends a timestamp over a WebSocket and the server sends it back, the reply has to travel all the way to the code that sent it: browser to proxy, proxy to exit, exit to server, and back. The application round trip includes every hop. Subtract the TCP round trip and what is left is the hidden part of the path.
Since late October 2026 at least one widely deployed challenge widget runs this probe: it opens a WebSocket to its own host, sends String(performance.now()) and records six echoes with a 500 ms budget. What the server then does with the values is not visible from outside, but the pattern matches the published technique.
What the numbers look like
Published measurements:
- CalcuLatency (USENIX Security 2024) compared a WebSocket round trip from the page with the TCP handshake. At a 50 ms threshold it reported 0.95% false positives and 2.9% false negatives. Two thirds of the VPNs it missed were within about 1,050 km of the user.
- BADPASS (ISPEC 2022) compared TLS and TCP round trips over 92.7 million connections through four residential proxy providers. 97% of direct connections differed by 20 ms or less; at 50 ms the false-positive rate was 0.04%.
An October 2026 test from Amsterdam with Chrome 156 and a public echo server gave:
| Path | Echo round trip | WebSocket open |
|---|---|---|
| Direct | about 12-18 ms | 47-62 ms |
| Residential exit, same country | 48-64 ms (about +38 ms) | about 270 ms |
| Exit in the US | 400-470 ms | 1.6-1.8 s |
The server saw a home IP in every case. With a 500 ms budget, the direct run finishes all six echoes, the same-country exit runs out after about four, and the US exit times out before the socket opens. Note the limit: the same-country exit added 38 ms, under the 50 ms line. Latency catches distance, not proxies as such.
What follows for proxy setups
No browser setting changes a round trip, and the TCP side is measured on the server, out of reach of the page. The practical answers are about network design:
- Keep the browser near the exit. Run the browser in or near the exit's region, so the hidden path is short.
- Keep the chain short. Every extra hop (a gateway, a second proxy, a tunnel to a remote worker) adds to the echo but not to the handshake.
- Make the rest agree. Timezone, language and the WebRTC path have to fit the exit too, or the latency gap is only one of several contradictions. See timezone and IP mismatch.
This is a placement problem more than a configuration problem, which is why a managed web data API that runs browsers next to its proxy exits avoids it, while a browser on one continent behind an exit on another cannot fix it from inside the page.
