JA4T TCP Fingerprinting — SYN Window, MSS, Options

JA4T TCP fingerprinting identifies the TCP stack from the first SYN packet, before TLS or HTTP exist. A fingerprint like 64240_2-1-3-1-1-4_1460_8 means: raw SYN window size 64240, ordered TCP option kinds 2-1-3-1-1-4, MSS 1460, and window scale 8.

Last verified: 2026-06-15 against the FoxIO JA4+ repository, FoxIO’s JA4T article, and the reference Rust/Zeek implementations.

Quick Reference

JA4T is the TCP-layer sibling of JA4 TLS fingerprinting inside the wider JA4+ fingerprint suite. JA4 reads the TLS ClientHello; JA4T reads the TCP SYN that arrives one layer earlier. That makes it useful when a request can fake a browser TLS fingerprint but still exposes a non-browser TCP stack, proxy, VPN, load balancer, or scanner path.

What JA4T fingerprints

JA4T, short for JA4TCP, is part of FoxIO’s JA4+ family. The passive client format built by the reference Rust and Zeek implementations is:

<window size>_<tcp option kinds>_<mss>_<window scale>

The canonical Rust example is also the Windows 11 JA4T example in FoxIO’s main mapping table:

64240_2-1-3-1-1-4_1460_8

The fields come from the TCP SYN packet. TCP starts a connection with a SYN, the server answers with SYN-ACK, and the client finishes with ACK. TLS negotiation starts after that handshake. JA4T therefore captures the operating system or network device behavior that exists before a TLS library, HTTP client, JavaScript runtime, or bot framework can shape the application layer.

The key design choice is that the fingerprint is human-readable. JA3 hides its input behind an MD5 hash. JA4T leaves the network facts visible: window size, option order, MSS, and window scale can be read from the string without a lookup database.

The option list is literal TCP option kind numbers. The common ones are:

That is why the 2-1-3-1-1-4 segment is not decorative. The repeated 1s are NOP padding, and the presence, absence, and order of option kinds help distinguish TCP stack families.

Decoding 64240_2-1-3-1-1-4_1460_8

The example fingerprint has four parts.

Window size and window scale work together. The raw TCP window field is only two bytes wide; window scale acts as a multiplier. FoxIO’s JA4T article gives the example 64240 * 2^8 = 16,445,440 bytes of effective receive window.

MSS is the field that most often points at path shape instead of only OS shape. 1460 is the common Ethernet value: MTU 1500 minus 20 bytes of IPv4 header and 20 bytes of TCP header. Lower values can appear when a VPN, mobile carrier, tunnel, overlay network, or other intermediary adds overhead and reduces the payload that safely fits into each packet. AWS jumbo-frame environments can produce much larger values; FoxIO’s JA4TScan examples include AWS Linux 2 with MSS 8961.

JA4T vs JA4 vs JA4H

Layering is the point. A scraper can use curl_cffi to mimic browser TLS and produce a browser-looking JA4. It can still fail if its TCP SYN looks like Linux defaults behind a data-center proxy, or if its HTTP/2 SETTINGS look unlike Chrome. Modern bot detection stacks score these signals together, not one hash at a time.

JA4T is also earlier than JA4. A firewall, load balancer, or netflow sensor can compute JA4T without decrypting TLS and without seeing HTTP. That makes it useful for traffic shaping and scanner clustering at network edges where application-layer visibility is limited.

Proxy and VPN behavior

JA4T is an observation of the TCP packet that reaches the sensor. That distinction matters.

For a direct client connection, the server-side sensor sees the client’s TCP stack. For a proxy connection, the destination usually sees the proxy’s TCP stack, not the original device. FoxIO’s JA4T article calls out iCloud Relay as an example where an iPhone’s visible fingerprint changes because the relay terminates and re-originates the connection path.

