Every developer eventually learns to rotate the User-Agent header. Fewer learn that User-Agent is the easiest field to lie about — and therefore the least trusted on the receiving end. Modern bot detection runs a layer lower: it fingerprints the TLS ClientHello, the TCP options, and the exact byte ordering your stack puts on the wire. Most of that is set by your OS and your TLS library, not your code, so it is much harder to fake.
TL;DR: A proxy changes your exit IP, but it does not change your TLS fingerprint. If your scraper runs Python on Linux, every connection carries a Python JA3 and a Linux TCP fingerprint — regardless of which carrier IP it exits from. Nodetonet's TCP fingerprint spoofing rewrites that at the edge so the target sees a real browser instead of automation tooling.
The fingerprints that matter
Three families dominate, and all are computed before a single HTTP byte is exchanged:
- JA3 — a hash over the TLS ClientHello: TLS version, cipher suite order, extension list, elliptic curves. Stable per stack:
curlon macOS has one JA3, Chrome on Windows has another, Pythonrequestshas yet another. - JA4 — JA3's successor; more structured and harder to collide intentionally. Major CDN bot products (Cloudflare, Akamai, PerimeterX) all surface JA4 alongside JA3 as of 2025.
- TCP fingerprint — OS level. SYN window size, MSS, TCP options order, initial TTL. This is what
p0fuses to tell Linux from Windows without reading a single application byte.
None of these change when you route through a standard proxy. If your tool is Python on Linux, every connection it makes carries a Python JA3 and a Linux TCP fingerprint — regardless of which exit IP it appears from. To the target, "Chrome User-Agent on a mobile carrier IP but Python's JA3" is a four-alarm fire. The IP reputation buys you nothing if the TLS hello gives you away immediately.
To verify what a target actually sees from your current connection, use our free What is my IP tool — it surfaces IP, ASN and carrier info in one click. For a reference on how CGNAT carrier IPs earn their trust level, see the carrier-grade NAT glossary entry.
What the fingerprint comparison looks like in practice
| Stack | JA3 / JA4 result | TCP signature | Bot-detection verdict |
|---|---|---|---|
Python requests (urllib3 + OpenSSL) |
Well-known automation hash | Linux default window / MSS | Flagged immediately on hardened targets |
Node.js fetch / axios |
Node TLS hash — distinct from browsers | Linux or Windows defaults | Flagged on most CDN bot products |
| Headless Chromium (Puppeteer / Playwright) | Matches real Chrome — passes JA3/JA4 | Matches OS Chrome runs on | Passes unless behavioural signals betray it |
| Any tool + Nodetonet fingerprint spoofing | Rewritten to chosen browser profile | Rewritten to match chosen OS | Indistinguishable from that browser at TLS/TCP level |
What Nodetonet rewrites for you
On any proxy you can toggle TCP fingerprint spoofing in the advanced settings panel. When enabled, the edge node tears down the incoming connection at the application boundary and re-establishes the outbound connection with a fresh ClientHello that matches the chosen profile. Available profiles include:
- Chrome 121 on Windows 11
- Chrome 120 on Android 14
- Safari 17 on macOS Sonoma
- Safari Mobile on iOS 17
- Firefox 123 on Linux
The rewrite covers JA3, JA4, ALPN order, the GREASE values real browsers inject, the exact extension permutation Chrome ships this quarter, and the TCP window scaling and MSS that the underlying OS would set. From the target's perspective, the connection is indistinguishable from the selected browser running on that platform.
This is most valuable when your exit IP is already trustworthy — for example a mobile proxy on a real carrier network — and the only remaining signal that exposes automation is the TLS layer itself. It pairs naturally with rotating proxy pools: fresh IPs across a pool plus a consistent, browser-matching TLS fingerprint removes two of the three primary detection vectors simultaneously. The third — behavioural signals in the browser — requires a fully browser-based client like Playwright and is outside the scope of network-layer spoofing.
Fingerprint spoofing also complements SOCKS5 proxies for HTTP/HTTPS traffic, though note the limitation described in the next section.
What it cannot do
Spoofing is necessary but not sufficient on its own. The same target that inspects your ClientHello is almost certainly also checking:
- HTTP/2 frame order. Chrome sends SETTINGS, WINDOW_UPDATE, HEADERS in a specific sequence.
requestsand most HTTP libraries do not. Nodetonet rewrites this for HTTP and HTTPS tunnels; SOCKS5 carries your original frames transparently by design — the rewrite cannot reach inside an encrypted SOCKS5 stream. - Header order and casing. The order of your request headers is itself a fingerprint. Use a browser-emulating client like
curl-impersonateor Playwright to fix this at the source before it reaches the proxy. - Behavioural signals. Mouse movement, dwell time, scroll velocity, canvas entropy. These are JavaScript-land and no network rewrite can touch them. If a target relies heavily on these, headless browser automation with stealth plugins is the right layer to address them.
- TLS certificate pinning. If the target app pins the server certificate, a separate challenge arises at the client side. See SSL pinning and your proxy for a full treatment.
Treat TCP fingerprint spoofing as the floor, not the ceiling. It plugs the TLS-layer leak that nothing else plugs, but it will not turn a headless scraper into a real user on its own. Use it as one layer of a defence-in-depth approach: real carrier IP + clean TLS fingerprint + human-like request pacing + sticky sessions for stateful flows.
When to turn it on — and when to leave it off
The rewrite adds roughly 20–40 ms of one-time handshake overhead per new TCP connection, because the edge must perform a fresh outbound TLS negotiation. For long-lived connections this is invisible. For high-frequency, short-burst patterns (many requests per second, each on a fresh socket) the overhead accumulates. If your target does not fingerprint TLS — most plain APIs and internal tooling do not — leave it off and save the latency.
Targets that historically fingerprint aggressively: e-commerce platforms, travel aggregators, social networks, and anything fronted by Cloudflare Bot Management, Akamai Bot Manager or PerimeterX. For those, enable it by default. You can also run a quick diagnostic by first sending a request without spoofing and checking whether the proxy checker or the target's response changes when you enable it — that tells you instantly whether the site is actively inspecting TLS.
Where fingerprint spoofing fits in the wider anti-detection stack
A robust anti-detection setup typically combines several independent layers. Here is how TCP fingerprint spoofing fits alongside other Nodetonet features:
- Clean IP reputation — start with a mobile proxy on a real carrier. A mobile IP from CGNAT is the hardest type for anti-bot vendors to block without collateral damage.
- Carrier and geo matching — use geo-targeting to match the carrier and city your target audience expects. A Turkish e-commerce site is suspicious of a French carrier IP.
- TLS fingerprint spoofing (this feature) — rewrites JA3, JA4, ALPN, GREASE and TCP stack at the edge.
- Session continuity — use sticky sessions to keep the same IP across a login or checkout flow. Rotating mid-session looks like account takeover.
- Per-client controls — lock each customer or automation task to its own credentials, IP allowlist and quota so a rogue client cannot harm others. See proxy clients and per-customer auth.
None of these layers replaces the others. Used together, they address IP reputation, geographic plausibility, TLS identity, session consistency and access control in one platform.
Related reading
- SSL pinning and your proxy — what happens when the target app pins certificates and how to handle it.
- HTTPS proxies and SNI routing — how Nodetonet avoids MITM by routing on SNI rather than decrypting traffic.
- When to use rotating mobile proxies — combine fingerprint spoofing with IP diversity for maximum coverage.
- Sticky sessions explained — when to pin a session and how the
-session-XXXXsuffix works. - HTTP vs SOCKS5 — which to pick — understand the protocol-level trade-offs before choosing where to apply fingerprint rewriting.