Gli sviluppatori che utilizzano Playwright per il web scraping vedono la propria prima richiesta rifiutata anche se lo script avvia un'istanza completa di Chromium, imposta un User-Agent autentico e inserisce ritardi simili a quelli umani. Il server blocca la richiesta durante l'handshake TLS, una tecnica chiamata TLS fingerprinting.

Spiegazione del TLS fingerprinting

Quando un browser apre una connessione HTTPS, invia un messaggio ClientHello. Il pacchetto elenca la versione TLS, le suite di cifratura supportate, un set di estensioni (curve ellittiche, algoritmi di firma) e altri campi. La combinazione esatta identifica in modo univoco lo stack di rete.

I ricercatori trasformano questi campi grezzi in un identificatore compatto chiamato JA3 (o il suo più recente parente JA4). Un browser Chrome autentico produce un hash; una libreria HTTP in Python ne produce un altro. Se l'hash del server non corrisponde all'User-Agent dichiarato, la richiesta viene contrassegnata come automatizzata.

Perché un browser Playwright standard può essere comunque segnalato

L'build Chromium predefinita di Playwright di solito emette il fingerprint corretto di Chrome, ma molti scraper aggiungono passaggi che ne compromettono la coerenza:

  1. Strategie di richiesta miste – Gli sviluppatori spesso lasciano che Playwright renderizzi pagine pesanti mentre un client HTTP leggero recupera risorse ausiliarie (JSON, immagini, ecc.). Queste chiamate veloci portano l'impronta digitale della libreria, non quella di Chrome, e il server rileva istantaneamente l'incongruenza.
  2. Proxy con terminazione TLS – Alcuni servizi proxy decriptano il flusso TLS, ispezionano o modificano il traffico, quindi lo ricriptano. Il server vede infine l'impronta digitale del proxy e potrebbe bloccarlo come client non appartenente a un browser.
  3. Altri livelli di protocollo – I sistemi anti-scraping confrontano anche le impostazioni HTTP/2, l'ordine degli header e la reputazione dell'IP. Una discrepanza in qualsiasi livello può innescare un blocco.

Da JA3 a JA4: la corsa agli armamenti

JA3 è stato il primo TLS fingerprint ampiamente adottato. Ora Chrome randomizza l'ordine delle sue estensioni a ogni avvio, rendendo l'hash JA3 instabile per un browser reale. JA4 risolve questo problema ordinando l'elenco delle estensioni prima dell'hashing, producendo un identificatore stabile anche quando Chrome rimescola l'ordine. Gli strumenti di rilevamento che adottano JA4 possono separare in modo affidabile le istanze Chrome reali dai client automatizzati che si limitano a copiare un hash JA3 statico.

Cosa possono fare gli sviluppatori oggi

Non esiste una "stringa magica" che inganni un server per sempre. L'approccio affidabile consiste nel far sì che ogni livello della richiesta racconti la stessa storia:

  • Allineare l'User-Agent, l'handshake TLS, le impostazioni HTTP/2 e l'ordine degli header con la stessa versione del browser e dello stesso sistema operativo.
  • Smettere di mescolare uno strumento di automazione browser completo con un client HTTP separato. Se la velocità è importante, lascia che Playwright gestisca tutte le chiamate di rete, anche quelle banali.
  • Scegliere proxy che lascino passare il TLS senza terminare la connessione, o configurarli per inoltrare l'handshake TLS originale senza modifiche.
  • Monitorare i servizi di reputazione IP; un pool di IP puliti riduce la probabilità di un blocco basato su abusi storici.

Il costo dell'ignorare la coerenza del fingerprint

Quando uno scraper viene bloccato durante la fase di handshake, non raggiunge mai la logica della pagina, quindi non vengono raccolti dati e non viene sprecato tempo nell'esecuzione di JavaScript. Le aziende che si affidano alla raccolta di dati su larga scala vedono aumentare i costi di calcolo cloud man mano che i cicli di riprovo (retry loops) si avviano. I blocchi ripetuti possono anche portare a ban dell'IP che influenzano altri traffici legittimi dalla stessa rete.

Punto di vista opposto: perché i siti utilizzano il TLS fingerprinting

I proprietari dei siti considerano il TLS fingerprinting come una difesa legittima. Lo scraping automatizzato può sovraccaricare i server, aggirare i paywall o raccogliere dati personali su larga scala. Verificando che il TLS fingerprint corrisponda al browser dichiarato, un sito filtra un'intera classe di bot a basso sforzo senza danneggiare gli utenti reali. La tecnica è meno invasiva dei CAPTCHA, preservando l'esperienza dell'utente.

Cosa monitorare in futuro

  • Adozione di JA4 – Ci si aspetta che più fornitori di sicurezza e provider CDN implementino il rilevamento basato su JA4 nei prossimi mesi.
  • Randomizzazione a livello di browser – Chrome e altri browser potrebbero continuare a variare i parametri TLS, spingendo gli strumenti di fingerprinting verso segnali più complessi come la temporizzazione del traffico o i pattern di esecuzione di JavaScript.
  • Risposta del mercato dei proxy – È probabile che emergano servizi che promettono il routing "TLS-transparent", rispondendo alla necessità della comunità di scraping di avere handshake invariati.

In sintesi

Se il tuo scraper Playwright viene rifiutato prima che venga caricata qualsiasi pagina, il colpevole è quasi certamente un'incongruenza nel TLS fingerprint. La soluzione non è una patch rapida; richiede un allineamento rigoroso di ogni livello del protocollo con il profilo browser dichiarato. La coerenza tra User-Agent, TLS handshake, impostazioni HTTP/2, ordine degli header e comportamento del proxy è l'unico modo affidabile per rimanere sotto il radar delle moderne difese anti-scraping.