Passive OS Fingerprinting: TCP/IP, JA4T, and Proxy Behavior

Passive OS fingerprinting estimates the network stack behind a connection by observing normal packet characteristics instead of actively probing the device. It can help a network operator classify traffic, diagnose unexpected intermediaries, or compare a connection with other signals. It cannot reliably reveal an exact OS version, identify a unique person, or prove that two matching connections came from the same device.

Proxies make the observation point especially important. A conventional HTTP or SOCKS5 proxy normally creates a new TCP connection to the destination. The destination therefore measures the proxy-side TCP connection, while TLS or browser signals may still come from the original application. A VPN or packet-forwarding path can behave differently.

Quick Answer

Passive OS fingerprinting examines ordinary IP and TCP behavior—especially the initial TCP handshake—to estimate the TCP/IP implementation that created the observed connection. JA4T is a TCP client fingerprint built from the SYN packet's window size, ordered TCP options, maximum segment size, and window scale.

With a direct connection, a website's network edge usually observes the client's TCP stack, subject to changes made by network devices. With a conventional HTTP CONNECT or SOCKS5 proxy, there are separate client-to-proxy and proxy-to-destination TCP connections. The destination observes the stack that created the second connection. If TLS is tunneled without interception, however, the TLS ClientHello can still come from the original browser.

A JA4T value describes a connection profile. It is not a unique device ID, user identity, or guaranteed OS label.

Key Takeaways

• Passive OS fingerprinting estimates a TCP/IP implementation from observed traffic; it does not establish an exact OS version with certainty.
• JA4T and JA4 are different. JA4T fingerprints a TCP SYN; JA4 fingerprints a TLS ClientHello.
• A conventional application proxy normally terminates one TCP connection and creates another, so the destination sees the proxy-side TCP stack.
• An HTTP CONNECT or SOCKS5 tunnel can relay the original client's TLS bytes even though the destination-facing TCP connection came from the proxy.
• VPNs, packet-forwarding gateways, transparent middleboxes, and reverse proxies can produce different observation boundaries.
• Matching JA4T values do not prove that two requests came from one device. Many systems can share the same TCP defaults.
• In our controlled check, direct and proxied routes had different public IPs but the same JA4T; the observer reported Android for a runner known to use Linux, and the available evidence does not establish why.

What Is Passive OS Fingerprinting?

Passive OS fingerprinting is the process of observing normal network traffic and comparing its protocol characteristics with known implementation patterns. The observer does not need to send unusual probes to the device being classified.

Operating systems and network appliances implement TCP/IP standards with different defaults and engineering choices. Useful observations can include:

• TCP receive-window value.
• Which TCP options appear and the order in which they appear.
• Maximum segment size, or MSS.
• Window-scale value.
• Initial time-to-live or IPv6 hop-limit estimate.
• IP flags, packet sizes, quirks, and retransmission behavior.
• How the values change across connections or network paths.

A tool compares those observations with known profiles and returns a likely family, implementation, or device class. The output should be treated as an estimate. The official p0f documentation explicitly describes generic fallback signatures and says its results should be treated as advisory because fingerprints can be changed or evaded.

Passive does not mean invisible or uniquely identifying. It means the classifier observes traffic that already exists instead of initiating a special scan.

Passive vs. Active OS Fingerprinting

Passive fingerprinting watches normal traffic; active fingerprinting sends chosen probes and analyzes the replies. The two methods can inspect similar protocol behaviors, but they collect evidence differently.

Nmap's OS detection is an active example: it sends a defined set of probes and compares the responses with a database. Tools such as p0f classify normal observed TCP traffic passively.

Neither method guarantees a correct answer. Firewalls, forwarding, shared defaults, custom TCP settings, virtualization, and unknown signatures can all produce an ambiguous or incorrect match.

How TCP/IP Fingerprinting Works

For an inbound TCP connection, the initial SYN is especially useful because it advertises how the connecting endpoint wants to communicate before application data is exchanged.

The observer can record the SYN's window value, TCP option kinds and ordering, MSS, window scale, IP version, TTL or hop limit, and related flags. It can then compare the resulting signature with a database or use it as a stable grouping field.

