TLS Impersonation with curl_cffi: Beating JA3/JA4 Anti-Bot Detection in 2026

Why TLS Impersonation with curl_cffi Matters in 2026

If you've ever routed requests through a residential proxy and still gotten a 403 or an endless CAPTCHA loop, the problem is almost certainly not your IP — it's your TLS fingerprint. Modern anti-bot systems from Cloudflare, Akamai, DataDome, and PerimeterX read the TLS ClientHello before your HTTP headers ever arrive. A default Python requests or urllib3 handshake produces a JA3/JA4 hash that instantly screams "I am a script, not a browser." TLS impersonation with curl_cffi solves this by replaying Chrome's exact TLS stack, cipher order, extensions, and HTTP/2 SETTINGS frame — so your traffic is indistinguishable from a real browser at the network layer.

This guide is for Python scraping engineers and security researchers who need to understand exactly how detection works and how to pass it cleanly. We'll cover the TLS fingerprinting mechanics, how curl_cffi and curl-impersonate replicate Chrome's BoringSSL handshake, why residential proxies remain mandatory even with a perfect fingerprint, and a fully runnable example routed through ProxyHat residential exits.

How Anti-Bot Systems Read Your TLS ClientHello

Every TLS connection begins with the client sending a ClientHello message. This message is fully visible to the server before any encryption is negotiated — it's plaintext by design. Anti-bot vendors parse it and compute two widely-used fingerprints:

• JA3 — a hash of the TLS version, cipher suites, extensions list, elliptic curves, and EC point formats, concatenated in a specific order. Introduced by Salesforce in 2017.
• JA4 — a newer, order-stable fingerprint format designed by FoxIO and adopted widely in 2024–2025. JA4 separates the fingerprint into observable fields (e.g., t13d1516h2_8daaf6152771_b186095e22b6) and is resilient to Chrome's extension permutation.

The key insight: the cipher list and extension order are as identifying as a browser User-Agent string. A real Chrome 120 client sends a specific, ordered set of ~15 cipher suites with GREASE values inserted at predictable positions. Python's ssl module — backed by OpenSSL — sends a completely different set in a different order.

The Default Python ClientHello Problem

Here's what a standard requests.get() looks like to a fingerprinting system:

• Cipher order: OpenSSL default order — ECDHE-ECDSA-AES256-GCM-SHA384 first, not Chrome's order. Chrome leads with TLS_AES_128_GCM_SHA256 (0x1301) in TLS 1.3.
• Extensions: Python sends server_name, ec_point_formats, supported_groups, but omits Chrome-specific extensions like application_settings (ALPS), encrypted_client_hello (ECH), and renegotiation_info in the exact positions Chrome uses.
• Supported curves: Python/OpenSSL sends x25519, secp256r1, secp384r1 — but Chrome sends x25519 first, then secp256r1, and includes secp384r1 only in specific builds.
• GREASE: Chrome inserts GREASE (RFC 8701) values like 0x0a0a at specific positions in cipher lists, extensions, and ALPN. OpenSSL-based Python clients do not insert GREASE at all, or insert it differently.
• TLS 1.3 ClientHello shape: Chrome's ClientHello is ~517 bytes; Python's is typically ~260 bytes. The size alone is a signal.

The result: your JA3 hash looks like 519...8f (a known Python/OpenSSL signature) instead of Chrome's cd08e31494f9531f...5b. The anti-bot system flags you before your HTTP/1.1 GET / is even read.

A correct User-Agent header with the wrong JA3 hash is worse than no User-Agent at all — it tells the bot detection system you're actively trying to deceive it.

How curl_cffi and curl-impersonate Replicate Chrome's TLS Stack

