TLS Impersonation with curl_cffi: Beating JA3/JA4 Fingerprinting in 2026

Every time your Python HTTP client opens a TLS connection, it broadcasts a ClientHello message that anti-bot vendors silently hash into a fingerprint. If you are using requests, urllib3, or httpx with the default OpenSSL backend, that fingerprint does not match any real browser — and sophisticated WAFs like Cloudflare, Akamai, and DataDome will block you before you send a single HTTP byte. TLS Impersonation with curl_cffi solves this by compiling curl against BoringSSL and replaying Chrome's exact ClientHello byte-for-byte, but it is only half the equation: a perfect TLS fingerprint over a datacenter IP still trips reputation scoring. This guide covers the full stack — from JA3/JA4 internals to a runnable curl_cffi + ProxyHat residential proxy example.

How Anti-Bot Systems Read Your TLS Stack

The TLS handshake begins with the client sending a ClientHello record. This message is sent in cleartext before encryption is negotiated, which means any network observer — including the CDN terminating your connection — can inspect every field. Anti-bot vendors exploit this by hashing selected fields into a compact fingerprint and comparing it against known browser profiles.

JA3: The Original TLS Fingerprint

JA3, introduced by Salesforce in 2017, hashes five fields from the ClientHello into a 32-character MD5:

• SSLVersion — the TLS version offered (e.g., TLS 1.3 = 771, TLS 1.2 = 770).
• Ciphers — the ordered list of cipher suites, e.g., TLS_AES_128_GCM_SHA256(4865),TLS_AES_256_GCM_SHA384(4866),TLS_CHACHA20_POLY1305_SHA256(4867).
• Extensions — the ordered list of TLS extensions, e.g., 0,23,65281,10,11,35,16,5,34,51,43,45,13,0,50.
• Elliptic Curves — supported groups like x25519(29),secp256r1(23),secp384r1(24).
• EC Point Formats — typically 0 (uncompressed) or empty.

These five values are concatenated with commas, hashed with MD5, and the result is your JA3 hash. The key insight: the order of ciphers and extensions matters. Two clients with the same cipher suites in a different order produce different JA3 hashes. OpenSSL-based Python clients have a characteristic cipher ordering that no real browser uses, so their JA3 hash is immediately recognizable as non-browser traffic.

You can browse the full JA3 specification and the original research on the JA3 GitHub repository.

JA4: Order-Stable Fingerprinting

In 2023, FoxIO introduced JA4 to address a critical weakness in JA3: Chrome 110+ began permuting its extension order on every connection as a deliberate anti-fingerprinting measure. This meant the same Chrome instance produced a different JA3 hash on each request, making JA3 unreliable for browser identification.

JA4 solves this by sorting extensions and cipher suites before hashing. The format is JA4_T_XX_OS where:

• T = transport (TCP = t, QUIC = q)
• XX = TLS version (d13 for TLS 1.3, d12 for TLS 1.2)
• O = SNI present (d) or absent (i)
• S = number of ciphers, sorted and hashed

The critical difference: JA4 sorts extensions alphabetically and ciphers numerically before hashing, so a browser that shuffles extension order still produces the same JA4 hash. You can read the full JA4 specification at FoxIO's JA4 repository.

What Makes a Python ClientHello Scream "Not a Browser"

When you use requests or httpx with the default OpenSSL backend, several signals immediately identify the connection as non-browser:

GREASE (RFC 8701) deserves special attention. Google engineers deliberately inject reserved, meaningless values — like cipher 0x0a0a or extension 56026 — into ClientHello fields. These values serve no cryptographic purpose; they exist to ensure middleboxes and fingerprinting systems do not choke on unknown values. A ClientHello without GREASE is a strong signal that the client is not Chrome, Firefox, or Safari. The IETF RFC is available at RFC 8701.

How curl_cffi Replicates Chrome's TLS Fingerprint