Several caveats matter:

1. The observed TTL is not necessarily the sender's initial TTL. Routers decrement it along the path, so tools estimate the starting value and distance.
2. MSS can describe path overhead as well as a host default. Tunnels and middleboxes can clamp it.
3. Different systems can produce the same fields. A profile may match an OS family rather than a specific release.
4. A network device can modify selected fields without terminating the connection.
5. If an intermediary creates a new TCP connection, the observer measures that intermediary's destination-facing stack.

The current TCP specification also recognizes that option presence, option ordering, timing, sizing, and implementation-specific behavior can be used to infer a TCP implementation. These signals are useful precisely because standards leave some engineering decisions to implementers.

What Does a JA4T Fingerprint Contain?

JA4T is FoxIO's TCP client fingerprint. It is calculated from an initial TCP SYN and is intended to be human-readable, loggable, and useful for grouping connections and spotting unusual network conditions.

The common four-part form is:

For example:

RFC 7323 specifies that the window field in a SYN or SYN-ACK is not scaled. The negotiated scale factor applies to later window advertisements after the handshake.

The option numbers come from the IANA TCP Option Kind registry:

JA4T does not encode a person's identity. It also does not include every adjacent field that a website might display. For example, a testing service can show an MTU estimate, hop distance, and OS guess beside JA4T even though those values are not part of the four-section JA4T string.

FoxIO's reference repository provides JA4T implementations for different tools. As of September 22, 2026, an open issue in that repository documents differences between the Rust, Wireshark, and Zeek implementations for edge cases such as missing options and ECN-marked SYN packets. Record the implementation and version when comparing results; identical traffic may otherwise be formatted differently.

TCP/IP vs. TLS vs. Browser Fingerprints

TCP, TLS, HTTP, browser, and IP reputation signals belong to different layers. Treating them as one fingerprint causes incorrect conclusions about what a proxy changes.

JA4 without a suffix is a TLS client fingerprint. JA4T is the TCP client fingerprint. JA4H is an HTTP client fingerprint. A JavaScript/browser fingerprint is a broader browser-side collection method and is not interchangeable with any of those network fingerprints.

For more on browser-side signals, see our browser fingerprinting guide or inspect the signals directly with the free Proxidize Browser Fingerprint tool.

Whose TCP Fingerprint Does a Website See Through a Proxy?

The website sees the TCP stack that created the connection reaching its observation point. With a conventional forward proxy, that is normally the proxy-side connection—not the original client-to-proxy connection.

The path contains two distinct TCP handshakes:

The proxy can relay application bytes between those connections, but TCP sequence numbers, TCP options, receive windows, and retransmission behavior belong to each separate connection.

HTTP CONNECT Proxies

For HTTPS, the browser commonly opens a TCP connection to the HTTP proxy and sends CONNECT target.example:443. The proxy then establishes a separate TCP connection to the target. RFC 9110 defines the proxy's switch to blind forwarding after a successful CONNECT response.

This creates a split that is easy to miss:

• The target-facing TCP SYN comes from the proxy-side connection, so the target's JA4T represents that connection.
• The browser can create the TLS ClientHello and send it through the tunnel unchanged, so the target's JA4 can still represent the browser's TLS library.
• The source IP is the proxy exit.
• JavaScript executed by the page still observes the browser environment unless a separate browser-profile system changes it.

A TLS-inspecting intermediary behaves differently because it terminates the client's TLS session and creates another TLS session toward the target. In that architecture, the target can see both TCP and TLS characteristics generated by the intermediary.

SOCKS5 Proxies

SOCKS5 has the same important connection boundary. The client connects to the SOCKS5 server, negotiates, and asks it to connect to a destination. RFC 1928 specifies that the SOCKS server establishes the requested connection before relaying data.

For HTTPS carried over SOCKS5, the destination normally sees the SOCKS egress connection's TCP profile while the TLS ClientHello can remain client-generated. DNS behavior depends on whether the client sends an IP address or hostname to the proxy.

