TCP fingerprint: why a scraper gets exposed even with a perfect antidetect browser

TCP fingerprint means the network fingerprint of the TCP/IP stack, which helps identify the client's OS even before JavaScript is executed. It is used to detect mismatches between the browser profile, proxy, and actual network stack in web scraping and data collection. In real-world scenarios, consider TTL, window size, the order of TCP options in the SYN packet, and the proxy type, because these signals often explain why tcp fingerprint exposes a scraper without any visible error in Playwright or Selenium.

The problem is unpleasant because everything may look clean at the browser level. User-Agent shows Windows, Canvas and WebGL pass the checker, and timezone matches the proxy geo. But the server sees the lower layer: the SYN packet arrives with Linux behavior typical of a datacenter node. For antifraud systems, this is not a separate "error" but a strong desynchronization signal.

What is a TCP fingerprint and how does it differ from a browser L7 fingerprint

A TCP fingerprint is a set of TCP/IP stack characteristics that a server or WAF sees at the network and transport layers. A browser fingerprint works higher up, at the L7 application layer: JavaScript API, User-Agent, Client Hints, Canvas, WebGL, fonts, timezone, WebRTC. This is why even strong browser fingerprint analysis does not cover the entire risk surface.

In the classic OSI model, the browser operates where HTTP, headers, cookies, and behavioral events already exist. The TCP/IP stack operates lower down. It determines exactly how the connection is created: what initial TTL the OS sets, what receive window size the client advertises, whether SACK is permitted, what the MSS looks like, and in what order the TCP options appear. These details cannot be configured by simply changing the User-Agent.

For a scraper, this creates a strange effect. An antidetect browser may isolate the profile well, while Cloudflare during scraping protection or another antibot layer can still see that the connection behaves like a Linux server in a datacenter. And if the declared profile says "Windows 11 Chrome" while the lower layer looks like headless infrastructure on a VPS, scoring becomes stricter.

Conventionally, these are two passports for the same client. The first is shown by the browser: language, platform, fonts, graphics, cookies. The second is shown by the network: IP, ASN, TLS handshake, TCP SYN, hop distance. When the passports do not match, antifraud does not have to ban the session immediately. It may serve a CAPTCHA, trim content, return an empty page, or silently lower limits.

What a SYN packet consists of and which parameters reveal the operating system

This diagram clearly shows the main trap: antidetect works with the browser layer, while TCP/IP signals come from the connection route.

A SYN packet initiates a TCP connection, so it gives the server the first set of the client's network characteristics. Passive fingerprinting tools such as p0f or JA4T look not at the HTML page but at packet fields: TTL, TCP window size, MSS, window scale, SACK, timestamps, and option order.

In practice, antifraud does not look for a magic "Linux" field. It collects a combination. For example, the initial TTL often has different typical values across operating systems, while the server receives an already reduced number after the packet passes through routers. Window size and window scale show how the stack plans to receive data. MSS depends on the MTU along the route. The order of options in the SYN packet also matters because operating systems and network libraries construct it differently.

An individual parameter can be noisy. A datacenter may have NAT, load balancers, tunnel mode, TCP proxies, or an intermediate network device that rewrites some fields. But the combination of characteristics is often stable. This is exactly what makes TCP/IP fingerprinting useful for passive OS classification.

The following fields are most commonly examined:

• initial TTL or hop limit, which helps estimate the typical OS and distance to the client
• TCP window size, which shows the initial receive window size
• MSS, which defines the maximum TCP segment size for this route
• window scale, SACK, and timestamps, which show the set of enabled TCP options
• TCP option order, because different stacks construct it differently

This set should not be confused with a TLS fingerprint. TLS sits above TCP but below HTTP. JA3, JA4, and similar signatures inspect ClientHello, cipher suites, extensions, and field order in the TLS handshake. Together, TCP and TLS provide an even stronger picture: the browser may identify itself as Chrome on Windows, TLS may look like Chromium, while TCP remains typical of a Linux server. These layers should be checked together.

