TCP/IP Fingerprinting: What Your Proxy's Network Stack Reveals

Most discussions about proxy detection focus on the IP address, the browser fingerprint, and the TLS handshake. There is another layer underneath all of them: the first packet of every TCP connection.

Operating systems fill in that packet differently. The starting TTL, the window size, the maximum segment size, and the order of TCP options together form a signature that a server can observe as the connection is established, without sending any probes of its own. This is called passive TCP/IP fingerprinting.

It matters for proxy users because an HTTP or SOCKS5 proxy opens its own connection to the website. The website then sees the network stack of the proxy, not the one on your device. If your browser says Windows and the TCP packet says Linux, that is an inconsistency a site can notice. This guide explains which fields reveal the operating system, how proxies change them, and how to check and align what websites see.

What Is TCP/IP Fingerprinting?

Every TCP connection starts with a SYN packet from the client. The IP and TCP headers of that packet contain values that each operating system sets in its own way. Comparing those values with known signatures makes it possible to estimate which operating system sent the packet.

There are two approaches. Active fingerprinting, used by tools such as Nmap, sends probe packets to a host and studies the replies. Passive fingerprinting only observes traffic that arrives anyway. The open source tool p0f describes itself as a tool that uses "purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications."

For a server or network device, passive fingerprinting does not require a separate probe. The SYN packet is already part of the normal TCP connection process, so the signature is available before any HTML, JavaScript, or cookie is involved.

Which Fields Reveal the Operating System

Initial TTL

The Time To Live (TTL) field limits how many routers a packet can pass through. Each router lowers it by one. The starting value depends on the operating system. The p0f documentation notes that "almost all operating systems use 64, 128, or 255." Linux uses 64 by default, as the kernel documentation states for the ip_default_ttl setting, and the Windows 7, 8, and NT kernel signatures in the p0f database use 128.

A website sees the TTL after it has crossed the network, so the value is lower than it started. An observed TTL of 52, for example, most likely started at 64 and crossed 12 hops. Rounding the observed value up to a common initial TTL provides a useful estimate of the sender's original TTL.

Window size and window scale

The TCP window size tells the other side how much data it can send before waiting for an acknowledgment. According to the p0f documentation, it "can be expressed as a fixed value, but many operating systems set it to a multiple of MSS or MTU." The window scale option sets a shift factor that enlarges window values in later segments. Both vary between operating systems and versions.

Maximum segment size (MSS)

MSS is the largest amount of data a host will accept in a single TCP segment. FoxIO, the company behind the JA4+ fingerprinting suite, notes that "the most common Maximum Segment Size (MSS) initially set is 1460, based on an ethernet MTU of 1500." A lower value can reveal something about the path. In FoxIO's words, "observing an MSS of 1380 would indicate that there is overhead on the network path, such as a tunnel or VPN."

TCP options and their order

The SYN packet also lists TCP options, such as MSS, selective acknowledgment (SACK), timestamps, and window scale. Which options appear, and in which order, is one of the most distinctive parts of the signature. Timestamp support and option ordering differ across operating systems and versions, and both p0f and JA4T use these differences as fingerprinting signals. In the p0f database, for example, most Windows signatures leave out the timestamp option, while the macOS and iOS signatures end the option list with an end-of-list marker.

The table below shows common SYN signatures from the p0f database. In the option lists, sok means SACK permitted, ts means timestamp, ws means window scale, and eol means end of options list.

What TCP/IP fingerprinting can and cannot tell you

A TCP/IP fingerprint is a useful signal, but it has clear limits:

• It produces an estimate of the operating system, not a definitive identification.
• Proxies and VPN tunnels change what the server observes, and the network path lowers the TTL and can affect the MSS.
• Different versions of the same operating system can use different TCP signatures.
• Many devices running the same operating system share the same signature, so a TCP fingerprint alone says little about which device or person is behind a connection.
• Detection systems that use it can weigh it together with IP data, TLS fingerprints, and browser signals.

