Markdown source
JA4T TCP Fingerprinting — SYN Window, MSS, Options Markdown source
Readable source view for humans. The raw Markdown endpoint remains available for crawlers and agent readers.
---
title: "JA4T TCP Fingerprinting — SYN Window, MSS, Options"
description: "JA4T TCP fingerprinting decoded: read 64240_2-1-3-1-1-4_1460_8 as SYN window size, ordered TCP options, MSS, window scale, and proxy/VPN clues before TLS."
kind: article
maturity: budding
confidence: high
origin: ai-drafted
author: "Agent"
directedBy: "krow"
tags: [networking, fingerprinting, bot-detection, ja4, tls]
published: 2026-06-15
modified: 2026-06-25
wordCount: 1663
readingTime: 8
prerequisites: [bot-detection-2026]
related: [ja4-plus-fingerprint-suite, bot-detection-2026, ja4-vs-ja3, http2-fingerprinting-akamai, tls-fingerprinting-curl-cffi]
url: https://krowdev.com/article/ja4t-tcp-fingerprinting/
---
## Agent Context
- Canonical: https://krowdev.com/article/ja4t-tcp-fingerprinting/
- Markdown: https://krowdev.com/article/ja4t-tcp-fingerprinting.md
- Full corpus: https://krowdev.com/llms-full.txt
- Kind: article
- Maturity: budding
- Confidence: high
- Origin: ai-drafted
- Author: Agent
- Directed by: krow
- Published: 2026-06-15
- Modified: 2026-06-25
- Words: 1663 (8 min read)
- Tags: networking, fingerprinting, bot-detection, ja4, tls
- Prerequisites: bot-detection-2026
- Related: ja4-plus-fingerprint-suite, bot-detection-2026, ja4-vs-ja3, http2-fingerprinting-akamai, tls-fingerprinting-curl-cffi
- Content map:
- h2: Quick Reference
- h2: What JA4T fingerprints
- h2: Decoding 64240_2-1-3-1-1-4_1460_8
- h2: JA4T vs JA4 vs JA4H
- h2: Proxy and VPN behavior
- h2: Passive JA4T, JA4TS, and JA4TScan
- h2: How to generate a JA4T
- h2: Detection use cases
- h2: Sources
- Crawl policy: same canonical content is exposed through HTML, Markdown, and llms-full; no crawler-specific content gate.
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
| Segment | Example | Meaning | Why it matters |
|---|---:|---|---|
| Window size | `64240` | Raw TCP receive window from the SYN packet, before window-scale multiplication | OS and TCP stack defaults leak before TLS |
| TCP options | `2-1-3-1-1-4` | TCP option kind numbers in observed order | Option order helps distinguish Windows, Linux, macOS, iOS, appliances, and proxy/relay stacks |
| MSS | `1460` | Maximum Segment Size offered by the sender | Lower values often indicate tunnel, VPN, carrier, or path overhead |
| Window scale | `8` | TCP Window Scale value; FoxIO's Zeek script emits `00` when absent | Multiplies the effective receive window and helps distinguish stack defaults |
| Retransmission timing | `0-1-R2` | Extra JA4TScan / JA4TS-style suffix for SYN-ACK retransmission intervals and RST timing | Useful for active server fingerprinting, not the passive four-field client JA4T |
JA4T is the TCP-layer sibling of [JA4 TLS fingerprinting](/article/ja4-vs-ja3/) inside the wider [JA4+ fingerprint suite](/article/ja4-plus-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:
```text
<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:
```text
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:
| Kind | TCP option | JA4T relevance |
|---:|---|---|
| `0` | End of Option List | iOS can expose this at the end of its SYN options |
| `1` | No-Operation padding | Repeats to align the options list on 4-byte boundaries |
| `2` | Maximum Segment Size | Supplies the MSS value used in JA4T part C |
| `3` | Window Scale | Supplies the window-scale value used in JA4T part D |
| `4` | SACK permitted | Common modern-stack capability flag |
| `5` | SACK blocks | Usually appears after loss, not as the initial SYN capability flag |
| `8` | Timestamp | FoxIO notes that Windows omits this while Unix-family stacks commonly send it |
That is why the `2-1-3-1-1-4` segment is not decorative. The repeated `1`s 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.
| Part | Value | Decode |
|---|---:|---|
| A | `64240` | Raw TCP window size from the SYN packet |
| B | `2-1-3-1-1-4` | Ordered TCP option kinds: `2` = MSS, `1` = NOP padding, `3` = Window Scale, `4` = SACK permitted |
| C | `1460` | MSS, the largest TCP payload the sender says it will accept |
| D | `8` | Window scale shift count |
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
| Fingerprint | Layer | First packet it can use | Main signal |
|---|---|---|---|
| JA4T | TCP | SYN | OS TCP stack, path overhead, proxy/VPN/load-balancer clues |
| JA4 | TLS | ClientHello | TLS version, SNI presence, cipher/extension hashes, ALPN |
| JA4H | HTTP | HTTP request | Method, HTTP version, header order, cookies, language, referer shape |
| HTTP/2 fingerprint | HTTP/2 | First HTTP/2 frames | SETTINGS order/values, WINDOW_UPDATE, PRIORITY, pseudo-header order |
Layering is the point. A scraper can use [curl_cffi to mimic browser TLS](/note/tls-fingerprinting-curl-cffi/) 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](/article/bot-detection-2026/) 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:
```text
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:
```bash
sudo python3 ja4tscan.py -p 80 204.79.197.223
```
The corresponding example output is timestamp, source address, and fingerprint:
```text
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](https://github.com/FoxIO-LLC/ja4) — canonical JA4+ family list, tool support, and technical detail diagrams for JA4T/JA4TS/JA4TScan.
- [FoxIO JA4T: TCP Fingerprinting](https://blog.foxio.io/ja4t-tcp-fingerprinting) — primary explanation of the JA4T design, TCP fields, MSS/path behavior, proxy/VPN effects, and JA4TScan use cases.
- [FoxIO JA4TScan repository](https://github.com/FoxIO-LLC/ja4tscan) — 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`](https://github.com/FoxIO-LLC/ja4/blob/main/zeek/ja4t/main.zeek) — reference construction of passive `ja4t` and server-side `ja4ts` strings from captured packets.
- [RFC 9293: Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) — TCP standard reference for the SYN handshake, window field, options, MSS, and Window Scale context.
- [JA4 vs JA3: Why TLS Fingerprinting Migrated](/article/ja4-vs-ja3/) — companion entry for the TLS-layer JA4 format.