TCP/IP fingerprint of the proxy: OS check in 5 minutes

You have configured an anti-detect browser for Windows and Chrome, selected a clean IP, aligned the timezone and language, yet the site still prompts for a captcha or blocks the account. A common reason lies beneath the browser, at the TCP/IP level. The server sees the first connection packet (SYN), and from its fields, it can tell which operating system sent that packet. If it's a Linux proxy server, but the User-Agent claims to be Windows, the anti-bot system encounters a contradiction that cannot be resolved through headers.

The topic has ceased to be exotic. On October 13, 2026, according to Proxyway, the British provider Byteful launched an open beta for TCP/IP fingerprint spoofing for data center and ISP proxies: they can impersonate Windows, macOS, Linux, Android, and iOS. Proxyway's explanation is straightforward: anti-bot systems are increasingly looking at TCP/IP fingerprints. Below, we will explore how this check works, how to verify your proxy in five minutes, and what to do in case of a mismatch.

What is a TCP/IP fingerprint and why does a proxy change it

Each OS collects the SYN packet in its own way: its initial TTL, TCP window size, window scaling factor, MSS, and most importantly, the set and order of TCP options. Passive fingerprinting (the classic tool here is p0f, while modern variants are called Zardaxt and JA4T) reads these fields and guesses the OS without sending anything back to the client.

A key point for those working through a proxy: the site sees the TCP stack of the machine that opens the last connection to it. A regular proxy (HTTP CONNECT or SOCKS5) accepts your connection and opens a new one to the site in its own name. Therefore, the TTL and TCP options in the packet belong to the proxy, not your computer. You can change the User-Agent, TLS fingerprint, or headers, but the SYN has already been collected by the kernel of the machine through which you are connecting.

Typical values by OS

Benchmarks from Scrapfly's analysis and pydoll documentation (values may vary depending on specific kernel versions and networks):

Windows 10/11: initial TTL 128, window 64240–65535, order of options MSS, NOP, WSCALE, NOP, NOP, SACK (without timestamp by default).
Linux: TTL 64, window 29200 on 3.x+ kernels (on some 5.x/6.x kernels 64240), order MSS, SACK, TIMESTAMP, NOP, WSCALE.
macOS and iOS: TTL 64, window 65535, order MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL.
Android: TTL 64, with the order of options similar to Linux, which is logical since it has a Linux kernel.

From this, the main trap emerges: almost all data center proxies operate on Linux. A "Windows + Chrome" profile over such a proxy carries Linux traits in the SYN, and this contradiction is most noticeable.

How accurately do anti-bots catch mismatches

Figures are available from the open project Zardaxt: these are rewritten p0f and satori.py that specifically look for relays, i.e., HTTP and SOCKS proxies behind which the browser presents itself as another machine. According to the README for the build from September 21, 2026 (based on 1,453 fingerprints from approximately 23,000 sessions):

A model with a threshold of 0.8 catches 94.4% of connections through proxies and mistakenly marks only 0.1% of direct connections;
If the browser claims Windows, the proxy is caught 96% of the time; if it claims Mac, then 99%;
The weak point is Android and Linux: they share one class, so such relays are caught 74% of the time;
Tunneling VPNs are hardly detected by the model (6.1%): through a tunnel to the site, the stack of your own device speaks.

The OS reveals itself most through the order of TCP options: in the factor analysis of the project, this field guesses the OS 99.1% of the time. The DF flag is almost useless (0.362). This is an open tool from one researcher; commercial anti-bots do not publish details, but the principle is the same: compare the OS from the SYN with the OS from the User-Agent.

How to check your proxy: step by step

