L'IP residenziale non salva più. Nel 2026, i più grandi sistemi anti-bot — Cloudflare, Akamai, AWS WAF — hanno imparato a riconoscere il traffico automatizzato ancora prima che il server restituisca il primo byte di HTML. La decisione su se si sia un bot o un essere umano viene presa durante la fase di handshake TLS, in base all'"impronta digitale" del tuo client. E se questa impronta non corrisponde alla forma di un vero browser, nessun IP residenziale pulito ti salverà. Lo scraping si è trasformato da un "gioco di proxy" a un "gioco di identità".
Cosa è successo: JA4+ è diventato lo standard del settore
Solo un paio di anni fa, lo standard di fingerprinting TLS era JA3 — un hash che riassumeva la versione TLS, l'elenco dei cipher suite, le estensioni e le curve ellittiche dal messaggio ClientHello in una stringa MD5. Il metodo funzionava fino a Chrome 110 (gennaio 2023), quando Google ha intenzionalmente attivato la randomizzazione dell'ordine delle estensioni TLS come misura contro il fingerprinting. Dopo ciò, l'hash JA3 ha cominciato a cambiare ad ogni connessione anche con lo stesso browser — identificare il client in modo affidabile è diventato impossibile.
La risposta è stata JA4+ di FoxIO: prima dell'hashing, i cipher suite e le estensioni vengono ordinati, quindi la randomizzazione di Chrome non disturba più l'impronta. Entro il 2026, JA4 è diventato lo standard de facto e funziona come segnale principale nella gestione dei bot Cloudflare, AWS WAF, VirusTotal e Akamai. Il formato a tre parti (a_b_c) è stabile tra le versioni del browser: ad esempio, Chrome 120–131 restituisce t13d1516h2_8daaf6152771_02713d6af862, mentre Chrome 133–136 restituisce t13d1516h2_8daaf6152771_d8a2da3f94cd.
La portata di questo rilevamento è difficile da sovrastimare. Cloudflare analizza oltre 15 milioni di impronte JA4 uniche, raccolte da oltre 500 milioni di user-agent, e il suo modello ML di ottava generazione elabora circa 46 milioni di richieste HTTP al secondo. DataDome, secondo i propri dati, gestisce oltre 5 trilioni di segnali al giorno con una latenza inferiore a 2 ms, mantenendo oltre 85.000 modelli ML client. Akamai riporta un'accuratezza di classificazione dei bot nel range del 92–98% grazie all'analisi cross-layer.
Post-quantum TLS: una nuova trappola per gli scraper
Il principale cambiamento del 2026, di cui pochi sono a conoscenza, è il passaggio dei browser alla crittografia post-quantistica. Ed è proprio questo che sta rendendo obsoleti gli strumenti di scraping.
La cronologia è semplice. Nell'aprile 2024, Chrome 124 ha attivato per impostazione predefinita lo scambio di chiavi ibrido X25519MLKEM768 (X25519 classico più ML-KEM-768, ex Kyber). Nel novembre 2024, Firefox 132 ha aggiunto il supporto, nell'ottobre 2025 — Apple su iOS e macOS. E il 31 gennaio 2026 Akamai ha reso le connessioni post-quantistiche il default per tutti i clienti. Secondo F5 Labs, già il 57,4% di tutte le connessioni browser porta chiavi post-quantistiche; tra il traffico di Chrome, il 93% è compatibile con PQ.
Il problema per gli scraper è che la chiave post-quantistica aggiunge 1088 byte nel ClientHello — il messaggio si gonfia da circa ~300–500 byte a oltre 1400 byte e ora non entra più in un singolo pacchetto TCP. Questo fornisce al rilevatore tre indizi:
- Segnale binario. Una richiesta che si presenta come Chrome 131, ma senza la chiave post-quantistica — "bandiera rossa, attivata ancora prima del primo byte di traffico HTTP".
- Frammentazione del ClientHello. Il messaggio gonfiato viene suddiviso in più pacchetti TCP, e il modello di segmentazione differisce da quello di un vero browser.
- JA4 esteso. Un lavoro scientifico (arXiv, marzo 2026) ha mostrato un'accuratezza del 98% nel distinguere TLS classico e post-quantistico solo dai dati di handshake.
Una storia a parte sono le vulnerabilità della libreria uTLS, su cui sono costruiti molti scraper Go. Due CVE (CVE-2026-26995 e CVE-2026-27017) sono rimaste inosservate per più di due anni e hanno fornito una probabilità di rilevamento del 25–50% per connessione a causa dell'estensione di padding mancante e della dissonanza GREASE/ECH. Si risolve aggiornando uTLS a 1.8.2+. La morale: un legame rigido con vecchie impronte come HelloChrome_120 si è trasformato da un trucco utile a un peso letteralmente dopo un aggiornamento del browser.
Non solo TLS: HTTP/2 e rilevamento stratificato
Il handshake TLS è solo il primo confine. Subito dopo c'è il fingerprinting HTTP/2: ogni browser invia un insieme caratteristico di parametri SETTINGS e il proprio ordine di pseudo-intestazioni. Per Chrome è masp, per Firefox — mpas, per Safari — mspa. E l'ordine delle pseudo-intestazioni di un normale curl (mpsa) non corrisponde a nessun vero browser — cioè curl viene subito identificato.
Nel 2026, il rilevamento è costruito in una catena chiara, dove i segnali vengono verificati per coerenza tra loro:
- Fingerprinting TCP/IP — identificazione del sistema operativo prima della crittografia;
- TLS ClientHello (JA4) — durante l'handshake;
- HTTP/2 SETTINGS — il primo frame dopo TLS;
- l'ordine delle intestazioni HTTP nella richiesta;
- cross-verifica: tutti i segnali devono "comporre" un'unica identità coerente.
È per questo che una corrispondenza solo su JA3 oggi è peggiore di niente: il sistema vede "Chrome di forma errata" e lo classifica come bot. Come formulano gli ingegneri pratici: il matching del fingerprint TLS non riguarda più un hash statico, ma un'identità complessiva del cliente su tutti i livelli contemporaneamente.
Cosa significa questo nella pratica
La conclusione, che ripetono tutte le fonti serie del 2026: "un perfetto spoofing TLS perde valore se le richieste arrivano improvvisamente da cinque diverse località in due minuti". I proxy e l'impronta ora funzionano solo in combinazione. Vediamo cosa cambia.
1. L'impronta deve essere reale, non "ritoccata"
Per le richieste HTTP senza esecuzione di JavaScript, i segnali chiave sono: un corretto JA4, i giusti SETTINGS HTTP/2 e l'ordine delle pseudo-intestazioni, la corretta sequenza delle intestazioni e la coerenza di tutti i livelli. Il nativo Python-requests, il curl standard e Go net/http non possono riprodurre questo. Gli strumenti funzionanti del 2026 sono curl_cffi, curl-impersonate, uTLS, tls-client, che mantengono l'impronta TLS a livello di BoringSSL. Per l'automazione del browser, la soluzione open source più potente è Camoufox: sostituisce l'impronta a livello di C++, e non tramite evidenti patch JS. Ma ricordate le CVE — le librerie devono essere aggiornate.
2. Il proxy risolve ciò che l'impronta non risolve
Anche un perfetto spoofing TLS non aiuterà se l'indirizzo IP ha una cattiva reputazione e l'ASN è noto come data center. La rete è un livello di fiducia a parte: coerenza della geolocalizzazione, reputazione ASN, velocità e dispersione delle richieste. Qui entrano in gioco proxy residenziali — il traffico passa attraverso veri indirizzi ISP di utenti domestici, quindi dai segnali di rete non sei distinguibile da un visitatore normale. Per le piattaforme più aggressive (app mobili di social media, banche, antifrode) i proxy mobili sono ancora più resistenti: gli IP degli operatori di telefonia mobile con NAT-sharing offrono il massimo livello di fiducia e raramente vengono bannati in massa.
3. Vince la combinazione, non il trucco singolo
Il metodo più efficace (e, onestamente, il più costoso) del 2026 si compone di quattro componenti contemporaneamente: vera automazione del browser (Chromium/Firefox), instradamento attraverso indirizzi ISP residenziali o mobili, plugin stealth che rimuovono la telemetria dell'automazione, e randomizzazione del comportamento umano. La regola è semplice: "ripara l'handshake, conserva l'IP residenziale — e il tasso di successo aumenta drasticamente". Nessuno di questi elementi da solo nel 2026 è più sufficiente.
Se stai solo scegliendo su cosa costruire l'infrastruttura, è utile iniziare dalle basi — comprendere i protocolli di trasporto e cosa distingue i proxy HTTP/HTTPS dai SOCKS5 per diverse esigenze di scraping. Ne abbiamo parlato in una guida separata: HTTP, HTTPS e SOCKS5 — quale proxy scegliere.
Conclusione
Il 2026 ha definitivamente chiuso l'era in cui per lo scraping bastava "comprare proxy residenziali e ruotare gli IP". Ora sei riconosciuto dalla forma dell'handshake TLS, dalle chiavi post-quantistiche, dall'ordine delle intestazioni HTTP/2 — e tutti questi segnali vengono confrontati tra loro e con la rete da cui provieni. Vince chi ha un'identità coerente su tutti i livelli: un'impronta credibile, librerie aggiornate, comportamento umano e una rete residenziale o mobile di qualità sotto di essa. I proxy non hanno smesso di essere necessari — sono diventati la base su cui si costruisce tutto il resto.
```