Why Proxies Change Your TCP/IP Fingerprint

HTTP and SOCKS5 proxies open a new connection

With an HTTP or SOCKS5 proxy, your device does not connect to the website directly. It connects to the proxy, and the proxy opens a separate TCP connection to the destination. The SOCKS5 specification, RFC 1928, describes the proxy server evaluating the client's request and then "either establishes the appropriate connection or denies it." For HTTPS through an HTTP proxy, the CONNECT method asks the proxy to set up a tunnel and then "blindly forward data in both directions until the tunnel is closed."

Because the proxy opens the connection, the SYN packet the website receives is built by the proxy's operating system. FoxIO states it directly: "When a device is connected through a Proxy, the TCP fingerprint of the proxy is seen on the server side, not the client."

TLS and TCP come from different machines

The tunnel forwards your data without changing it, so unless the proxy decrypts TLS, the handshake inside the tunnel still comes from your browser or HTTP client. The result is a split. The TCP/IP fingerprint belongs to the proxy, while the TLS fingerprint (JA3 or JA4) and everything above it, including headers and browser signals, belong to your client. Both layers need to tell the same story.

VPN tunnels behave differently

A VPN tunnel such as OpenVPN forwards your device's own IP packets instead of opening new connections. The website therefore sees your device's TCP settings, but with changes caused by the tunnel. FoxIO notes that when a device is connected through a VPN, the MSS, and occasionally the window size, are changed based on the overhead of the VPN. A reduced MSS on an otherwise normal signature is one of the ways a tunnel can be recognized.

Direct, proxy, and VPN connections compared

TCP/IP vs TLS vs Browser Fingerprinting

TCP/IP fingerprinting is one of three layers that websites can read, and each layer comes from a different place. Seeing them side by side explains why a proxy affects only part of your fingerprint:

An HTTP or SOCKS5 proxy normally changes the TCP/IP layer seen by the destination. The TLS and browser layers still come from your own client unless the proxy is terminating or intercepting TLS, so the signals across all three layers should be consistent with the device or client profile the workflow is intended to represent. Browser Fingerprinting Explained covers the TLS and browser layers in detail.

The OS Mismatch Problem

The most practical use of TCP/IP fingerprinting for a website is a consistency check. Security researcher Nikolai Tschacher described the approach in 2021: "The goal is to detect a mismatch in the operating system specified in the HTTP User-Agent header and the operating system inferred from the TCP/IP header intricacies."

Here is a typical case. A scraper sends requests with a Windows Chrome User-Agent through a proxy whose exit machine runs Linux. The User-Agent says Windows, which would normally mean an initial TTL of 128 and usually no timestamp option. The SYN packet says Linux, with a TTL that started at 64 and a timestamp option present. Each signal looks normal on its own, but together they do not match.

Publicly available tools make this kind of check easy to add: the open source p0f, FoxIO's JA4T, and Zardaxt, which Tschacher publishes on GitHub, can all classify incoming SYN packets. That does not mean every website runs this check, and a mismatch has innocent explanations too, such as traffic from corporate proxies, which present their own TCP fingerprint. It is usually one signal weighed alongside IP data, TLS, and browser fingerprints rather than proof on its own.

Where Mobile Proxies Fit

Android uses a Linux-based kernel, and the p0f database includes Android signatures that share several TCP characteristics with Linux, such as an initial TTL of 64. An Android browser profile combined with an Android-compatible TCP fingerprint can therefore produce a more internally consistent profile for a mobile proxy workflow. This matches what an ordinary Android phone on a carrier network looks like at the network level, which makes Android profiles a natural fit for mobile proxy workflows.

Other profiles need more care. If your automation uses a Windows, macOS, or iOS browser profile, the TCP layer should match that operating system too. This is where OS fingerprint control becomes relevant for proxy users.

PowerProxy includes a Passive OS Fingerprint option that simulates Android, iOS, Windows, or macOS through custom TCP/IP fingerprints. In the Windows example above, setting the fingerprint to Windows helps the network layer better align with the Windows browser profile. Choosing the operating system that matches your User-Agent or antidetect browser profile keeps the network layer and the browser layer consistent.

