Interni di Cloudflare Turnstile: trust score, JA4 e cf_clearance nel 2026

Se gestisci automazione autorizzata — monitoraggio SERP, ricerca di sicurezza, raccolta di dati pubblici — prima o poi ti scontri con Cloudflare Turnstile. Capire gli interni di Cloudflare Turnstile non è un esercizio accademico: è la differenza tra una pipeline che gira a 1500 richieste al minuto e una che muore dopo 3 richieste con un challenge JavaScript insormontabile. Questa guida esamina come Turnstile calcola il punteggio di fiducia nel 2026, perché il bypass di Cloudflare Turnstile con tecniche naive fallisce, e come usare proxy residenziali sticky di ProxyHat per mantenere una sessione valida end-to-end.

Avvertenza legale. Le tecniche descritte sono per automazione autorizzata, ricerca di sicurezza consentita e accesso a dati pubblici. L'elusione di controlli di accesso per credenziali rubate, attacchi credential stuffing o violazione di Termini di Servizio può violare il CFAA negli Stati Uniti e il GDPR in Europa. Rispetta sempre robots.txt, i ToS del sito e le normative locali.

Cosa esegue realmente Cloudflare Turnstile: interni del managed challenge

Turnstile non è un CAPTCHA visivo nel senso classico. È un managed challenge invisibile che carica un bundle JavaScript (~50 KB compresso) ospitato sui domini challenges.cloudflare.com e cloudflareinsights.com. Il bundle esegue tre categorie di controlli prima di emettere il token cf_clearance:

• Proof-of-work (PoW) adattivo. Turnstile assegna un puzzle computazionale la cui difficoltà scala con il punteggio di rischio del client. Un browser legittimo con buon trust score riceve un PoW banale (sub-millisecondo); un client sospetto riceve un PoW che richiede centinaia di millisecondi di CPU. Il risultato viene inviato come parte del payload del token.
• Probe delle API del browser. Lo script interroga decine di proprietà — navigator.webdriver, navigator.plugins, window.chrome, Notification.permission, timing di performance.now(), lista di font via document.fonts, e segnali di sandboxing. Qualsiasi incoerenza (per esempio navigator.webdriver === true o l'assenza di window.chrome.runtime su un UA che dichiara Chrome) alza il punteggio di rischio.
• Telemetria comportamentale. Eventi mouse, scroll, tocchi e tastiera vengono campionati per rilevare pattern non umani. Un client headless che non genera eventi pointer per 30 secondi viene marcato.

Se tutti i controlli passano, Turnstile firma un token cf_clearance con scadenza tipica di 30 minuti (configurabile dal sito, fino a un massimo di ~24 ore). Il cookie è vincolato rigidamente alla coppia User-Agent + IP del client che lo ha ottenuto. Cambia uno dei due e il token viene rifiutato con un 403.

Cloudflare descrive Turnstile come alternativa privacy-first a reCAPTCHA nella propria documentazione pubblica, ma i dettagli del motore di trust score non sono documentati ufficialmente — la maggior parte di ciò che segue deriva da analisi della community di sicurezza e reverse engineering etico.

Il trust score a quattro segnali di Cloudflare Bot Management

Dietro Turnstile c'è Cloudflare Bot Management, che assegna un punteggio di rischio da 1 (bot certo) a 99 (umano certo) basandosi su quattro segnali principali. Il Cloudflare Bot Management JA4 è uno di questi, ma non l'unico.

1. Fingerprint TLS JA4

JA4 è il successore di JA3, sviluppato da John Althouse e FoxIO. A differenza di JA3, JA4 ordina le estensioni TLS alfabeticamente prima di hasharle, rendendo il fingerprint deterministico e resistente al riordino arbitrario dei campi. Il formato è JA4___. Per esempio, un Chrome 131 reale presenta un JA4 come t13d1516h2_8daaf6152771_b186095e22b6, mentre le librerie Python (requests via urllib3/OpenSSL) producono un fingerprint completamente diverso come t13d1715h2_5b57614c22b8_000000000000.

La specifica JA4 è open-source e disponibile nel repository FoxIO su GitHub. Cloudflare confronta il JA4 osservato con una database di fingerprint noti per UA dichiarato: se l'header User-Agent dice Chrome ma il JA4 corrisponde a OpenSSL/Python, il punteggio crolla a 1-10 e il challenge viene forzato immediatamente.

2. HTTP/2 SETTINGS fingerprint

Ogni client HTTP/2 invia un frame SETTINGS all'inizio della connessione con parametri come HEADER_TABLE_SIZE, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS. L'ordine e i valori di questi parametri variano per browser: Chrome, Firefox e Safari hanno firme distintive. Cloudflare hash questi valori come secondo segnale. Le librerie come httpx con h2 usano valori di default generici che non corrispondono a nessun browser reale.

3. Fingerprint del browser (canvas / WebGL / audio)

Turnstile raccoglie un fingerprint lato client combinando:

• Canvas 2D: rendering di testo con font specifici e misurazione dell'output pixel-per-pixel. Varia per GPU, driver e sistema operativo.
• WebGL: WEBGL_debug_renderer_info espone vendor e renderer della GPU (es. ANGLE (NVIDIA, NVIDIA GeForce RTX 4070)).
• AudioContext: l'output di OfflineAudioContext produce un fingerprint dipendente dall'implementazione DSP del browser.
• Font enumeration: misurazione del rendering di font di sistema noti.

Un browser headless come Playwright con Chromium headless presenta canvas/WebGL reali ma segnali rivelatori: navigator.webdriver = true, assenza di plugin, viewport di 800x600, e timing di performance.now() troppo precisi. La documentazione MDN sull'API Canvas descrive come questi elementi siano intrinsecamente dipendenti dall'hardware.

4. Reputazione IP

Cloudflare classifica ogni IP in categorie: datacenter (ASN di AWS, GCP, Azure, OVH, Hetzner), residenziale (ISP come Comcast, Telecom Italia, Vodafone), mobile (operatori cellulari), e known-bad (TOR exit node, proxy pubblici elencati). Un IP datacenter con JA4 incoerente è challenge garantito. Un IP residenziale con JA4 coerente può passare senza challenge visibile.

Perché una connessione Python con UA Chrome viene sfidata all'istante

Questo è l'errore più comune tra scraper principianti: impostare User-Agent: Mozilla/5.0 ... Chrome/131 in requests o httpx e aspettarsi di passare. Non funziona, e il motivo è puramente a livello TLS.

Quando Python apre una connessione TLS a challenges.cloudflare.com, il ClientHello viene generato da OpenSSL (o BoringSSL in alcune build). Le estensioni, le curve ellittiche e i cipher suite sono ordinati e selezionati dalla libreria TLS, non dal browser. Cloudflare vede il JA4 di OpenSSL — per esempio t13d1715h2_5b57614c22b8 — mentre l'header dice Chrome. Questo mismatch è una prova inequivocabile di spoofing dell'UA. Il punteggio di Bot Management scende sotto 10 e Turnstile emette un challenge che richiede JavaScript reale, PoL significativo e fingerprint coerente — cose che un client HTTP non può fornire.

Non esiste patch per questo a livello di libreria HTTP. Puoi usare curl-impersonate o tls-client per simulare il JA4 di Chrome, ma allora devi anche simulare HTTP/2 SETTINGS, l'ordine degli header, e comunque non hai un DOM per eseguire il challenge JavaScript. La soluzione robusta è usare un browser reale (Playwright/Puppeteer con Chromium non-headless o stealth) che produce JA4, HTTP/2 e fingerprint nativamente coerenti.

Perché i proxy residenziali sono essenziali: cf_clearance è IP-pinned

Anche con un browser perfetto, il cf_clearance cookie ha una limitazione critica: è vincolato all'IP con cui è stato ottenuto. Se ottieni cf_clearance da IP A e poi fai la richiesta successiva da IP B — anche con lo stesso UA, lo stesso browser, la stessa sessione — Cloudflare rifiuta il cookie con un 403 o reissua il challenge.

Questo distrugge l'approccio "proxy rotante per-request" che funziona per scraping semplice. Per Turnstile devi usare una sessione sticky: lo stesso IP di uscita per tutta la durata del cf_clearance. E quell'IP deve essere residenziale, perché:

• Un IP datacenter anche con JA4 perfetto ha un punteggio IP basso per default.
• Cloudflare penalizza ASN noti di hosting anche senza altri segnali negativi.
• Gli IP residenziali hanno un trust score base di 60-80, lasciando margine per superare la soglia di challenge.

I proxy mobili hanno trust score ancora più alto (80-90) perché gli operatori cellulari NAT migliaia di dispositivi legittimi dietro lo stesso IP, rendendo il segnale IP quasi indistinguibile da un utente reale. Ma sono più costosi e più lenti (latenza 200-400ms vs 50-100ms dei residenziali).

Approccio pratico: sessioni sticky residenziali con ProxyHat

Ecco un flusso legittimo end-to-end per ottenere cf_clearance con un browser reale tramite Playwright, usando una sessione sticky residenziale di ProxyHat, e poi riutilizzare il cookie per richieste successive.

Step 1: Avvia un browser con proxy sticky residenziale

from playwright.sync_api import sync_playwright
import requests

# Sessione sticky residenziale ProxyHat
# L'ID sessione abc123 garantisce lo stesso IP di uscita
PROXY = "http://user-session-abc123:pass@gate.proxyhat.com:8080"

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # headless=False riduce i segnali di automazione
        proxy={"server": PROXY}
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/131.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
    )
    page = context.new_page()
    page.goto("https://esempio-sito-protetto.com")

    # Attendi che Turnstile completi il challenge invisibile
    page.wait_for_timeout(5000)

    # Estrai cf_clearance e altri cookie
    cookies = context.cookies()
    cf_clearance = next(
        (c for c in cookies if c["name"] == "cf_clearance"), None
    )
    user_agent = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " \
                 "AppleWebKit/537.36 (KHTML, like Gecko) " \
                 "Chrome/131.0.0.0 Safari/537.36"

    browser.close()