If you look at the SYN packet as a set of small OS defaults, it becomes clear why simply replacing the User-Agent does not change network behavior.

Why datacenter proxies often have a Linux-like TCP fingerprint

Datacenter proxies often have a Linux-like TCP fingerprint because many proxy nodes in datacenters run on Linux or on network infrastructure with Linux-like behavior. This is normal in the server world. The problem begins when such a node is used as the exit for a profile that pretends to be a home Windows Chrome browser.

If a proxy operates as an HTTP CONNECT or SOCKS5 tunnel, the target website usually sees the TCP connection from the proxy server, not from your local machine. Therefore, the network fingerprint is formed not by the developer's laptop but by the provider's exit node. If it is a cheap VPS or a pool of datacenter IPs, antifraud sees server-side logic even before analyzing page behavior.

This is why changing the browser profile does not always help. You can switch the User-Agent to Windows, set the correct timezone, warm up cookies, and remove obvious WebDriver traces. But the lower layer remains different. For headless browser detection, this is another signal in the scoring model, alongside WebDriver, automation extension, click frequency, and repetitive navigation routes.

In scraping, this often does not look like a ban. The scenario simply starts receiving fewer products in search results, the API returns 403 only for some profiles, the page loads without the required block, while the Playwright log remains clean. The developer looks at selectors, retries, and timeouts. But the cause may be lower down: the datacenter TCP/IP stack does not match the image of an "ordinary user".

What should you do during diagnostics? Do not start by completely rewriting the scraper. First separate the layers: check the browser fingerprint, then TLS, then TCP. If the problem appears only with a specific proxy type or ASN, that already gives you a direction for testing.

How to check your own TCP and TLS fingerprint

Checking a TCP fingerprint starts by launching the profile through the same route used by the scraper. If you test local Chrome without a proxy while production runs through a datacenter SOCKS5 proxy, the result will not reflect the production infrastructure.

The practical minimum is:

1. open the same antidetect profile from which the scraper is launched
2. connect the same proxy, ASN, geo, and protocol used in production
3. go to BrowserLeaks TCP or a similar TCP/IP fingerprint checker
4. record JA4T or Satori fingerprint, TTL, window size, MSS, and TCP options
5. check the TLS fingerprint in a TLS checker, preferably in the same session
6. compare the result with the declared User-Agent, profile OS, and proxy type
7. repeat the test on another proxy of the same type to distinguish an isolated node from a systemic problem

It is important to save results as artifacts rather than rely on memory. For a team, a simple table is enough: profile_id, proxy_provider, proxy_type, ASN, UA OS, TCP OS score, TLS signature, target site result. After a week, this kind of logging will reveal patterns faster than guesswork.

BrowserLeaks TCP is useful because it shows a passive TCP/IP fingerprint assessment directly from the browser session. p0f is useful on your own side if you analyze pcap or want to understand what packets look like at the network boundary. But do not treat a single checker as an absolute judge. Checkers also use heuristics and can make mistakes with NAT, tunnels, or nonstandard middleboxes.

After the test, do not look only at "Windows" or "Linux" in the score. Look at the desynchronization: Windows User-Agent plus Linux TCP, mobile User-Agent plus datacenter ASN, residential IP plus server-like TLS. A single signal is not always critical. A mismatch across several signals already looks like automation.

Such a screenshot is useful as a checkpoint before changing the proxy or infrastructure: first document the desynchronization, then test alternatives.

How to align a Linux TCP fingerprint with a Windows profile

There are three practical directions: change the proxy type, configure the network stack, or move the exit infrastructure to an environment that better matches the required OS. No option solves the problem on its own. Strong results come from aligning the layers, not from one magic setting.

Before choosing a method, clearly answer two questions. Who forms the TCP fingerprint on your route: the local OS, the proxy node, or an intermediate tunnel? And which OS does the browser profile declare? Without this, it is easy to change the parameters of a component that does not actually form the TCP fingerprint.