Take a "baseline" without a proxy. Open browserleaks.com/tcp in a regular browser. Record the TTL, MSS, order of options, p0f guess, and Zardaxt's OS estimates. This is your real stack.
Check the proxy from the console. Execute a request through the proxy to an open classifier:
curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
The response will include the field avg_score_os_class with scores for Linux, Windows, Mac OS, and iOS. The winner here is the OS of the proxy's exit node, not your computer.
Repeat in the anti-detect profile. Open browserleaks.com/tcp or proxydetect.live/tcpip.html in the profile with the proxy. Now compare two things: the OS from TCP/IP and the OS from the User-Agent of the profile.
Look at the MSS. A clean Ethernet line gives an MSS of 1460. Values like 1380 (WireGuard), 1360 (IPsec), or 1240 indicate a tunnel on the way. By itself, this is not a ban; mobile networks often provide a lower MSS as well, but combined with other signs, it raises suspicions.
Take 5–10 measurements on rotation. With residential and mobile proxies, each new IP may be a different device with a different OS. One measurement says nothing; look at the distribution.
Compile a table: proxy type → OS by TCP → OS of the profile → match yes/no. This is the answer to which profile to run on which proxy.

One TTL alone is not sufficient as evidence: the visible value decreases at each router, and the site only evaluates the initial (64 or 128) based on the nearest power of two. The combination of fields is what matters, primarily the order of options.

What to do in case of a mismatch

1. Adjust the profile to the proxy, not the other way around

The cheapest way: choose the OS of the profile to match what the exit node shows. If the proxy provides Linux, it is more honest to run a Linux profile than to convince the site that you are using Windows. For tasks where the OS of the profile is not important (scraping public pages, price monitoring), this completely resolves the issue.

2. Choose the type of proxy for the required OS

Data center proxies almost always show a Linux server from a cloud ASN. This is normal for scraping from a Linux client (Python, Go, curl on a server): the stack and User-Agent of your script align. For "Windows user" profiles, this is a weak link. Choose data center proxies where speed and price per gigabyte matter, not the legend of a "real person."
Residential proxies connect through real home devices and gateways, so the site sees the stack of a genuine user node. The OS on a specific IP is not guaranteed in advance, but it is the stack of a real device, not a cloud server. For multi-accounting and complex anti-bots, residential proxies provide the most natural picture if you check the distribution of OS on rotation.
Mobile proxies show paths resembling Android or iOS. For mobile profiles (social networks, applications, mobile versions of sites), this is a perfect match across all layers. For more on how to distinguish a genuine mobile IP from a fake one, read our guide on checking mobile proxies. For such tasks, mobile 4G/5G proxies are suitable.

3. Do not confuse the TCP layer with the TLS layer

Tools like curl-impersonate or curl_cffi spoof the TLS handshake and HTTP/2 under Chrome, but do not touch the TCP stack: the SYN is still collected by the kernel of the machine from which the connection is made. A good TLS fingerprint over a contradictory TCP does not save the situation; both layers are needed. How to align the TLS part is discussed in the article about bypassing JA4 through curl_cffi.

4. OS spoofing on the proxy side and tunnels

Providers are starting to sell TCP/IP fingerprint spoofing on their servers, as seen with Byteful above, but this is still rare and in beta. There is also a reverse path: tunneling VPNs are hardly detected by the Zardaxt model as relays because the site sees your own stack. The downsides are also known: reduced MSS indicates a tunnel, and the IP of the VPN itself is often listed in databases as a hosting IP.

Common mistakes

Checking only with IP checkers. IP reputation services look at the address and ASN, not at the SYN. A clean IP with a Linux stack under a Windows profile passes the checker and fails at the anti-bot level.
Making conclusions based on a single measurement on rotation. In a residential pool, the next IP may be a different OS.
Fixing with headers. No header rewrites the SYN after the kernel has sent it.
Ignoring Android profiles on Linux proxies. For open models, this is a zone of uncertainty (74% catch rate), but commercial anti-bots may add other signals, such as timings and mobile ASN. A mobile profile looks more natural on a mobile IP.

Conclusion

The TCP/IP fingerprint is a layer that cannot be fixed from the browser: it is determined by the machine opening the connection to the site. The check takes five minutes: browserleaks.com/tcp without a proxy and with a proxy, plus curl to an open classifier. The simple rule is that the OS of the profile must match the OS of the exit node. Data centers suit Linux scripts, residential proxies fit "live" desktop profiles, and mobile proxies are for mobile scenarios. Choose the type of proxy for your profile, run 5–10 measurements on rotation, and the anti-bot will lose one of its most reliable hooks.