Step 2: Riutilizza cf_clearance con la stessa sessione proxy

# Riutilizza il cookie mantenendo la STESSA sessione proxy
# per preservare l'IP che ha ottenuto cf_clearance
import requests

session = requests.Session()
session.proxies = {
    "http": "http://user-session-abc123:pass@gate.proxyhat.com:8080",
    "https": "http://user-session-abc123:pass@gate.proxyhat.com:8080",
}
session.headers.update({
    "User-Agent": user_agent,  # deve essere IDENTICO a quello del browser
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "it-IT,it;q=0.9,en;q=0.8",
})

session.cookies.set(
    "cf_clearance",
    cf_clearance["value"],
    domain=".esempio-sito-protetto.com",
)

response = session.get("https://esempio-sito-protetto.com/pagina-dati")
print(response.status_code)  # 200 se cf_clearance è ancora valido

Step 3: Geo-targeting per coerenza

Se il sito target è italiano, usa un exit IP italiano per coerenza geografica. Un cf_clearance ottenuto da un IP tedesco che poi accede a un sito con Accept-Language: it-IT genera un leggero anomaly score.

# Exit IP italiano con sessione sticky
PROXY_IT = "http://user-country-IT-session-abc123:pass@gate.proxyhat.com:8080"

Consulta la pagina delle locazioni ProxyHat per verificare la copertura geografica e i codici paese disponibili.

Errori comuni e casi limite

1. Rotazione IP dopo cf_clearance

L'errore più frequente: ottenere cf_clearance con sessione sticky, poi passare a proxy rotante per le richieste successive. Il cookie viene rifiutato al primo cambio IP. Soluzione: mantieni la stessa sessione -session-abc123 per tutta la vita del cookie.

2. User-Agent incoerente

Il UA usato per ottenere cf_clearance deve essere byte-identico a quello usato nelle richieste successive. Anche un cambiamento di versione (Chrome/131.0.0.0 vs Chrome/131.0.0.1) invalida il binding.

3. Headless detection

Chromium in modalità --headless=new (la nuova headless di Chrome 112+) è meno rilevabile della vecchia, ma navigator.webdriver è ancora true e window.chrome.runtime manca. Usa headless=False con Xvfb su Linux, o librerie come playwright-stealth per patchare questi segnali.

4. Scadenza del cf_clearance

Il cookie ha una vita tipica di 30 minuti. Se la tua pipeline impiega più tempo, devi rinnovarlo rilanciando il browser con la stessa sessione proxy. Implementa un refresh proattivo a 25 minuti per evitare gap.

5. JA4 mismatch anche con browser reale

Se usi un browser reale ma il proxy è un MITM TLS (alcuni proxy datacenter intercettano TLS), il JA4 che Cloudflare vede è quello del proxy, non del browser. I proxy residenziali di ProxyHat usano tunneling CONNECT senza terminazione TLS, quindi il JA4 del browser passa intatto.

Quando questo approccio è appropriato

Il bypass di Cloudflare Turnstile è legittimo in questi scenari:

• Ricerca di sicurezza autorizzata: pentesting con scope firmato, bug bounty program.
• Accesso a dati pubblici: pagine non protette da login, dati governativi open-data, SERP pubbliche.
• Monitoraggio prezzi e-commerce: prodotti pubblici, per analisi competitiva — rispetta i ToS del singolo merchant.
• QA e testing: testare i tuoi stessi siti protetti da Cloudflare.

Non è appropriato per: credential stuffing, account takeover, scraping di contenuti dietro login senza autorizzazione, o elusione di rate limit per abuso. Il CFAA (Computer Fraud and Abuse Act) negli Stati Uniti e il GDPR in Europa possono applicarsi anche all'accesso "tecnico" a dati non autorizzati, indipendentemente dalla presenza di un bug nel sistema di protezione.

Configurazione ProxyHat per Turnstile

Per implementare il flusso sopra descritto con ProxyHat, usa questi parametri di connessione:

Esempio con curl per testare la connettività:

# Test HTTP con sessione sticky italiana
curl -x http://user-country-IT-session-abc123:pass@gate.proxyhat.com:8080 \
  https://httpbin.org/ip

# Test SOCKS5
curl -x socks5://user-country-IT-session-abc123:pass@gate.proxyhat.com:1080 \
  https://httpbin.org/ip

Per i dettagli completi sulla configurazione, consulta la documentazione ProxyHat. Per i piani e i prezzi dei proxy residenziali, visita la pagina prezzi di ProxyHat. Per use case specifici di web scraping e SERP tracking, vedi web scraping e SERP tracking.

Punti chiave

• Turnstile = 4 segnali. JA4 TLS, HTTP/2 SETTINGS, fingerprint browser, reputazione IP. Devi allinearli tutti, non solo l'User-Agent.
• cf_clearance è IP-pinned. Cambia IP e il cookie muore. Usa sessioni sticky residenziali per tutta la durata del token.
• Python + UA Chrome = challenge immediato. Il JA4 di OpenSSL non corrisponde a Chrome. Serve un browser reale per un JA4 coerente.
• Proxy residenziali > datacenter. Trust score IP base 60-80 vs 20-40. I mobili sono ancora meglio ma più lenti.
• Stesso UA, stessa sessione, stesso IP. La triade deve restare costante dalla ottenzione del cf_clearance fino al suo rinnovo.
• Legalità. Solo per automazione autorizzata e dati pubblici. Il CFAA e il GDPR si applicano all'accesso non autorizzato.

FAQ

Cosa sono gli interni di Cloudflare Turnstile?

Gli interni di Cloudflare Turnstile comprendono il bundle JavaScript del managed challenge, il proof-of-work adattivo, i probe delle API del browser (navigator, canvas, WebGL, audio), la telemetria comportamentale e l'emissione del cookie cf_clearance firmato e vincolato a User-Agent + IP. Turnstile non è un CAPTCHA visivo ma un sistema invisibile che assegna un punteggio di rischio basato su quattro segnali: JA4 TLS, HTTP/2 SETTINGS, fingerprint del browser e reputazione IP. Se il punteggio supera la soglia del sito, il challenge passa senza interazione; altrimenti viene emesso un challenge interattivo o un blocco.

Perché gli interni di Cloudflare Turnstile importano per gli utenti di proxy?

Il cookie cf_clearance emesso da Turnstile è vincolato rigorosamente all'IP di uscita del proxy. Se usi un proxy rotante per-request, il cookie ottenuto da IP A viene rifiutato quando la richiesta successiva parte da IP B. Questo rende i proxy datacenter rotanti inutilizzabili per siti protetti da Turnstile. Serve una sessione sticky su un IP residenziale stabile per tutta la durata del cf_clearance (tipicamente 30 minuti). Senza questa coerenza IP, anche un browser perfetto con JA4 corretto fallisce.

Quale tipo di proxy funziona meglio per gli interni di Cloudflare Turnstile?

I proxy residenziali con sessioni sticky sono la scelta ottimale. Gli IP residenziali hanno un trust score base di 60-80 perché appartengono a ISP reali, mentre i datacenter partono da 20-40. I proxy mobili hanno trust score ancora più alto (80-90) ma latenza superiore (200-400ms vs 50-100ms). La sessione sticky garantisce che lo stesso IP ottenga e riutilizzi cf_clearance. ProxyHat supporta sessioni sticky via flag username -session-abc123 sul gateway gate.proxyhat.com:8080.

Come evitare i blocchi implementando gli interni di Cloudflare Turnstile?

Allinea quattro elementi: usa un browser reale (Playwright/Puppeteer con Chromium non-headless o stealth) per produrre JA4 e HTTP/2 SETTINGS nativamente coerenti; mantieni lo stesso User-Agent byte-per-byte dalla ottenzione al riutilizzo di cf_clearance; usa una sessione proxy sticky residenziale che non cambi IP per tutta la durata del cookie; scegli un exit IP geo-coerente con l'Accept-Language dichiarato. Evita librerie HTTP pure (requests, httpx) perché il loro JA4 TLS non corrisponde a nessun browser reale e viene sfidato all'istante.

Quanto dura un cf_clearance cookie?

La durata predefinita di cf_clearance è di circa 30 minuti, configurabile dal singolo sito fino a un massimo di circa 24 ore. Per pipeline che richiedono più tempo, implementa un rinnovo proattivo a 25 minuti rilanciando il browser con la stessa sessione proxy sticky. Se il cookie scade a metà di una richiesta, il server risponde con 403 o reindirizza al challenge Turnstile, interrompendo la pipeline.