TCP fingerprinting

Four fields carry most of the signal. The hop limit starts at a value the system picks, and p0f notes that "almost all operating systems use 64, 128, or 255". Every router on the way subtracts one, so a packet that arrives with 54 started at 64 and crossed ten routers. Unix-like systems start at 64 and Windows at 128.

The segment size comes from the sending interface, so it reports the link rather than the system. The window and its scaling factor were standardised in September 2014 and differ by system and by tuning. The order of the options is the quietest signal. The standard says which options exist. It never says in what sequence they must appear, so each stack lists them its own way.

This is the part that matters for proxy work, and it depends on the arrangement. A SOCKS or HTTP proxy opens its own connection to the target on your behalf, a design written down in March 1996. Your own handshake ends at the proxy, and the target reads the proxy's machine.

A VPN does not work that way. It carries your packets inside a tunnel, so your own system still performs the handshake with the target and the target still reads your system. The tunnel takes bytes from each packet, which is why the segment size drops and gives the arrangement away.

On 20 September 2026 we asked 2,400 proxies from our own free list to open a connection to our own server. We captured the SYN that arrived from each of them. Of the 2,400, some 461 completed the request, and 594 distinct proxies reached us. Of those, 588, or 99.0 percent, started the hop limit at 64. Four started at 128, and all four also used the Windows option order, so the two signals agreed every time.

The segment size is the more interesting column. The plain Ethernet value of 1460 came from 72.2 percent of them. The other 27.8 percent sent something smaller, which means their traffic is encapsulated somewhere. That is more common on the addresses our list does not mark as datacenter, 30.9 percent against 18.1 percent. Altogether the 594 proxies produced 112 distinct fingerprints, 72 of which appeared exactly once.

In the same minutes, 5,693 other connections arrived at that server from 2,504 addresses, carrying 53 distinct fingerprints. One of them covered 2,808 of the connections, because our site sits behind a content delivery network and those packets come from its machines. Our origin reads the network's stack and never sees a visitor's.

One more result is worth admitting. Our own server sends window 64240, segment size 1460, scale 7 and the Unix option order. That is exactly the fingerprint 215 of the 594 proxies sent. At this layer a rented server and a free proxy are the same shape. What matters is whether that shape matches what the client claims to be.

The contradiction is the whole detection. A request that announces Chrome on Windows, while its SYN describes a Linux server, has answered the question already. Our numbers show how likely that is: 99 percent of free proxies present a Unix stack. A Windows claim through one of them is therefore a mismatch.

You cannot correct this from your own machine, because the packet is the exit's. A Linux host can be told to use a different segment size for a route, but no proxy service does that per customer. The honest options are to claim what the exit actually is, or to use an exit whose machine really matches the claim.