VPNs and tunnels behave differently. They may preserve the originating TCP stack but reduce MSS or alter window-size-related behavior because extra encapsulation consumes packet budget. That is why MSS belongs in the fingerprint rather than being discarded as noise. A changed MSS is often the evidence that a path includes an intermediary.

This is the difference between JA4T and older OS-fingerprinting tools. Nmap and p0f are excellent for fuzzy OS matching. JA4T is designed to be logged and pivoted as a stable-ish network artifact, including the messy path conditions that older tools often tried to normalize away.

Passive JA4T, JA4TS, and JA4TScan

Passive JA4T is the client-SYN fingerprint. It has the four fields shown above.

JA4TS is the server-side sibling: the SYN-ACK response exposes the server TCP stack. FoxIO’s Zeek script builds ja4ts from SYN-ACK window size, option kinds, MSS, and window scale. When retransmission timing is available, the script appends a fifth part with SYN-ACK delay intervals and optional reset timing.

JA4TScan is FoxIO’s active scanner built on Zmap. It sends a single SYN probe, listens for SYN-ACK retransmissions, and records those retransmission intervals as part of the active server fingerprint. FoxIO’s README examples look like:

65535_2-1-3-1-1-4_1440_8_0-1-R2

That last 0-1-R2 style segment is not needed for passive client JA4T. It is useful when actively probing servers, because retransmission cadence is another operating-system and network-stack clue.

How to generate a JA4T

Passive JA4T comes from capture tooling at the network edge. FoxIO ships Wireshark, Zeek, Rust, and Python implementations in the JA4+ repository; the Zeek script logs ja4t for client SYN fingerprints and ja4ts for SYN-ACK server fingerprints.

For active server fingerprinting, JA4TScan wraps a Zmap probe. Run it only on networks where scanning is authorized. FoxIO’s single-host README example is:

sudo python3 ja4tscan.py -p 80 204.79.197.223

The corresponding example output is timestamp, source address, and fingerprint:

1710168119,204.79.197.223,65535_2-1-3-1-1-4_1440_8_0-1-R2

Use the four-field part for the TCP-stack shape and the optional fifth segment for active retransmission behavior.

Detection use cases

JA4T is most useful when a defender needs cross-layer consistency checks.

• Browser impersonation checks: a browser-looking JA4 paired with an odd JA4T means the TLS layer may be impersonated while the TCP layer still exposes the real client or proxy stack.
• Proxy and relay clustering: many users behind the same proxy, relay, load balancer, or scanner infrastructure can share TCP-layer traits even when headers and TLS change.
• Scanner triage: active scan traffic often comes from cloud hosts, appliances, or purpose-built tooling whose TCP signatures differ from residential browser paths.
• Troubleshooting: sudden MSS shifts can point to VPN rollout, tunnel overhead, carrier changes, or path MTU problems before application logs explain the failure.

The safe rule is not “block this JA4T everywhere.” TCP fingerprints are environmental. They vary by OS, appliance, network path, and observer position. A good rule treats JA4T as one high-signal column beside JA4, JA4H, HTTP/2, ASN, behavior, reputation, and session history.

Sources

• FoxIO JA4+ repository — canonical JA4+ family list, tool support, and technical detail diagrams for JA4T/JA4TS/JA4TScan.
• FoxIO JA4T: TCP Fingerprinting — primary explanation of the JA4T design, TCP fields, MSS/path behavior, proxy/VPN effects, and JA4TScan use cases.
• FoxIO JA4TScan repository — active scanner examples, retransmission timing suffixes, and real JA4TScan fingerprints for Windows, macOS/iPhone, AWS Linux, F5 BIG-IP, printers, and routers.
• JA4 Zeek ja4t/main.zeek — reference construction of passive ja4t and server-side ja4ts strings from captured packets.
• RFC 9293: Transmission Control Protocol — TCP standard reference for the SYN handshake, window field, options, MSS, and Window Scale context.
• JA4 vs JA3: Why TLS Fingerprinting Migrated — companion entry for the TLS-layer JA4 format.