What is P0F?
p0f is a passive OS fingerprinting tool that identifies the system behind a connection by watching traffic rather than probing it. It reads TCP SYN packets for initial TTL, window size, MSS, the order of TCP options and a set of quirk flags, then matches them against a signature database. It sends nothing to the host it identifies.
p0f reads packets from a live interface or a pcap file through libpcap and never transmits. Michał Zalewski wrote it, and version 3 is the current rewrite. Most of the signal comes from the TCP SYN: the observed TTL, from which the tool infers the initial value (64 on Linux and macOS, 128 on Windows) and the hop count; the advertised window, often stored as a multiple of MSS; the MSS itself; the exact order of TCP options such as MSS, SACK-permitted, timestamps, NOP padding and window scale; and quirk flags for unusual header states.
Version 3 fingerprints at the application layer too, matching HTTP request and response signatures by header order and value shape. It derives extras from the same traffic, including system uptime from TCP timestamp counters and a guess at the uplink type from MSS, since a PPPoE or mobile path leaves a smaller MTU than plain Ethernet. Signatures live in a plain-text database that you can extend with your own captures, and results are reported as exact or fuzzy matches with a confidence note.
TCP terminates at a proxy, so a website fingerprints the exit node's stack rather than yours. A datacenter proxy presents a Linux server, with an initial TTL of 64 and an option layout that contradicts a Windows or iOS User-Agent. An exit running on a real phone, or on a device attached to a carrier link, produces the stack and the smaller MTU that path would produce anyway. PROXIES.SX runs a p0f tester that reports what a server reads from your connection, which is one way to compare it against the OS your headers claim.
Passive fingerprinting is best effort. NAT hides many hosts behind one visible stack, and firewalls, load balancers and TCP normalisers rewrite window scaling or reorder options, so the shape reaching the server can belong to a middlebox. Signature databases age against new kernel defaults. QUIC sidesteps the method completely, because HTTP/3 rides on UDP and carries no TCP options to read. Treat a p0f result as one moderate signal alongside TLS and browser fingerprints.
Where you meet it
You meet p0f indirectly, as the OS-mismatch line in an anti-fraud report or a proxy-check page that names your operating system correctly when you assumed the proxy hid it. It is also worth running in reverse, on your own traffic, to see whether an exit looks like a phone or like a rented Linux box. That single answer explains a lot of blocks that otherwise look random.
Common questions
Can a proxy hide my operating system from p0f?
An HTTP or SOCKS proxy opens its own TCP connection to the target, so the server fingerprints the exit machine instead of yours. A routed VPN forwards your packets, so your own TCP options and window values still reach the server. Either way the reported OS can contradict your User-Agent.
Does p0f send packets to the host it fingerprints?
No. It only reads traffic that already passes the interface or sits in a pcap file, which is what passive means here. Nmap's OS detection is the active alternative: it sends crafted probes and reads the replies, which is more precise and visible to the target.
How accurate is p0f?
It is good at broad families such as Linux, Windows, macOS and BSD, and weaker at exact versions, especially where a middlebox rewrites TCP options or a signature database has not kept up with recent kernel defaults. Use it as corroboration rather than as a single source of truth.
Related terms
Real 4G/5G mobile and residential IPs
PROXIES.SX runs carrier IPs in 100+ countries with HTTP and SOCKS5 on every endpoint. $4/GB down to $2.40/GB at volume, free endpoints and rotation, and your GB never expire.