How to Check What Websites See

Quick check with BrowserLeaks

The fastest way to see your TCP/IP fingerprint is the TCP/IP Passive Fingerprinting page at browserleaks.com/tcp. Open it through your proxy and it shows the JA4T fingerprint, initial TTL, MSS, window size, TCP options, and an operating system estimate. Compare that estimate with the operating system in your User-Agent. Then open the same page without the proxy to see how the two differ.

Capture the SYN on your own server

For a more controlled test, capture incoming SYN packets on a server you control. The script below uses Scapy and prints the fields discussed above for every new connection to port 8080. Packet capture requires root privileges, and the filter shown covers IPv4 traffic.

To run the test, start a simple web server on the same machine with python3 -m http.server 8080, run the capture script with sudo in a second terminal, and send one request through the proxy and one without it:

The first line of output shows what websites see from your proxy. The second shows your own machine. If the proxy output does not match the operating system your browser profile claims, adjust the setup before running real workflows.

What to re-check after changing proxies

After changing a proxy, a proxy protocol, or an OS fingerprint setting, check:

• Initial TTL
• MSS
• Window size and window scale
• TCP options and their order, or the JA4T fingerprint that combines them
• TLS fingerprint (JA3 or JA4)
• User-Agent and browser OS profile
• Whether the connection uses IPv4 or IPv6

Common Mistakes

Matching the User-Agent but not the network stack

Changing the User-Agent to Windows or iOS does not change the SYN packet. Through an HTTP or SOCKS5 proxy, the TCP signature comes from the proxy, so it has to be aligned separately.

Assuming a VPN and a proxy look the same

A proxy replaces your TCP fingerprint with its own. A VPN tunnel passes your device's fingerprint through, usually with a reduced MSS. The two produce different signatures, so test the protocol you actually use.

Randomizing TCP values

Changing individual values at random can produce a combination that matches no real operating system. A signature that looks like a real OS is more consistent than one that looks like none.

Forgetting the TLS layer

A Windows TCP signature does not help if the TLS handshake matches a Python HTTP library while the User-Agent claims Chrome. The TCP, TLS, and browser layers need to agree with each other.

Testing once and never again

Fingerprints change when you switch protocols, proxy settings, operating system profiles, or client software. Re-check after any change to the setup.

FAQ

Can a website see my real operating system through an HTTP or SOCKS5 proxy?

Not at the TCP level. The website sees the TCP/IP fingerprint of the proxy that opened the connection. Your operating system can still show up in other layers, such as the TLS handshake, the User-Agent, and browser JavaScript signals.

Is TCP/IP fingerprinting the same as browser fingerprinting?

No. TCP/IP fingerprinting reads values from network packets before any web content loads. Browser fingerprinting reads values from the browser, such as screen size, fonts, and canvas rendering, usually through JavaScript. They are separate layers, and a consistent setup needs both to match.

Does IPv6 change how this works?

The idea is the same. IPv6 uses a Hop Limit field in place of TTL, and tools such as p0f keep signatures for both IPv4 and IPv6 traffic.

Do all websites check TCP/IP fingerprints?

No. Many sites rely on IP data, TLS fingerprints, and browser signals. TCP/IP fingerprinting is one more signal that publicly available tools make easy to add, so it is worth keeping consistent even if a given site does not use it today.

Which OS fingerprint should I choose?

Choose the OS fingerprint that matches the device or browser profile your workflow is intended to represent. If that profile is an Android phone, an Android fingerprint keeps the layers consistent. If it is a Windows desktop browser, choose Windows.

Related Reading

• Browser Fingerprinting Explained
• Proxy Protocols Deep Dive: HTTP vs SOCKS5 vs OpenVPN
• Mobile Proxies vs Datacenter Proxies
• What Is CGNAT?
• How to Test a Mobile Proxy
• Mobile Proxies for Selenium and Puppeteer