TLS (JA3/JA4) and TCP Fingerprinting

A TLS fingerprint is a summary of the ClientHello, the first message a client sends when it opens an HTTPS connection. Every TLS library builds that message its own way: which TLS versions it offers, which cipher suites and in what order, which extensions, which elliptic curves. Chrome, Firefox, Safari, curl, Python's ssl module and Go's crypto/tls each produce a recognizable pattern, and the pattern stays the same whatever IP the client uses or which site it visits. Cloudflare describes the fingerprint as "a stable identifier across different destination IPs, ports, and certificates" (Cloudflare: JA3/JA4 fingerprint).

That stability is why it catches scrapers. A script can send a Chrome User-Agent header in one line of code, but its handshake still comes from its own TLS library. When the header says Chrome and the handshake says Python, the request contradicts itself.

JA3 turns the ClientHello into an MD5 hash. It takes five fields, in this order: the TLS version, the cipher suites, the extensions, the elliptic curves and the point formats; it joins their decimal values into one string and hashes it into 32 characters (salesforce/ja3). JA3S does the same for the server's reply.

JA3 was created at Salesforce in 2017 by John Althouse, Jeff Atkinson and Josh Atkins. The repository was archived on 1 May 2025 and is no longer maintained by Salesforce; the work continues as JA4.

JA3's weak point is that it hashes the extensions in the order they were sent. When Chrome began randomizing the order of its TLS extensions, one Chrome version started to produce many JA3 hashes, which made JA3 less useful for recognizing browsers.

JA4 fixes that by sorting the ClientHello extensions before hashing, which reduces the number of distinct fingerprints a modern browser produces (Cloudflare: JA3/JA4 fingerprint). It is also readable: the first part of a JA4 string shows the protocol, TLS version, number of ciphers and extensions, so you can tell a lot before you look up the hash.

JA4 belongs to JA4+, a suite of fingerprints by FoxIO (FoxIO-LLC/ja4):

JA4 itself is open source under the BSD 3-Clause license. The other JA4+ methods are licensed under the FoxIO License 1.1, which the README says is not permissive for monetization.

On Cloudflare, a JA4 fingerprint is a property of each HTTPS request that site owners on Enterprise Bot Management can see and act on. Cloudflare's documentation says JA3 and JA4 fingerprints "are only available to Enterprise customers who have purchased Bot Management" (Cloudflare). Site owners can:

• view the fingerprints in Bot Analytics, Security Events and logs;
• write WAF custom rules that block, challenge or skip a fingerprint;
• use JA4 Signals in Workers, which summarize how a fingerprint behaves across Cloudflare's traffic.

The same page notes the limits: there is no fingerprint for plain HTTP traffic, and with TLS session resumption no new fingerprint is calculated after the first handshake. Cloudflare also lists JA3/JA4 among the inputs of its bot detection, next to the bot score; see why Cloudflare thinks you are a bot.

TCP/IP fingerprinting identifies the operating system that opened a connection from the first packets, without any code on the client. The SYN packet that starts a TCP connection carries values that each OS sets its own way: the initial TTL, the window size, the maximum segment size (MSS) and the order of TCP options. Tools such as p0f read these passively, and JA4T turns them into a fingerprint.

Through a proxy, the TCP fingerprint is not yours. The site's TCP connection comes from the proxy's exit, so the site sees that machine's network stack. This is how TCP fingerprinting can point to a proxy: if the User-Agent and the TLS handshake say Windows and Chrome but the TCP stack looks like a Linux server, the request does not add up. How much weight each anti-bot system gives this is not published.

No. An HTTP proxy that uses the CONNECT method, and a SOCKS5 proxy, pass your encrypted bytes through without reading them, so the site sees your client's ClientHello exactly as your client sent it. The proxy changes the IP and the TCP connection, not the TLS layer.

A VPN forwards your packets, so the TLS fingerprint and most of the TCP fingerprint stay those of your device; the tunnel can still show, for example in a smaller MSS. The one exception is a proxy that terminates TLS itself and opens a new connection to the site: then the site sees the proxy's TLS library, and you must trust the proxy with your decrypted traffic.

Clean residential IPs fix reputation-based blocks; they cannot fix a handshake that gives your client away. The typical failure looks like this:

• The same URL loads in Chrome on your own connection, but returns 403 or a challenge to your script, even through residential IPs.
• Changing the User-Agent and adding browser headers makes no difference, or makes it worse.
• A real browser driven by Playwright through the same proxy passes.

Each of those points to the TLS (or HTTP/2) layer. The fix is to make the handshake match the browser you claim to be, which there are two ways to do:

Match the rest too: if you impersonate Chrome, send Chrome's headers in Chrome's order, and keep cookies within the session. Headers are covered in HTTP headers for web scraping.

This script sends one request with Chrome's TLS and HTTP/2 fingerprint through the ProxyField gateway and prints what a TLS echo service saw. Install it with pip install curl_cffi, then replace <login> and <password>.

from curl_cffi import requests

proxy = "http://<login>-country-us-city-new_york:<password>@gate.proxyfield.io:7000"

r = requests.get(
    "https://tls.browserleaks.com/json",
    impersonate="chrome",          # the latest Chrome profile the library ships
    proxies={"http": proxy, "https": proxy},
    timeout=30,
)
data = r.json()
print("status:", r.status_code)
print("ja3:", data.get("ja3_hash"))
print("ja4:", data.get("ja4"))
print("user agent:", data.get("user_agent"))

Run the same request with plain requests and compare: the IP stays the proxy's in both cases, while the JA3 and JA4 values change with the client. To keep one IP for a whole session, use a sticky session (30 s to 36 h): -region-<region>, -session-<id> and -ttl-<seconds> (30 to 129,600 seconds, 20 minutes by default) after the location, as in <login>-country-us-region-new_york-city-new_york-session-he9f2qga-ttl-600. The Python setup for the gateway in general is on the Python proxy integration page.

HTTP/2 adds a second fingerprint above TLS. Browsers open an HTTP/2 connection with their own SETTINGS values, window sizes, priority behavior and pseudo-header order, and libraries differ from them just as they do in TLS. JA4H covers the HTTP side, including header order. An impersonating client such as curl_cffi matches HTTP/2 as well as TLS; a client that matches only TLS can still be caught here.

Proxies for the IP layer, any client on top. ProxyField residential proxies work with real browsers and impersonating clients over HTTP, HTTPS and SOCKS5, with per-request rotation or sticky sessions up to 36 h. From $1.95/GB, no subscription; start with the Easy Trial (1 GB). Traffic never expires, and all purchases are final.