TCP fingerprinting and port scans: what they can and cannot tell you about a proxy
TCP/IP stack fingerprints, open proxy ports and their limits — and why an HTTP-side check cannot replace them.
What the old tools did
Tools like p0f classify an operating system from TCP/IP header details: initial TTL, window size, options order, MSS. A proxy relaying traffic can leave a stack signature that differs from the browser's claimed OS.
Port scans add another signal: open 8080 / 3128 / 1080 suggests a proxy daemon, and a transparent proxy often leaves distinctive headers.
Why it is weaker than it sounds
- Middleboxes rewrite headers. NAT, load balancers and CDNs normalise TTL and options; the original fingerprint disappears.
- The stack may be the proxy's, not the user's. A residential proxy can run on a normal Linux host with a plausible stack — and many modern proxies use TLS termination that hides everything.
- HTTP-only checks cannot see it. From a web request you get headers, not SYN packets. Anything claiming a TCP fingerprint from an HTTP call is guessing.
- False positives are common. Mobile networks and CGNAT mangle stacks; a mismatch does not imply a proxy.
Where it still helps
- Server-side scanner with a real socket: useful for spotting open proxy daemons on a pool you control.
- Consistency checks: claimed OS vs observed stack is a valid weak signal when nothing else contradicts it.
What we do instead
Our verdict uses what can be observed from data plus the request itself: ASN type, hosting/CDN flags, Tor exit list, and the browser consistency checks. We do not claim TCP fingerprints we cannot see. If a vendor tells you they fingerprint TCP from a browser API call, ask them which packets they captured.