Get started

TCP Fingerprints and Handshake Timing: How OS and Latency Emulation Work

· 7 min read

A clean residential IP gets a connection past the first check most protected sites run, the lookup of who owns the address. It does not get it past the next ones. Anti-bot systems also look at the connection itself: how its TCP handshake was put together, and how long that handshake took compared with everything after it. Both are measured passively, on every connection, and both can give a proxy away even when the address is spotless.

This article explains where those two signals come from, what the published research says about them, and what OS and latency emulation change.

Why a proxy shows up in the handshake

When you browse through a proxy, there are two connections rather than one. Your device opens a TCP connection to the proxy, and the proxy opens a second TCP connection to the website. The encrypted session, on the other hand, runs end to end: with HTTPS through an HTTP CONNECT or SOCKS5 proxy, the TLS handshake and every request inside it come from your browser and reach the site untouched.

The site therefore receives two layers from two different machines. TLS and HTTP describe your browser, while the TCP connection underneath describes the proxy server. Any disagreement between the two is a sign that something sits in the middle, and the two checks below look for exactly that.

The TCP fingerprint

The first packet of every TCP connection, the SYN, carries a handful of values that each operating system's network stack sets in its own way:

  • Initial TTL. Each system starts its packets at a value of its own. The site sees it lowered by the number of hops along the way, but the starting point is easy to infer.
  • Window size and window scale. How much data the sender is willing to receive before acknowledging it, and the multiplier applied to that number.
  • Maximum segment size. 1460 bytes on an ordinary Ethernet path. Lower values point to the overhead of a tunnel or VPN.
  • TCP options and their order. Which options are sent, and in what order, differs from one system to the next.

Reading an operating system from these values is far from new. Michal Zalewski's p0f has done it passively since the early 2000s, and its signature format still underlies OS detection in firewalls such as OpenBSD's pf. More recently, FoxIO's JA4T packed the same fields into a compact fingerprint that sits alongside JA4 for TLS and JA4H for HTTP, which makes comparing the layers of a single connection straightforward.

That comparison is where proxies fail. A browser announcing Windows in its user agent, with a TLS fingerprint to match, whose connection arrives with the TTL and option layout of a Linux server, is not a person at home on a Windows laptop. No single field is decisive, but the mismatch is cheap to detect and difficult to explain away.

Handshake timing

The second signal is a matter of time. A website can measure two round trips on the same connection:

  • The TCP round trip, from the moment it sends its SYN-ACK to the moment the final ACK of the handshake arrives. Behind a proxy, that ACK comes from the proxy server.
  • The TLS or application round trip, from a message the site sends inside the encrypted session to the reply. Behind a proxy, that reply has to travel all the way to your device and back.

On a direct connection, the two are close. On a proxied one, the TCP round trip only covers the distance to the proxy, while the TLS round trip covers the distance to you. With a proxy in Ashburn and a user in Europe, the site can see a handshake answered in a couple of milliseconds and requests that take more than a hundred.

This gap has been studied in detail. Chiapponi and colleagues at EURECOM and Amadeus proposed it in BADPASS as a way for servers to spot scraping bots behind residential proxies, comparing TCP and TLS round trips across a months-long measurement campaign. Xue, Stanley, Kumar and Ensafi at the University of Michigan then showed at NDSS 2025 that the same misalignment fingerprints proxy traffic regardless of the protocol in use, since every proxy that splits the transport layer while relaying the application layer produces it.

FoxIO's JA4L measures the TCP side of this from the handshake alone, in microseconds, and turns it into an upper bound on the distance between the two ends, using the speed of light in fibre. A website that knows how far away the other end of the TCP connection is, and how long the application takes to answer, has everything it needs to notice that the two belong to different machines.

What OS emulation does

OS emulation makes the proxy's side of the connection look like the system your browser claims to be. When it is set to Windows, the SYN the website receives starts with Windows' TTL and carries its window size and option layout. The same goes for macOS, Android and iOS.

The setting only works when it agrees with the rest of the connection. Pick the system your browser or anti-detect profile presents in its user agent, and keep the two aligned when you change one. A Windows handshake under a macOS browser is just as inconsistent as a Linux one.

What latency emulation does

Latency emulation closes the timing gap from the proxy's side. Instead of acknowledging the website's SYN-ACK immediately, the proxy holds its ACK back for about as long as the round trip to your device takes. The website then measures a handshake that matches the rest of the connection, as it would if your device were answering it directly.

The delay can be applied in two ways:

  • Partial delays only the first ACK of each connection. The handshake matches, and transfers keep their full speed afterwards. It is the right choice for most uses.
  • Full delays every ACK, so round trips measured later in the connection match as well. It is more thorough, at the cost of slower downloads.

Holding back acknowledgements is the evasion that the research itself points to. A Stanford student project on residential proxy detection reached the same conclusion, showing that a provider can defeat the TCP and TLS round-trip comparison by deliberately delaying TCP acknowledgements.

What emulation does not change

Emulation brings the transport layer in line with everything above it. It does not make up for problems higher in the stack:

  • Your browser's own fingerprint, from its TLS handshake to canvas and fonts, reaches the site exactly as your browser produces it. An anti-detect profile that is inconsistent on its own stays inconsistent.
  • Behaviour still counts. Request rates, navigation patterns and account history are judged on their own merits, as covered in our article on fraud scores.
  • Detection keeps moving. At NDSS 2026, Ali and colleagues showed that a simple scheduling attack cut round-trip based detection from 99% recall to 8%, and proposed flow-correlation features aimed at proxyware devices relaying traffic for others. Timing is one signal among several, and it is best treated that way.

Checking the result

Several public tools display the TCP/IP fingerprint of an incoming connection next to the browser's user agent. Visit one through the proxy with emulation off, then on, and the guessed system should switch from Linux to the one you picked. The rest of a proxy check, from the exit IP to DNS leaks, is described in how to test a proxy.

What we deliver

Every Leastslow package comes with OS emulation for Windows, macOS, Android and iOS, and latency emulation in partial or full mode, both set per package from the dashboard. They sit on top of static residential IPs on Frontier's consumer network, hand picked at a fraud score of zero. Pricing is on the homepage.

References

  1. Michal Zalewski, p0f v3, passive OS fingerprinting.
  2. FoxIO, JA4+ network fingerprinting, the reference implementations and specifications.
  3. John Althouse, JA4T: TCP Fingerprinting, FoxIO, 2024.
  4. John Althouse, JA4+ Network Fingerprinting, FoxIO, 2023. Introduces JA4L, latency and light distance.
  5. Elisa Chiapponi, Marc Dacier, Olivier Thonnard, Mohamed Fangar and Vincent Rigal, BADPASS: Bots Taking ADvantage of Proxy as a Service, ISPEC 2022.
  6. Diwen Xue, Robert Stanley, Piyush Kumar and Roya Ensafi, The Discriminative Power of Cross-layer RTTs in Fingerprinting Proxy Traffic, NDSS 2025.
  7. Temoor Ali, Shehel Yoosuf, Mouna Rabhi, Mashael Al-Sabah and Hao Yun, Beyond RTT: An Adversarially Robust Two-Tiered Approach For Residential Proxy Detection, NDSS 2026.
  8. Sophia Barnes and Stephanie Vezich Tamayo, Residential Proxy Detection, Stanford CS244C project report, 2026.