curl_cffi is a Python binding to curl-impersonate, a fork of curl compiled against BoringSSL (Google's TLS library used in Chrome) instead of OpenSSL. BoringSSL is the critical piece: it produces the same ClientHello structure as Chrome because it is Chrome's TLS stack, with the same default cipher ordering, extension list, and GREASE injection logic.

The impersonate Presets

curl_cffi exposes a simple impersonate parameter that maps to pre-configured browser profiles:

from curl_cffi import requests

# Synchronous
r = requests.get("https://tls.peet.ws/api/all", impersonate="chrome")
print(r.json().get("tls", {}).get("ja3_hash"))

# Asynchronous
from curl_cffi.requests import AsyncSession

async with AsyncSession(impersonate="chrome") as s:
    r = await s.get("https://tls.peet.ws/api/all")
    print(r.json().get("tls", {}).get("ja4"))

Available presets include chrome (latest), chrome110, chrome116, chrome120, chrome124, chrome131, safari17_0, safari17_2_ios, edge101, and firefox133. Each preset configures:

• The exact cipher suite list and ordering
• The full extension list with correct ordering (or permutation logic for Chrome 110+)
• Supported groups (curves) with GREASE values
• The HTTP/2 SETTINGS frame, WINDOW_UPDATE, and PRIORITY frames
• Default headers that match the browser's User-Agent

JA3, Akamai, and extra_fp Overrides

For fine-grained control, curl_cffi lets you override specific fingerprint components:

from curl_cffi import requests

r = requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome131",
    ja3="771,4865-4866-4867-49195-49199...,0-23-65281-10-11-...,29-23-24,0",
    akamai="1,65536;0,0;0,0;0,0",
    extra_fp={
        "tls_extensions": {"session_ticket": True},
        "http2_settings": {"HEADER_TABLE_SIZE": 65536},
    },
)

The ja3 parameter lets you specify a raw JA3 string (version,ciphers,extensions,curves,ec_formats). The akamai parameter controls the HTTP/2 fingerprint (SETTINGS frame values, WINDOW_UPDATE, PRIORITY). The extra_fp dictionary allows surgical overrides for individual TLS extensions and HTTP/2 settings without rewriting the entire fingerprint.

The HTTP/2 Fingerprint: Akamai's Second Layer

TLS fingerprinting is only the first gate. Once the TLS handshake completes and HTTP/2 is negotiated, anti-bot systems inspect the HTTP/2 SETTINGS frame — the first frame the client sends after the connection preface. This frame contains key-value pairs like HEADER_TABLE_SIZE, ENABLE_PUSH, INITIAL_WINDOW_SIZE, and MAX_CONCURRENT_STREAMS. Chrome, Firefox, and Safari each send a distinct SETTINGS frame, and Akamai's bot detection specifically hashes this frame.

curl_cffi's impersonate="chrome" preset configures the exact SETTINGS frame Chrome sends: HEADER_TABLE_SIZE=65536, ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=6291456, MAX_HEADER_LIST_SIZE=262144. It also sends the correct WINDOW_UPDATE frame (increment = 15663105) and a PRIORITY frame for stream 0 with weight 0. A mismatch in any of these values is a strong non-browser signal.

Chrome 110+ Extension Permutation and Why JA4 Exists

Starting with Chrome 110, Google introduced ClientHello extension permutation as a privacy feature. Before Chrome 110, the extension list in the ClientHello was always in the same order, making JA3 a stable identifier. Chrome 110+ shuffles the order of certain extensions on every new connection while keeping the set of extensions constant.

This broke JA3-based detection: the same Chrome browser would produce dozens of different JA3 hashes depending on the permutation. Anti-bot vendors had two options: maintain a database of all known permutations (combinatorial explosion) or adopt an order-stable fingerprint. JA4 was designed precisely for this — it sorts extensions before hashing, so permutation does not affect the result.

For curl_cffi users, this means:

• Using impersonate="chrome110" or later will produce permuted extensions, which may generate different JA3 hashes per request — this is expected and correct.
• JA4 will remain stable across requests for the same preset.
• Anti-bot systems that still rely on JA3 may flag permuted fingerprints as suspicious if they have not updated their databases — this is a known edge case.

If you need a stable JA3 for testing or compatibility, use impersonate="chrome" which maps to the latest stable preset, or pin to an older preset like chrome107 that does not permute.

Why Residential Proxies Remain Mandatory

A perfect TLS fingerprint is necessary but not sufficient. Modern anti-bot systems layer multiple signals:

1. TLS fingerprint (JA3/JA4) — does the ClientHello match a known browser?
2. HTTP/2 fingerprint — do the SETTINGS and WINDOW_UPDATE frames match?
3. IP reputation — is the source IP a known datacenter, VPN, or residential address?
4. Behavioral signals — does the request pattern look human (mouse movement, scroll, timing)?
5. JS challenges — can the client execute JavaScript and solve CAPTCHAs?

curl_cffi handles signals 1 and 2. But signal 3 — IP reputation — is where datacenter proxies fail catastrophically. Cloudflare, Akamai, and DataDome maintain extensive databases of ASN ranges belonging to AWS, GCP, Azure, DigitalOcean, OVH, Hetzner, and other hosting providers. A request from 34.0.0.0/8 (Google Cloud) with a perfect Chrome TLS fingerprint is still flagged as a bot because real Chrome users do not browse from datacenter ASNs.