Kernel tuning may seem attractive because of its potentially lower cost. In reality, this is an engineering area with many technical nuances. You can change TTL but leave the Linux TCP option order. You can adjust window size but get strange behavior during retransmission. You can rewrite packets through NFQueue but run into latency and instability under parallel load.

Changing the proxy type often produces a faster effect. Residential proxies can better align the IP context with the image of a home user, while mobile proxies may be more appropriate for mobile-first platforms. At the same time, the TCP fingerprint is determined by the specific route architecture and exit node, so the proxy type itself does not guarantee a match with the declared OS. But there is no simple rule here either. A poor residential pool with a noisy IP history may perform worse than a high-quality datacenter route for a less sensitive target.

Windows infrastructure is expensive to administer, but it removes part of the contradiction between the declared OS and the lower stack. For a small number of valuable profiles, this may be more rational than endless Linux tuning. For large-scale price monitoring across thousands of URLs, a hybrid often wins instead: some tasks go through a cheaper datacenter route, while sensitive endpoints are moved to another route.

Do residential and mobile proxies solve the problem completely

Residential and mobile proxies can reduce network desynchronization, but they do not remove all automation signals. They change the IP context, while actual TCP/IP behavior depends on the proxy architecture, exit node, and where the TCP connection terminates. Browser fingerprint, TLS, cookies, and script behavior remain separate layers.

For scraping, profile consistency matters. If the User-Agent indicates Windows desktop, it is more logical to have a stable residential or ISP route, the correct timezone, desktop resolution, and behavior without sharp headless anomalies. If the profile is mobile, then a mobile proxy, mobile viewport, correct UA, and limited request frequency should form a consistent picture.

Problems begin when a team mixes layers randomly. For example, the profile has a macOS UA, the proxy exits through a datacenter ASN, the TLS fingerprint resembles automated Chromium, and TCP shows a Linux score. One such match can still be explained. Four together look like infrastructure assembled from inconsistent components.

There is also the question of rotation. Frequent IP switching may help bypass a rate limit but can break session integrity. Antifraud sees that the cookies are the same while IP, ASN, TCP signature, and latency jump too sharply. For login areas, this is more dangerous than a slower but stable route. Sometimes less rotation means less suspicion.

The practical rule is simple: do not optimize for only one checker. Test the actual target platform, keep a response log, and compare route variants using the same scenario. If a residential proxy reduces the number of 403 responses but increases timeout and CAPTCHA rates, that is not a win. It is a different trade-off.

How to build consistent scraping infrastructure without layer desynchronization

Consistent infrastructure starts with a map of layers: browser profile, TLS, TCP/IP, proxy, cookies, and behavioral model should not contradict one another. When a scraper "fails without errors", it is often this map that breaks rather than a selector on the page.

For a team working with Playwright, Puppeteer, or Selenium, it is worth separating the profile from the route and testing them in pairs. One profile should not randomly switch between datacenter, residential, and mobile exits. One proxy pool should not serve profiles that declare incompatible operating systems, geos, and device types.

A convenient workflow:

1. describe the target profile image: OS, browser, geo, device type, timezone
2. choose the proxy type for this image, not for the lowest price per gigabyte
3. check browser fingerprint, TLS, and TCP in the same session
4. run a short scenario on the target platform without aggressive parallelism
5. record responses: 200, 403, CAPTCHA, empty HTML, content changes
6. scale only the route that consistently passes the baseline test

Afina is relevant specifically at the browser layer of this scheme. It helps work with isolated profiles, real fingerprints, cookies, proxies, and automation through scenarios or code, but the network stack of the exit node still needs to be selected separately. And this is an honest limitation of any antidetect browser: it does not turn a Linux proxy into a home Windows stack with one switch. This material is provided solely for informational and educational purposes.

If the pain point is that the browser layer is clean while the network route lives a separate life, Afina should be combined with discipline at the proxy and infrastructure levels. For automation, Playwright, Puppeteer, and Selenium are useful, but they should run in profiles and routes that do not contradict each other. Otherwise, the script may be technically correct while the session still looks foreign to antifraud systems.

Download