Our HTTP vs. SOCKS5 comparison explains their protocol and DNS differences in more detail.

VPNs and Packet-Forwarding Paths

A VPN is not necessarily an application-level TCP relay. Many VPNs encapsulate and forward the client's IP traffic, then translate the source address at the VPN gateway. In that design, more of the original client's TCP behavior can reach the destination.

The result can still change. Tunnel overhead can reduce MSS, and gateways or middleboxes can clamp MSS or alter other fields. FoxIO's JA4T technical article specifically notes that VPN paths can change MSS and sometimes window size.

Do not infer behavior from the label “VPN,” “proxy,” or “gateway” alone. Determine whether the intermediary terminates TCP, forwards packets, translates addresses, intercepts TLS, or combines several of those operations.

CDNs, Reverse Proxies, and Load Balancers

Observation point matters on the server side too. A CDN or reverse proxy usually accepts the public client's connection at its edge and creates another connection to the origin.

• The edge can observe the public client's TCP and TLS characteristics.
• The origin's packet capture sees the CDN or reverse proxy's origin-facing connection.
• The website operator may receive edge-computed fields through logs or headers, but only if the service exposes them.

An origin server reporting the CDN's JA4T does not mean the edge failed to observe the client. It means the measurements were taken at different connections.

Direct vs. Proxy Test: What We Observed

We ran a small controlled comparison on September 22, 2026. The purpose was to verify how an observer reported the route—not to benchmark a provider or prove a universal fingerprint.

The test used Playwright 1.62.1 with its bundled Chromium 151.0.7922.34 on a Linux 6.11 runner. We opened the same BrowserLeaks IP and TCP page three times directly and three times through one Proxidize residential HTTP access point. The browser binary, target, and collection logic remained the same. Full IP addresses and credentials are not published.

The public IP, location, network, and hop estimate changed. JA4T and JA4 did not change in this sample.

That result does not mean BrowserLeaks saw one unbroken client TCP connection through the proxy. A conventional HTTP proxy establishes the destination connection separately. It means the two observed destination-facing connections produced the same four-field JA4T value. Common Linux-derived stacks and shared defaults can collide.

The reported OS label did not match the known runner OS: BrowserLeaks reported Android, while the runner was Linux and Chromium declared its platform as Linux. Without the observer's server-side packet capture, we cannot establish exactly why BrowserLeaks assigned that label or whether an intermediary influenced the reported fields. The mismatch shows why the label should be treated as an estimate rather than direct OS disclosure.

The unchanged JA4 is consistent with Chromium creating the TLS ClientHello and the HTTP CONNECT proxy relaying those TLS bytes without interception. It does not show that every proxy, browser, or destination will behave the same way.

Test Limitations

• We tested one proxy exit, one destination, one browser build, and one short time window.
• The proxy route returned the same exit in all three observations, so the test did not compare multiple exit systems.
• We relied on the fields BrowserLeaks reported; we did not have its server-side packet capture.
• We did not test a VPN, transparent proxy, TLS-intercepting proxy, CDN origin, IPv6 path, or QUIC/HTTP3 path.
• The result measures observed connection fields, not access quality, throughput, or provider-wide behavior.

How to Test Your Own Direct and Proxied Connections

Use the same client, target, and test window for both routes. Change only the routing variable, then repeat each route enough times to detect rotation or connection-to-connection variation.

Use a separate tool for each layer you want to verify. The Proxidize network-tool collection includes first-party checks for the exposed route and browser environment, while JA4T requires an observer that can inspect the destination-facing TCP SYN.

The Proxidize Browser Fingerprint report is computed locally in the browser. The tools serve different purposes: changing the IP route does not necessarily change the browser snapshot, and a stable browser snapshot says nothing about which TCP stack created the destination connection.

1. Record the Test Environment

Write down:

• Date and time.
• Operating system and kernel version.
• Browser or HTTP-client version.
• Fingerprinting service or server-side collector version, when available.
• IPv4 or IPv6.
• Direct, HTTP CONNECT, SOCKS5, VPN, or another route type.
• Whether a CDN or reverse proxy sits in front of the collection endpoint.