Residential proxies solve this by routing traffic through ISP-assigned IPs that belong to real households. A request from a Comcast residential IP in Seattle with a Chrome JA4 hash and matching HTTP/2 SETTINGS frame passes all three network-layer checks. The anti-bot system sees a connection that looks exactly like a real user browsing from home.

According to Cloudflare's own bot management documentation, they score requests on a 1–99 scale where IP reputation, TLS fingerprint, and behavioral signals are weighted together. A datacenter IP can push the score into the 80+ block range regardless of TLS quality. You can read more about their approach at Cloudflare Bot Management docs.

Worked Example: curl_cffi + ProxyHat Residential Exits

Here is a complete, runnable example that combines curl_cffi's TLS impersonation with ProxyHat residential proxies for a robust scraping setup. The example uses an AsyncSession with the chrome131 preset, routes through German residential exits, and includes retry logic with session rotation.

Basic Setup

import asyncio
from curl_cffi.requests import AsyncSession

PROXY = "http://user-country-DE:YOUR_PASSWORD@gate.proxyhat.com:8080"

async def fetch(url: str) -> dict:
    async with AsyncSession(impersonate="chrome131") as session:
        response = await session.get(
            url,
            proxies={"https": PROXY, "http": PROXY},
            timeout=30,
        )
        response.raise_for_status()
        return response.json()

result = asyncio.run(fetch("https://tls.peet.ws/api/all"))
tls_info = result.get("tls", {})
print(f"JA3: {tls_info.get('ja3_hash')}")
print(f"JA4: {tls_info.get('ja4')}")
print(f"User-Agent: {result.get('user_agent')}")

Production Setup with Rotation and Retries

For production scraping, you need session rotation (to distribute requests across different residential IPs) and retry logic (to handle transient failures). ProxyHat supports per-session sticky IPs via the session flag in the username:

import asyncio
import random
import string
from curl_cffi.requests import AsyncSession

PROXYHAT_GATEWAY = "gate.proxyhat.com"
PROXYHAT_PORT = 8080
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"

def make_proxy(session_id: str, country: str = "DE") -> str:
    return f"http://{USERNAME}-country-{country}-session-{session_id}:{PASSWORD}@{PROXYHAT_GATEWAY}:{PROXYHAT_PORT}"

async def fetch_with_retry(
    url: str,
    max_retries: int = 3,
    country: str = "DE",
) -> dict:
    for attempt in range(max_retries):
        session_id = "".join(random.choices(string.ascii_lowercase + string.digits, k=12))
        proxy = make_proxy(session_id, country)
        try:
            async with AsyncSession(impersonate="chrome131") as session:
                response = await session.get(
                    url,
                    proxies={"https": proxy, "http": proxy},
                    timeout=30,
                )
                if response.status_code == 200:
                    return response.json()
                elif response.status_code == 429:
                    await asyncio.sleep(2 ** attempt)
                    continue
                else:
                    response.raise_for_status()
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            await asyncio.sleep(2 ** attempt)
    raise RuntimeError(f"Failed after {max_retries} retries")

# Run multiple requests through different residential IPs
urls = [
    "https://tls.peet.ws/api/all",
    "https://httpbin.org/headers",
    "https://tls.peet.ws/api/all",
]

async def main():
    tasks = [fetch_with_retry(url) for url in urls]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    for i, result in enumerate(results):
        if isinstance(result, Exception):
            print(f"Request {i}: FAILED - {result}")
        else:
            tls = result.get("tls", {})
            print(f"Request {i}: JA4={tls.get('ja4', 'N/A')}")

asyncio.run(main())

SOCKS5 Alternative

If you prefer SOCKS5 (useful for certain tunneling scenarios), ProxyHat supports it on port 1080:

SOCKS5_PROXY = "socks5://user-country-DE-session-myid01:YOUR_PASSWORD@gate.proxyhat.com:1080"

async with AsyncSession(impersonate="chrome131") as session:
    r = await session.get(
        "https://tls.peet.ws/api/all",
        proxies={"https": SOCKS5_PROXY, "http": SOCKS5_PROXY},
    )

Verifying Your Fingerprint

Always verify your TLS fingerprint against a known endpoint before deploying to production. The tls.peet.ws service returns your JA3, JA4, HTTP/2 fingerprint, and Akamai fingerprint in JSON format. Compare your curl_cffi output against a real Chrome browser visiting the same URL — they should match on JA4 and HTTP/2 SETTINGS.

