TLS, HTTP/2 and TCP fingerprint
The JA3 / JA4 fingerprint of your TLS ClientHello, the HTTP/2 SETTINGS and header order, the TCP SYN (JA4T) and the round trips — and whether all of them match the browser and OS your User-Agent claims.
What to do about it
TLS shape ≠ User-Agent
The TLS stack cannot be changed in settings. Use the engine the User-Agent names, or accept that Cloudflare, Akamai and DataDome see the real one before reading a single header.
Unknown TLS stack
A ClientHello that matches no browser means TLS is not opened by the browser: a TLS-terminating proxy, an HTTP library, or a network layer that re-originates connections. Switch to a CONNECT proxy or a VPN.
Wrong TCP stack
A Linux SYN under a Windows User-Agent is the signature of a SOCKS/HTTP proxy on a Linux host. Only a VPN or TUN-level tunnel keeps your own TCP stack on the wire.
Extra round trip
Latency between TCP and TLS is the proxy hop. It cannot be hidden by configuration; a proxy geographically close to you shrinks it.
How this test works
The edge process accepts the TCP connection, reads the raw ClientHello before handing the socket to TLS, and computes JA3 and JA4 from the cipher suites, extensions, groups and signature algorithms. It records the HTTP/2 SETTINGS frame, the first WINDOW_UPDATE and the pseudo-header order of the first request, measures the TLS handshake round trip, and, with packet capture, reads the TCP SYN for TTL, window, MSS and option layout (JA4T). All of it travels to the app as trusted request headers.