TCP/IP fingerprinting
Your network stack speaks before the page loads.
The first TCP packets can expose defaults chosen by the operating system: hop limits, window behavior, segment size, flags, and option order. A server can inspect that pattern before browser-side JavaScript ever runs. That network-stack evidence can reinforce alarger browser and device profile.
- Observed at
- Network edge
- First clue
- TCP SYN
- Common use
- OS classification
- Encrypted by HTTPS
- No
Where the signal lives
The webpage cannot read these headers. The network can.
Browser JavaScript is sandboxed away from raw TCP/IP packets. The destination, CDN edge, reverse proxy, firewall, or an on-path observer may still inspect the unencrypted transport metadata.
HTTPS protects application content. It does not hide IP and TCP header fields required to deliver the connection.
Packet anatomy
A fingerprint is assembled from fields and relationships.
No single number reliably identifies an operating system. Tools compare combinations: values, option order, mathematical relationships, quirks, and how those observations change over time.
64TTL
Decreases at each routed hop. Observers often estimate the original value from common starting points.
setDon’t Fragment
A flag associated with path MTU discovery. Its presence and related IP ID behavior can become a clue.
64,240Window
The advertised receive window and its relationship to MSS or window scaling can reflect stack defaults.
1,460MSS
The maximum TCP payload offered by the endpoint. Tunnels and middleboxes may clamp it.
7Window scale
Expands the effective receive window. Values and placement vary between implementations.
MSS · SACK · TS · NOP · WSOrder
Ordering is especially useful because compliant stacks can arrange legal options differently.
Signature explorer
Different stacks make different legal choices.
Switch between illustrative profiles to see how the combination changes. These are teaching examples, not canonical signatures for every release or device.
Unix-like client
A common Unix-like arrangement: an initial TTL near 64 with timestamp, selective acknowledgment, and window-scale options. Many kernels and versions can overlap this pattern.
A reliable classifier uses a signature database and tolerates path changes. Matching one row is not proof of an exact OS.
TTL is a path measurement too
The observer sees what remains after every hop.
An arriving TTL of 51 does not mean the client started at 51. A classifier may infer a common starting value of 64 and estimate roughly 13 routed hops. It is a heuristic: routes change, tunnels add complexity, and starting values are not unique to one OS.
Common across Unix-like and mobile-derived stacks
Often associated with Windows-family defaults
Common in some network appliances and routing systems
The path leaves fingerprints too
The packet can change between the device and the destination.
Passive fingerprinting observes the endpoint through the network path. Good analysis distinguishes likely client defaults from fields altered by routers, tunnels, NAT, firewalls, and proxies.
- 01
Client stack
TTL 64 · MSS 1460The operating system creates the SYN and chooses its initial fields and TCP option order.
- 02
Router hops
TTL 63 → 62 → …Each routed hop reduces TTL. The destination sees the remaining value, not the original.
- 03
NAT or firewall
source address rewrittenAddress, port, and checksums may change. Some devices also normalize or drop uncommon fields.
- 04
Tunnel or middlebox
MSS may be clampedEncapsulation can reduce usable packet size. A terminating proxy creates an entirely new downstream connection.
- 05
Observer
post-path signatureThe server or edge service classifies what arrived, including changes introduced along the way.
Changes the route, not necessarily the TCP origin.
A conventional VPN hides the public IP and encapsulates traffic. After decapsulation, portions of the client-generated TCP signature may still reach the destination.
Creates a new downstream connection.
An HTTP proxy, reverse proxy, or Tor exit can terminate one connection and originate another. The next observer sees the intermediary’s TCP stack.
Passive and active methods
p0f watches a connection. Nmap asks the stack questions.
p0f can work from as little as an ordinary SYN. It pays attention to option order, MSS-to-window relationships, timestamps, quirks, and signals of NAT or proxying—without probing the client.
observe → normalize → compare → estimateNmap sends multiple TCP, UDP, and ICMP probes and examines response details such as sequence behavior, TCP options, window sizes, and IP ID patterns. It works best when it can find both open and closed ports.
probe → observe responses → score matchesThese methods answer related but different questions. A website commonly has passive access to the arriving connection; active Nmap-style OS detection targets a remotely reachable host and may be disrupted by NAT, firewalls, or load balancers.
Research tools
Capture, classify, and then verify the limits.
p0f
SYN → signature databaseObserves ordinary connections and can classify operating-system families, link type, distance, and connection-sharing clues without sending probes.
Nmap
crafted probes → response setSends TCP, UDP, and ICMP probes, then compares response behavior—including option order, window values, IP ID, and sequence traits—to known fingerprints.
Wireshark / tcpdump
capture → decode fieldsShows the packets and header fields directly. These tools collect evidence; they do not automatically make every OS inference reliable.
What actually changes the signal?
Changing identity at one layer does not replace every layer.
Neither action replaces the operating system’s TCP/IP stack.
Browsers usually rely on the same host networking stack, though protocol choices can differ.
Hop count, MTU, and middleboxes can change while endpoint defaults remain recognizable.
IP and route change; the client may still originate the TCP behavior visible after decapsulation.
The intermediary opens a new TCP connection, so the destination sees its stack rather than the original client stack.
The component choosing the packet defaults has changed.
Read the result carefully
A network fingerprint classifies a stack, not a person.
Packet behavior can narrow an operating-system or device family and expose inconsistencies between layers. It becomes identity evidence when an observer correlates it with IP history, TLS, HTTP, account activity, or browser-side signals.
combined resultmore confidence than any layer alone