For ProxyHat-specific configuration details, see the ProxyHat documentation. You can also explore available exit locations on the ProxyHat locations page.

Common Mistakes and Edge Cases

1. Mismatched User-Agent and impersonate Preset

If you set impersonate="chrome131" but manually override the User-Agent header to a Firefox string, the TLS fingerprint says Chrome but the HTTP headers say Firefox. Anti-bot systems cross-reference these and flag the mismatch. Always let the impersonate preset set the User-Agent, or manually set a matching one.

2. Forgetting HTTP/2 Fingerprint

Some engineers focus on JA3/JA4 but forget the HTTP/2 SETTINGS frame. If your TLS fingerprint is perfect Chrome but your HTTP/2 SETTINGS say HEADER_TABLE_SIZE=4096 (the h2 default), Akamai will flag you. The impersonate preset handles this automatically, but if you use ja3= overrides without also setting akamai=, you create a mismatch.

3. Using a Single Session ID for All Requests

ProxyHat's session flag gives you a sticky residential IP — useful for maintaining login state, but counterproductive for high-volume scraping. If you send 500 requests through the same session ID, they all come from the same IP, which triggers rate limits. Rotate session IDs every 10–50 requests depending on target sensitivity.

4. Ignoring the TLS 1.2 Fallback

Some older servers do not support TLS 1.3 and force a TLS 1.2 handshake. The impersonate presets include TLS 1.2 cipher lists, but the ClientHello shape differs. If your target forces TLS 1.2, verify the fingerprint still matches Chrome's TLS 1.2 profile.

5. Expecting curl_cffi to Solve JS Challenges

