TL;DREvery connection exposes a layered set of fingerprints that are supposed to agree with each other: the TCP/IP stack (TTL, window, MSS), the TLS ClientHello (JA3/JA4), HTTP/2 frame order, and the JS environment (timezone, language, WebRTC). A clean IP does not help if these layers contradict one another — the IP is only one signal among many.
The connection is a stack of fingerprints
When a client connects, it reveals independent signals at every layer, from the IP packet up to the browser environment. These are supposed to be internally consistent — a real Chrome on a real Windows machine produces one coordinated set of values. Inconsistency between layers is the strongest signal a detector has.
A landmark measurement (Eckersley, PETS 2010) found that browser configuration alone — no IP, no cookies — carried at least 18.1 bits of entropy and uniquely identified 83.6% of browsers. The signals beyond the IP are, by themselves, enough to single you out.
TLS fingerprint (JA3 / JA4)
The TLS ClientHello is generated by the underlying TLS library, entirely independent of the User-Agent header. JA3 hashes the ClientHello's version, cipher suites, extensions and curves; JA4, its 2023 successor, sorts the cipher and extension lists before hashing so that randomising their order no longer evades it.
This is why a request claiming to be Chrome but carrying a Go or Python library's ClientHello can be rejected before it sends a single byte of content. A 2019 study of 11.8 billion TLS connections found that non-browser tools posing as browsers had TLS configurations easily distinguished from the traffic they tried to imitate.
The TCP/IP stack (p0f) and tunnel tells
Passive tools like p0f infer the operating system from the TCP/IP stack alone — initial TTL, TCP window size, MSS, option order, the DF bit. Different OSes have different defaults: initial TTL is 64 on Linux/macOS, 128 on Windows.
Two tells expose tunnels and NAT. TTL decrements by one per hop, so hop count ≈ initial TTL − observed TTL; a value that doesn't match a claimed direct connection reveals an intermediary. And tunnel encapsulation forces a smaller MSS — WireGuard's default tunnel MTU is 1420 against a normal 1500, so an unusually small MSS advertises that something is wrapped underneath.
WebRTC and DNS — the two classic leaks
WebRTC gathers ICE candidates over UDP, and its STUN request returns the public IP the STUN server sees. Because HTTP proxies don't carry UDP, that request can bypass a proxy and expose the underlying connection. Modern Chrome's mDNS obfuscation hides the local IP behind a random .local name but does not hide the public IP from STUN — the one that actually matters.
A DNS leak is the resolution-path equivalent. DNS is resolved at the OS layer, often before routing, so a query can escape a tunnel and reach a resolver whose location contradicts the exit IP. A site can detect this with a unique subdomain and see which resolver actually queried it.
Timezone, language and HTTP layer
The browser timezone and language come from the operating system, not the network. A VPN changes the IP but not these — so a US IP paired with an Asia/Shanghai timezone, an eight-hour gap, is a contradiction. Notably, a partial fix (correcting the timezone but not the language) looks more like automation patching itself than a real person.
At the HTTP layer, browsers send headers and HTTP/2 pseudo-headers in a fixed order that differs by browser (Chrome m,a,s,p; Firefox m,p,a,s) and matches no generic library. Which HTTP/2 SETTINGS parameters are present is itself part of the fingerprint.
Why a clean IP isn't enough
Modern anti-fraud runs a cross-layer consistency check, not an IP blocklist lookup. A clean residential IP does nothing if the TLS fingerprint is a library's, the HTTP/2 order isn't the claimed browser's, the timezone is eight hours off, or WebRTC and DNS leak a different origin. Any one contradiction is enough.
This is the honest core of the whole topic: the IP is one signal among many, and no amount of address quality compensates for an inconsistent stack. It is also why we sell an address, not a promise about outcomes on any third-party platform.
Frequently Asked Questions
What is a TLS fingerprint (JA3/JA4)?
A hash of the TLS ClientHello — its version, cipher suites, extensions and curves — generated by the client's TLS library independent of the User-Agent. JA4 sorts the lists before hashing so reordering can't evade it. A mismatch between the claimed browser and the fingerprint exposes automation.
Can a website see my real IP even behind a proxy?
Sometimes, through WebRTC. Its STUN request runs over UDP, which HTTP proxies don't carry, so it can return your underlying public IP. Modern browsers hide the local IP via mDNS but not the public one from STUN.
Why do I get flagged even with a clean residential IP?
Because detection is a cross-layer consistency check. If the TLS fingerprint, TCP/IP stack, HTTP/2 order, timezone, WebRTC or DNS contradict each other or the claimed browser, a clean IP doesn't help — the IP is only one signal among many.
What is a DNS leak?
When DNS resolution escapes a tunnel and reaches a resolver whose location contradicts your exit IP. Because DNS is resolved at the OS layer, often before routing, the query can take a different path — and a site can detect it by seeing which resolver queried a unique subdomain.
Updated 2026-08-25 · Back to Guides · View plans →