curl_cffi is a Python binding to curl-impersonate, a patched build of curl linked against BoringSSL (Google's fork of OpenSSL, used by Chrome) instead of standard OpenSSL. This is the critical architectural decision: you cannot impersonate Chrome's TLS handshake with OpenSSL because the extension emission logic, GREASE insertion, and ALPS handling are baked into BoringSSL's source.

curl-impersonate patches libcurl and BoringSSL to:

• Hardcode Chrome's exact cipher suite list and ordering for both TLS 1.2 and TLS 1.3.
• Insert GREASE values at the positions Chrome uses (cipher list, extensions list, supported groups, ALPN).
• Emit Chrome-specific extensions: application_settings (ALPS), encrypted_client_hello, compress_certificate, signed_certificate_timestamp, and renegotiation_info in the correct order.
• Send the Chrome HTTP/2 SETTINGS frame with Chrome's exact values (e.g., HEADER_TABLE_SIZE=65536, ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=6291456).
• Set the TLS record layer to match Chrome's maximum fragment length and record splitting behavior.

The impersonate Presets

curl_cffi exposes this through a simple API:

from curl_cffi import requests

r = requests.get("https://www.example.com", impersonate="chrome")
print(r.status_code)
The impersonate parameter accepts presets like "chrome", "chrome110", "chrome120", "safari17", "edge99", and others. Each preset bundles a full TLS profile: cipher list, extension order, GREASE positions, ALPN list, and HTTP/2 settings. When you set impersonate="chrome", curl_cffi selects the latest Chrome profile available in your installed version.
Manual ja3, akamai, and extra_fp Overrides
For advanced use cases — security research, authorized penetration testing — curl_cffi lets you override individual fingerprint components:
from curl_cffi import requests, CurlOpt

r = requests.get(
    "https://target.example.com",
    impersonate="chrome120",
    ja3="771,4865-4866-4867-49195-49199...,0-23-65281-10-11-35-16-5-13-18-51-45-43-2721-17513-51,...",
    akamai="1-65536;2-0;3-1000;4-6291456;6-262144|15663105-0-0-0-0-0-0-0",
    extra_fp={
        "tls_signature_algorithms": [
            0x0403, 0x0804, 0x0401, 0x0501, 0x0601, 0x0201,
        ],
        "tls_client_hello_random_extension_order": True,
    },
)

The ja3 string lets you specify a custom cipher/extension/curve sequence. The akamai string controls the HTTP/2 SETTINGS frame and pseudo-header order. The extra_fp dict fine-tunes signature algorithms, extension ordering, and other sub-fingerprint fields. This granularity matters because some anti-bot systems check not just JA3 but also the Akamai fingerprint (HTTP/2 SETTINGS + header order) and the JA4 fingerprint simultaneously.
Chrome 110+ ClientHello Permutation and Why JA4 Exists
Starting with Chrome 110 (released February 2023), Google introduced ClientHello extension permutation. Instead of sending extensions in a fixed order every time, Chrome randomizes the order of certain extensions on each connection. This was a deliberate countermeasure against JA3-based fingerprinting — if the extension order changes, the JA3 hash changes, and a static blocklist of "known bot JA3 hashes" becomes unreliable.
This broke many JA3-based detection systems. A single Chrome client now produces dozens of different JA3 hashes across connections. curl_cffi's Chrome 110+ presets replicate this permutation behavior, so your requests produce the same distribution of JA3 hashes as a real Chrome client.
JA4 was designed as the response to permutation. Instead of hashing the raw extension order, JA4 sorts extensions into categories (SNI, ALPN, signature algorithms, etc.) and hashes the sorted representation. The result is an order-stable fingerprint: the same Chrome client produces the same JA4 regardless of extension permutation. The JA4 format looks like t13d1516h2_8daaf6152771_b186095e22b6, where:

t13 — TLS 1.3
d — destination IP included (SNI present)
15 — 15 cipher suites
16 — 16 extensions
h2 — ALPN negotiated HTTP/2
The two trailing hash components cover cipher/extension sets and signature algorithms, sorted.

For curl_cffi users, the implication is: you must match the JA4 set, not just the JA3 order. The impersonate="chrome120" preset handles this correctly because it uses BoringSSL's actual extension emission logic, not a hardcoded JA3 string. If you override ja3 manually, you may fix the JA3 but break the JA4. Use manual overrides only when you have a specific, tested reason.
Why Residential Proxies Remain Mandatory
A perfect TLS fingerprint over a datacenter IP still fails. Here's why: anti-bot systems don't rely on TLS fingerprinting alone. They combine it with IP reputation scoring, ASN classification, and behavioral analytics. The detection pipeline looks like:

TLS fingerprint check — Is the JA3/JA4 in the known-browser set? If no → block. If yes → continue.
IP reputation check — Is the IP from a residential ASN (Comcast, Deutsche Telekom, Vodafone) or a datacenter ASN (AWS, DigitalOcean, Hetzner)? Datacenter ASNs get a risk score multiplier of 5–10x.
Behavioral check — Is the request rate, navigation pattern, and header order consistent with a human or a known automation pattern?
JS challenge — If the first three pass but suspicion remains, serve a JavaScript challenge (Cloudflare Turnstile, DataDome captcha).

If you pass step 1 with curl_cffi but fail step 2 because you're on a 23.94.x.x Hetzner block, you get blocked at step 2. The TLS fingerprint got you past the first gate; the IP reputation gate stops you cold.


Factor
Datacenter IP + curl_cffi
Residential IP + curl_cffi
Residential IP + requests


TLS fingerprint match
✅ Yes
✅ Yes
❌ No
IP reputation score
❌ High risk (datacenter ASN)
✅ Low risk (residential ASN)
✅ Low risk
HTTP/2 SETTINGS match
✅ Yes
✅ Yes
❌ No (HTTP/1.1 or wrong H2)
Overall pass rate
~30–40%
~90–95%
~10–20%


The numbers above are representative ranges based on community testing against Cloudflare-protected sites in 2025. Your mileage varies by target, but the pattern holds: you need both a correct TLS fingerprint and a clean residential IP.
Worked Example: curl_cffi AsyncSession Through ProxyHat Residential Exits
Here's a complete, runnable example that combines curl_cffi's Chrome impersonation with ProxyHat residential proxies, including rotation and retry logic. This is the configuration that achieves the ~90–95% pass rate in the table above.
Basic Setup: Single Request Through ProxyHat
from curl_cffi import requests

# ProxyHat residential proxy with German geo-targeting
proxy = "http://user-country-DE:pass@gate.proxyhat.com:8080"

r = requests.get(
    "https://www.example.com",
    impersonate="chrome120",
    proxies={"http": proxy, "https": proxy},
    timeout=30,
)
print(f"Status: {r.status_code}")
print(f"JA4-relevant headers: {r.headers.get('server')}")

AsyncSession with Rotation and Retries
import asyncio
from curl_cffi.requests import AsyncSession

def build_proxy(country: str, session_id: str) -> str:
    """Build a ProxyHat residential proxy URL with sticky session."""
    return f"http://user-country-{country}-session-{session_id}:pass@gate.proxyhat.com:8080"

async def fetch(session: AsyncSession, url: str, country: str, session_id: str) -> dict:
    proxy = build_proxy(country, session_id)
    for attempt in range(3):
        try:
            r = await session.get(
                url,
                impersonate="chrome120",
                proxies={"http": proxy, "https": proxy},
                timeout=30,
                allow_redirects=True,
            )
            if r.status_code == 200:
                return {"url": url, "status": r.status_code, "body_len": len(r.text)}
            elif r.status_code in (403, 429):
                # Rotate session on block
                session_id = f"rot{attempt}"
                proxy = build_proxy(country, session_id)
                await asyncio.sleep(2 ** attempt)
                continue
            else:
                return {"url": url, "status": r.status_code, "error": None}
        except Exception as e:
            await asyncio.sleep(2 ** attempt)
    return {"url": url, "status": 0, "error": "max_retries_exceeded"}

async def main():
    urls = [
        "https://www.example.com/page1",
        "https://www.example.com/page2",
        "https://www.example.com/page3",
    ]
    async with AsyncSession() as session:
        tasks = [
            fetch(session, url, "DE", f"sess{i}")
            for i, url in enumerate(urls)
        ]
        results = await asyncio.gather(*tasks)
        for r in results:
            print(r)

asyncio.run(main())

SOCKS5 Variant
If you need SOCKS5 (useful for certain network configurations or when HTTP CONNECT is filtered), ProxyHat supports it on port 1080:
from curl_cffi import requests

proxy = "socks5://user-country-DE:pass@gate.proxyhat.com:1080"

r = requests.get(
    "https://www.example.com",
    impersonate="chrome120",
    proxies={"http": proxy, "https": proxy},
    timeout=30,
)

For production workloads, explore ProxyHat's pricing tiers for residential bandwidth plans, and check the available proxy locations for country/city-level targeting. The ProxyHat documentation covers advanced session control and concurrency limits.
Common Mistakes and Edge Cases
1. Overriding ja3 Without Updating akamai
If you set a custom ja3 string but leave the default akamai (HTTP/2 SETTINGS), the anti-bot system sees a Chrome TLS fingerprint with a non-Chrome HTTP/2 fingerprint. This mismatch is a stronger signal than either fingerprint alone. Always test both together.
2. Using an Outdated impersonate Preset
If your curl_cffi version ships chrome110 but the target site expects Chrome 120's JA4 set, you may pass JA3 but fail JA4. Update curl_cffi regularly (pip install --upgrade curl_cffi) to get the latest browser presets.
3. Ignoring the HTTP/2 Pseudo-Header Order
Chrome sends HTTP/2 pseudo-headers in the order :method, :authority, :scheme, :path. Some anti-bot systems check this order. curl_cffi's presets handle it, but if you're using a custom HTTP/2 library on top of curl_cffi, verify the order.
4. Forgetting the Sec-CH-UA Headers
TLS impersonation gets you past the network-layer check, but the application layer still checks headers. Chrome sends sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform, and sec-fetch-* headers. curl_cffi's presets set these automatically, but if you override headers, include them:
headers = {
    "sec-ch-ua": '"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Windows"',
    "sec-fetch-dest": "document",
    "sec-fetch-mode": "navigate",
    "sec-fetch-site": "none",
    "sec-fetch-user": "?1",
    "upgrade-insecure-requests": "1",
}
r = requests.get(url, impersonate="chrome120", headers=headers, proxies=proxies)

5. Not Testing Against a Fingerprint Check Endpoint
Before hitting your real target, test your fingerprint against https://tls.peet.ws/api/all or https://browserleaks.com/tls. These return your JA3, JA4, and HTTP/2 fingerprint so you can verify your curl_cffi setup matches Chrome's known values.
What curl_cffi Cannot Do: JavaScript Challenges
This is the hard limit. curl_cffi is a TLS and HTTP/2 impersonation library — it does not execute JavaScript. When a site serves a Cloudflare Turnstile challenge, a DataDome interstitial, or an Akamai Bot Manager puzzle, that challenge requires a JavaScript runtime to solve. curl_cffi will receive the challenge HTML and return it as a 403 or 200-with-challenge-body. It cannot solve it.
For sites that require JS execution, you need a real browser — Playwright, Puppeteer, or a managed browser solution. The strategy is:

Use curl_cffi for sites that only check TLS fingerprint + IP reputation (most SERP endpoints, many e-commerce APIs, public data feeds).
Use a real browser for sites that serve JS challenges (Cloudflare-protected dashboards, ticketing systems with queue managers, social media login flows).

For SERP tracking and web scraping use cases where JS challenges are rare, curl_cffi + residential proxies is the most efficient stack. For more on these workflows, see ProxyHat's web scraping use case guide and SERP tracking guide.
Limits and Ethics: Authorized Access Only
TLS impersonation is a dual-use technology. Legitimate use cases include:

Security research and authorized penetration testing against your own infrastructure or with written authorization.
Accessing public data (SERPs, public pricing, open government data) where the site's terms of service permit automated access or where the data is not protected by authentication.
QA testing of your own anti-bot systems.

It is not legitimate to:

Bypass authentication or paywalls to access restricted content.
Scrape personal data protected by GDPR or CCPA without a lawful basis.
Access systems in violation of the Computer Fraud and Abuse Act (CFAA) in the US or equivalent laws in other jurisdictions.

The CFAA makes it a federal offense to access a protected computer "without authorization" or to "exceed authorized access." Courts have debated whether violating a site's terms of service constitutes exceeding authorized access (see Van Buren v. United States, 2021), but the safest posture is: if a site explicitly prohibits automated access in its ToS and you proceed anyway, you may be exposing yourself to legal risk. When in doubt, consult counsel.
Under GDPR, scraping personal data from EU-based sites without a lawful basis (consent, legitimate interest with balancing test) can result in fines up to €20 million or 4% of global annual turnover, whichever is higher.
Key Takeaways

TLS fingerprinting is the first gate. Anti-bot systems read your ClientHello before your HTTP headers. Python's default OpenSSL stack produces a JA3/JA4 that's instantly identifiable as non-browser.
curl_cffi uses BoringSSL, not OpenSSL. This is why it can replicate Chrome's exact cipher order, GREASE insertion, extension list, and HTTP/2 SETTINGS frame — you can't fake this with OpenSSL.
Use impersonate="chrome120" (or latest) as your default. Manual JA3 overrides risk breaking JA4. Only override when you have a tested, specific reason.
Residential proxies are mandatory. A perfect TLS fingerprint over a datacenter IP still fails IP reputation scoring. Pair curl_cffi with ProxyHat residential exits for the ~90–95% pass rate.
curl_cffi cannot solve JS challenges. For Cloudflare Turnstile, DataDome, and similar, use a real browser. curl_cffi is for the 80% of sites that only check TLS + IP.
Stay legal. Authorized public-data access and security research only. CFAA and GDPR apply. Respect robots.txt and terms of service.

FAQ
What is TLS Impersonation with curl_cffi?
TLS impersonation with curl_cffi is the technique of making Python's HTTP requests produce a TLS ClientHello that's byte-for-byte identical to a real browser (typically Chrome). curl_cffi achieves this by binding to curl-impersonate, a patched libcurl linked against BoringSSL — Chrome's actual TLS library — rather than OpenSSL. This means your cipher suite order, GREASE values, extension list, and HTTP/2 SETTINGS frame all match Chrome's exact output, producing the same JA3 and JA4 fingerprints as a real browser.
Why does TLS Impersonation with curl_cffi matter for proxy users?
Even with a clean residential IP, if your TLS fingerprint identifies you as a Python/OpenSSL client, anti-bot systems block you before reading your HTTP request. curl_cffi closes this gap by making your network-layer fingerprint indistinguishable from Chrome. Without it, residential proxies alone achieve roughly 10–20% pass rates on protected sites. With curl_cffi plus residential proxies, pass rates climb to 90–95%.
Which proxy type works best for TLS Impersonation with curl_cffi?
Residential proxies work best. Datacenter proxies fail IP reputation checks even with a perfect TLS fingerprint. Mobile proxies offer the highest reputation scores but at higher cost and lower bandwidth. For most scraping and automation tasks, residential proxies from a provider like ProxyHat offer the best balance of reputation, cost, and reliability. Use the -country-XX flag in your ProxyHat username for geo-targeting and -session-XXX for sticky sessions.
How do you avoid blocks when implementing TLS Impersonation with curl_cffi?
Use the latest impersonate preset (e.g., "chrome120"), route through residential proxies, set the correct sec-ch-ua and sec-fetch-* headers, implement retry logic with session rotation on 403/429 responses, and keep your concurrency reasonable (start with 5–10 concurrent requests per IP). Test your fingerprint against tls.peet.ws before hitting production targets. For JS-protected sites, switch to a real browser — curl_cffi cannot execute JavaScript challenges.
Can curl_cffi bypass Cloudflare Turnstile or DataDome?
No. curl_cffi impersonates the TLS and HTTP/2 layers but does not execute JavaScript. Cloudflare Turnstile, DataDome interstitials, and Akamai Bot Manager puzzles all require a JavaScript runtime to solve. curl_cffi will receive the challenge page but cannot complete it. For these sites, use Playwright or Puppeteer with a stealth plugin, still routed through residential proxies for IP reputation.