OS spoofing for proxies: what your TCP/IP fingerprint gives away and how to set it

There is a layer of fingerprinting below the browser, below TLS, below anything you can set in a header. It lives in the first packet of every TCP connection, it is written by the operating system rather than your code, and it has been quietly contradicting proxy users for years.

What a TCP/IP fingerprint is

When a device opens a TCP connection it sends a SYN packet. The contents of that packet are chosen by the operating system's network stack, and each OS makes slightly different choices:

• Initial TTL. Windows starts at 128, Linux and Android at 64, macOS and iOS at 64 with other tells.
• Initial window size. 65535 on one family, 64240 on another, 29200 on older Linux, and so on.
• Maximum segment size (MSS). Set from the interface MTU, and predictable per platform.
• TCP options and their order. Whether window scaling, SACK, timestamps and NOP padding appear, and in which sequence. Windows and Linux order them differently and always have.

Put those together and you get a signature that identifies the operating system with high confidence from a single packet, passively, before any HTTP request is sent. Tools like p0f have done this for twenty years. Modern bot-detection vendors do it at the edge on every connection.

Why proxy traffic has always looked like Linux

Here is the problem. When you use a proxy, the TCP connection the target sees is not from your machine. It is from the proxy server, and proxy servers run Linux. So every request you send through a datacenter or ISP proxy arrives with a Linux TCP fingerprint, no matter what your browser, your automation framework or your user agent claims.

Your headers say "Windows 10, Chrome 128". The TLS handshake says Chrome. The TCP SYN says Linux server. That contradiction is a detection signal in itself. It does not matter that the IP is clean; a Windows browser does not emit a Linux SYN, and the site knows it.

Residential and mobile proxies do not have this problem in the same way, because the exit is a real device: a home router or a phone. The fingerprint the target sees is the real one of whatever is at the end of the line. On datacenter and ISP pools, where the exit is a server, the mismatch is the default.

OS targeting on Nyxon's ISP, datacenter and IPv6 pools

The fix is to tell the gateway which operating system fingerprint to present. On Nyxon's ISP, datacenter and IPv6 pools this is a username flag, the same way country targeting is:

USERNAME-os-windows:PASSWORD@HOST:PORT

Accepted values are windows, macos, ios and android. Leave the flag off and the connection presents the default Linux stack, which is fine for targets that do not fingerprint at this layer.

A complete example against a datacenter exit, using the host and port from your plan page:

curl -x http://USERNAME-os-windows:PASSWORD@HOST:PORT -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36" https://example.com

Now the TCP layer and the user agent agree. The feature is included in the pool price; there is nothing to enable and no extra charge.

Keep every layer telling the same story

OS spoofing is not a magic switch. It fixes one contradiction, and it introduces a new one if you set it carelessly. The layers a serious target reads, from the bottom up:

1. TCP/IP fingerprint (this article): the OS of the machine opening the connection.
2. TLS fingerprint (JA3, JA4 and friends): the client library doing the handshake. Chrome, Firefox, Safari, curl, Python's ssl module and Go's crypto/tls all look different.
3. HTTP fingerprint: header order, HTTP/2 settings frames, pseudo-header order.
4. Browser fingerprint: what JavaScript can see, from canvas to fonts to screen size.
5. Behaviour: timing, mouse and scroll, navigation patterns.

If you set -os-ios and then connect with a Windows Chrome TLS fingerprint and a desktop user agent, you have made things worse, not better. The rule is boring and absolute: pick one real device profile and make every layer match it. An iPhone profile means -os-ios, a Safari mobile TLS fingerprint, a Safari mobile user agent and a mobile viewport. A Windows desktop profile means -os-windows, Chrome's TLS fingerprint, Chrome's headers and a desktop viewport.

For most people this means: use a real browser (or an anti-detect browser that emulates one faithfully), set the OS flag to match the browser's platform, and stop there.

How to verify what the target sees

You cannot see your own TCP fingerprint from inside a browser, so use a checker that reports it. Several public fingerprint test pages show the detected OS from the TCP layer alongside the TLS and user-agent readings. Load one through the proxy with and without the -os- flag and compare. The test you want to pass is not "does it say Windows" but "do all three readings agree".

If you are running your own stack, p0f on a capture of your outbound connections tells you the same thing.

When to bother

• Skip it for residential and mobile pools: the exit is a real device and already carries a real fingerprint, and the flag is not applied there.
• Skip it on targets that do not fingerprint below the browser, which is most of them. Test first.
• Use it on ISP and datacenter pools against targets with serious bot protection, in combination with a matching browser profile.
• Use it when you have already fixed headers and TLS and are still being challenged on the first request from a clean IP. That pattern is the signature of a TCP-level mismatch.

Try it on any Nyxon ISP, datacenter or IPv6 plan today; the proxy tester accepts the flag in the username like any other targeting token, and the full username syntax is on your plan page. If a specific target still refuses you after the layers agree, the live chat is happy to look at the exact request with you.