This is the most critical limitation. curl_cffi replicates the network fingerprint of a browser, not the execution environment. If the target site serves a JavaScript challenge (Cloudflare's cf_chl_jschl, DataDome's dd cookie, Akamai's _abck sensor data), curl_cffi cannot execute it. You need a real browser engine (Playwright, Puppeteer, or a stealth browser) for JS challenges. curl_cffi is the right tool for sites that gate on TLS/IP reputation but do not require JS execution.

ProxyHat-Specific Setup Guide

ProxyHat provides residential, mobile, and datacenter proxies. For TLS impersonation workloads, residential proxies are the correct choice — they provide ISP-assigned IPs that pass reputation checks. Mobile proxies are useful for mobile-specific targets (app store scraping, mobile-only content), and datacenter proxies are suitable for low-stakes targets that do not perform IP reputation checks.

Proxy Selection by Use Case

Configuring Geo-Targeting

ProxyHat supports country-level and city-level geo-targeting via the username string. For TLS impersonation, matching the proxy geo to the target's expected audience improves success rates:

# Country-level
proxy = "http://user-country-US:pass@gate.proxyhat.com:8080"

# City-level (Berlin, Germany)
proxy = "http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080"

# Sticky session (same IP for all requests in this session)
proxy = "http://user-country-DE-session-abc123:pass@gate.proxyhat.com:8080"

For pricing details, visit the ProxyHat pricing page. For web scraping and SERP tracking use cases, see web scraping and SERP tracking use case pages.

Limits and Ethics: What curl_cffi Cannot Do

curl_cffi is a powerful tool for legitimate data access, but it has hard limits and ethical boundaries that practitioners must respect.

Technical Limits

• No JavaScript execution: curl_cffi cannot execute JS challenges, render pages, or interact with DOM elements. For JS-gated sites, use Playwright with a stealth plugin or a managed browser solution.
• No canvas/WebGL fingerprinting: A real browser exposes canvas, WebGL, and AudioContext fingerprints via JavaScript. curl_cffi does not have a rendering engine, so these are absent. Sites that check for these will detect the mismatch.
• No behavioral fingerprinting: Real browsers produce mouse movement, scroll, and timing patterns. curl_cffi sends HTTP requests with no behavioral signals. Sites that score behavioral patterns will flag this.
• TLS 1.3 session resumption: curl_cffi handles session tickets, but the session resumption fingerprint (PSK extension ordering) may differ from Chrome in edge cases.

Legal and Ethical Considerations

TLS impersonation and proxy usage exist in a legal gray area. Key principles:

• Respect robots.txt: While robots.txt is not legally binding in all jurisdictions, it signals the site owner's preferences. Ethical scraping respects these directives.
• Authorized access only: Under the U.S. Computer Fraud and Abuse Act (CFAA), accessing a computer system "without authorization" or "exceeding authorized access" can constitute a federal crime. The boundaries of "authorization" in the context of public web pages are contested, but circumventing technical access controls (like CAPTCHAs or WAF blocks) strengthens a CFAA argument. You can read the statute at 18 U.S.C. § 1030.
• GDPR and CCPA: If you collect personal data (names, emails, IP addresses) from EU or California residents, GDPR and CCPA obligations apply regardless of how you accessed the data. Scraping public pages that contain personal data is not exempt from data protection law.
• Terms of Service: Many sites prohibit scraping in their ToS. While ToS violations are typically a contract issue rather than a criminal one, they can result in IP bans, civil lawsuits, or DMCA takedowns.
• Rate limiting: Even with perfect TLS impersonation and residential proxies, sending 100 requests/second to a small site is abusive. Match your request rate to the site's capacity and use case.

Key Takeaways:

• TLS fingerprinting (JA3/JA4) inspects your ClientHello's cipher order, extensions, curves, and GREASE values — Python's default OpenSSL fingerprint is instantly recognizable as non-browser.
• curl_cffi compiles curl against BoringSSL (Chrome's TLS stack) and replays the exact ClientHello, HTTP/2 SETTINGS, and WINDOW_UPDATE frames that Chrome sends.
• Chrome 110+ permutes extension order, which broke JA3; JA4 sorts before hashing to remain stable across permutations.
• A perfect TLS fingerprint over a datacenter IP still fails IP reputation scoring — residential proxies are mandatory for serious anti-bot bypass.
• curl_cffi cannot execute JavaScript challenges; for JS-gated sites, use a real browser engine like Playwright with stealth plugins.
• Always verify your fingerprint against tls.peet.ws before production deployment, and ensure User-Agent, TLS, and HTTP/2 fingerprints all tell the same browser story.

FAQ

What is TLS Impersonation with curl_cffi?

TLS Impersonation with curl_cffi is the technique of using curl_cffi — a Python binding to curl-impersonate compiled against BoringSSL — to send a TLS ClientHello that byte-for-byte matches a real browser like Chrome or Firefox. This includes matching cipher suite ordering, TLS extensions, GREASE values, supported curves, and the HTTP/2 SETTINGS frame. The result is a JA3/JA4 fingerprint that anti-bot systems cannot distinguish from a legitimate browser connection.

Why does TLS Impersonation with curl_cffi matter for proxy users?

Without TLS impersonation, your Python HTTP client's ClientHello fingerprint immediately identifies it as a non-browser to anti-bot systems like Cloudflare, Akamai, and DataDome — regardless of which proxy you use. The proxy handles IP reputation, but the TLS fingerprint is inspected at the connection layer before any HTTP data is sent. If your JA3/JA4 hash does not match a known browser, the request is blocked before the proxy can help. curl_cffi closes this gap by making the TLS layer indistinguishable from Chrome.

Which proxy type works best for TLS Impersonation with curl_cffi?

Residential proxies are the best choice for TLS impersonation workloads. A perfect Chrome TLS fingerprint over a datacenter IP still fails because anti-bot systems cross-reference the TLS fingerprint against IP reputation — real Chrome users do not browse from AWS or DigitalOcean ASNs. Residential proxies provide ISP-assigned IPs that pass reputation checks. Mobile proxies are an alternative for mobile-specific targets. Datacenter proxies should only be used for targets that do not perform IP reputation scoring.

How do you avoid blocks when implementing TLS Impersonation with curl_cffi?

To avoid blocks: (1) use the correct impersonate preset matching your target's most common browser, (2) pair curl_cffi with residential proxies like ProxyHat to pass IP reputation checks, (3) rotate session IDs every 10–50 requests to distribute traffic across different IPs, (4) never override the User-Agent to a mismatched browser string, (5) respect rate limits and add jitter between requests, and (6) verify your fingerprint against tls.peet.ws before production deployment to ensure JA4 and HTTP/2 SETTINGS match a real browser.

Can curl_cffi solve JavaScript challenges or CAPTCHAs?

No. curl_cffi replicates the network-layer fingerprint (TLS and HTTP/2) but does not include a JavaScript execution engine. If a target site serves a JS challenge like Cloudflare's cf_chl_jschl, Akamai's _abck sensor, or DataDome's dd cookie, curl_cffi cannot execute or solve it. For JS-gated sites, you need a real browser engine like Playwright or Puppeteer with stealth plugins. curl_cffi is best suited for sites that gate on TLS fingerprint and IP reputation but do not require JavaScript execution.