your connection

TCP fingerprint and passive OS detection from your own packets

IPv432-bit
IPv6128-bit
Weighing what this connection revealed…
Waiting for the connection capture…

TCP fingerprint and passive OS detection

The first packet of a TCP connection, the SYN, carries choices the operating system makes on its own: initial TTL, window size, maximum segment size and the order of TCP options. Passive OS fingerprinting (p0f) matches these against known stacks, and JA4T writes them in a comparable form. Nothing is asked of the browser; the guess comes from the packet alone.

The live socket adds what the kernel knows about your connection: round-trip time, congestion window, MSS and path MTU, plus behaviour such as ECN, timestamps and window scaling. The handshake timeline shows each packet of the connection setup as it hit the network card, and the captured packets open as a hex dump.

What is passive OS fingerprinting?

Every operating system fills in the first TCP packet a little differently: the initial TTL, the window size, the maximum segment size, whether it uses window scaling, selective acknowledgements and timestamps, and in which order those options appear. p0f compares your SYN with a database of known stacks. The browser is never asked; the guess comes from the packet alone.

What is JA4T?

JA4T writes the TCP part of that fingerprint in a comparable form: window size, the option order, the maximum segment size and the window scale factor, separated by underscores. Two devices running the same operating system version normally share it, and a VPN or proxy that opens its own TCP connection replaces it with the relay's.

What does the initial TTL reveal?

Operating systems start their packets with a fixed time-to-live: 64 on Linux, macOS, iOS and Android, 128 on Windows, 255 on some network gear. Every router on the way subtracts one, so the value that arrives here gives both the likely family and the number of hops between your device and this server.

Why is the operating system guess wrong?

The SYN was not written by your device. A VPN or proxy terminates your connection and opens a new one from its own server, carrier-grade NAT and some firewalls rewrite TCP options, and a few middleboxes normalise packets deliberately. A guess that contradicts what the browser reports is one of the checks the overview's verdict weighs.

What is TCP_INFO?

The Linux kernel keeps statistics for every socket, and this page reads them for the connection your browser opened: round-trip time and its minimum, the congestion window, MSS and path MTU, retransmissions, the peer's receive window, delivery and pacing rate, and whether ECN marks were seen. They describe your actual connection, not a synthetic test.

What does the handshake timeline show?

Every packet of the connection setup as it reached the network card, with the time between them: SYN, SYN-ACK, ACK, the TLS ClientHello and the server's reply. The gaps are round trips on the wire, so the timeline shows where the time went before the first byte of the page, and whether your stack sends data early.

Related terms: Passive OS fingerprinting, TCP handshake, JA4T, Maximum segment size, Congestion window, TCP_INFO