2. Capture a Direct Baseline

Open a controlled endpoint directly and record:

• Observed public IP, preferably redacted in anything published.
• JA4T and its component fields.
• MTU and hop/distance estimate when reported.
• Inferred OS or device family.
• JA4, HTTP signature, and declared browser platform as separate fields.

Start with the Proxidize IP Checker to confirm the direct route's public network identity, then use the Proxidize Browser Fingerprint to record the separate browser layer. Neither calculates JA4T. For TCP fields, BrowserLeaks provides a convenient observer-side check, while FoxIO publishes JA4+ Wireshark and Zeek implementations for infrastructure you control. A server-side packet capture is stronger evidence because it lets you retain the SYN and verify how the fingerprint was calculated.

3. Repeat Through the Proxy

Restart the browser or client with the proxy configured, keeping its version and other settings unchanged. Our Playwright proxy guide shows how to supply the proxy server and credentials without embedding them in page code.

Do not paste secrets into screenshots, command history, source control, or published results. Load credentials through your existing secrets workflow.

4. Repeat and Compare

Run at least three observations per route and record each result rather than only the most convenient one.

If the goal is to identify exactly which endpoint generated a SYN, capture at both sides of infrastructure you control. A public testing page can show what it observed, but it cannot expose every internal hop or prove how a commercial service implements its routing.

How to Interpret Passive OS Fingerprint Results

Treat each result as evidence about a connection, not a verdict about a person or device.

The Same JA4T Can Appear on Different Devices

JA4T has only four sections, and many devices share kernel families, default option order, MSS, and window settings. NATed users, containers, virtual machines, gateways, and proxy exits can therefore produce the same value.

A shared JA4T is useful for grouping, but it is not a unique identifier.

A Different JA4T Does Not Necessarily Mean a Different OS

Changing a route can alter MSS. System updates, TCP tuning, virtualization, network interfaces, and intermediate devices can also change fields without replacing the underlying OS.

Compare the individual sections instead of treating the entire string as an opaque identity token.

“Unknown” Can Be the Correct Result

A classifier may lack a matching signature, observe too few fields, or receive a pattern shared by several systems. Reporting unknown or a broad family is more accurate than forcing a precise version.

Cross-Layer Mismatches Can Be Expected

A proxy can make the target-facing JA4T look like its egress stack while leaving the browser-generated JA4 and browser platform unchanged. That mismatch follows naturally from two TCP connections carrying one end-to-end TLS stream.

A mismatch can be useful for debugging or traffic analysis, but it does not by itself prove malicious behavior or identify a specific proxy product.

Results Can Differ by Observation Point

An edge proxy, CDN, origin server, network sensor, and client-side capture can each observe a different connection. Always record where the measurement was taken.

What Proxies Do—and Do Not—Change

A proxy changes the network route and public exit identity. A conventional proxy also creates a destination-facing TCP connection whose stack can be measured by the target.

A proxy does not automatically change:

• The TLS ClientHello produced by a tunneled browser.
• HTTP headers sent inside an encrypted tunnel.
• JavaScript-visible browser and hardware signals.
• Cookies, storage, account state, or application behavior.
• Every packet field in every proxy, VPN, or forwarding architecture.

Proxidize provides residential and mobile proxy routes with standard HTTP and SOCKS5 access, targeting controls, and rotating or sticky sessions. Those controls manage routing and session behavior; they should not be described as a universal browser- or device-fingerprint replacement.

Product-specific packet normalization or OS-spoofing behavior should be verified for the exact product, version, protocol, and route being used. Do not infer it from a general proxy claim.

Final Recommendation

Start by identifying the connection and observation point. A website edge, proxy, VPN gateway, CDN origin, and client packet capture may all measure different parts of the same request path.

Use JA4T as a compact TCP connection fingerprint, not as a unique device identifier or exact OS answer. Compare it with TLS, HTTP, browser, IP, and application signals while keeping those layers conceptually separate. When a proxy is involved, determine whether it terminates TCP, forwards packets, or intercepts TLS before deciding whose fingerprint the observer sees.