Lo script di automazione funziona in locale. Lo metti in produzione e nel giro di ore inizia a restituire 403, CAPTCHA o pagine vuote dove il contenuto non viene mai caricato. Il codice non è cambiato. Il sito target è lo stesso. Quello che è cambiato è l'ambiente in cui gira il browser — e i sistemi anti-bot leggono quell'ambiente su quattro livelli distinti.
In breve: L'automazione del browser viene bloccata perché i sistemi anti-bot controllano quattro livelli: identità del browser (fingerprint), segnali di rete (IP e TLS), pattern comportamentali (mouse e timing) e gestione delle sessioni (cookie e stato). Risolvere un solo livello lascia gli altri tre esposti. La soluzione strutturale parte dal basso: un browser con fingerprint coerenti e routing proxy a livello di engine, poi gestisci comportamento e sessioni nel codice.
Why automation gets blocked
I sistemi anti-bot come Cloudflare, Akamai, PerimeterX e DataDome non si basano su un singolo controllo. Assegnano un punteggio alla sessione su più segnali contemporaneamente. Un IP pulito con il flag navigator.webdriver esposto viene comunque bloccato. Un fingerprint perfetto da un IP datacenter viene comunque bloccato. Il rilevamento è a livelli, quindi anche la difesa deve esserlo.
I quattro livelli, dal più fondamentale al più situazionale:
| Livello | Cosa controlla | Dove si risolve |
|---|---|---|
| 1. Identità browser | Fingerprint, flag di automazione, segnali engine | Binary del browser |
| 2. Rete | Reputazione IP, TLS fingerprint, DNS, WebRTC | Configurazione proxy |
| 3. Comportamento | Movimenti mouse, timing, pattern di scroll | Codice applicativo |
| 4. Sessione | Cookie, stato login, frequenza richieste | Codice applicativo |
I livelli 1 e 2 sono problemi infrastrutturali. I livelli 3 e 4 sono problemi di codice. La maggior parte degli sviluppatori parte dal livello 3 (aggiungendo delay casuali) mentre i livelli 1 e 2 sono completamente scoperti. Per questo la correzione non regge mai.
Layer 1: Browser identity
Qui fallisce la maggior parte dell'automazione, ed è dove la maggior parte degli sviluppatori non guarda.
Un'istanza Chromium stock controllata da Playwright o Puppeteer espone segnali di automazione da 20+ superfici: navigator.webdriver è impostato su true, l'oggetto chrome.runtime manca, le stringhe WebGL renderer espongono driver GPU headless, i readback Canvas producono hash deterministici e gli output AudioContext non corrispondono a hardware reale. Gli script anti-bot raccolgono tutto nei primi 200ms del caricamento pagina, prima ancora che il tuo codice venga eseguito.
What doesn't work
I plugin stealth come puppeteer-extra-plugin-stealth o playwright-stealth patchano alcuni segnali a livello di pagina. Sovrascrivono navigator.webdriver con JavaScript. Il problema: i sistemi anti-bot leggono i segnali direttamente dall'engine del browser, non solo dalla pagina. Un override JavaScript di navigator.webdriver è rilevabile perché il property descriptor è diverso da un browser reale. I readback Canvas e WebGL vengono dalla pipeline GPU, non da JavaScript. Le patch a livello di pagina non raggiungono l'engine.
Le stringhe User-Agent casuali cambiano un segnale su 20+. Se il tuo User-Agent dice macOS ma il WebGL renderer riporta un driver GPU Linux, i font sono solo Windows e il timezone offset non corrisponde alla locale — l'incoerenza è peggio che non fare spoofing.
La modalità headless (--headless) produce un fingerprint completamente diverso dal Chrome in modalità headed. Dimensioni dello schermo, pipeline di rendering GPU, rendering dei font e lista plugin: tutto cambia. Alcuni siti bloccano headless direttamente.
What works
La soluzione è a livello di binary del browser. Un anti-detect browser patcha i segnali fingerprint dentro l'engine Chromium così da essere coerenti su tutte le 20+ superfici: Canvas, WebGL, AudioContext, font, proprietà navigator, client rects, media devices, dimensioni schermo, timezone, lingua e WebRTC riportano tutti valori che corrispondono a un singolo profilo dispositivo reale.
La parola chiave è coerenza. Fare spoofing di segnali individuali crea contraddizioni. I fingerprint gestiti garantiscono che ogni segnale racconti la stessa storia.
Per l'analisi completa di tutti i 20+ segnali, vedi Browser Fingerprinting: I 20+ Segnali Che i Sistemi Anti-Bot Usano per Rilevare l'Automazione.
Layer 2: Network
Un'identità browser pulita da un IP segnalato viene comunque bloccata. I sistemi anti-bot controllano il livello di rete in modo indipendente.
IP reputation
Gli IP datacenter (AWS, GCP, Azure, DigitalOcean) sono catalogati. I provider anti-bot mantengono database di range IP associati a infrastruttura cloud. Le richieste da questi range ricevono controlli più severi o blocchi diretti, indipendentemente dal fingerprint del browser.
Gli IP residenziali da ISP reali hanno tassi di blocco molto più bassi. La differenza è misurabile: lo stesso script di automazione con la stessa identità browser può passare da un tasso di blocco del 90% su un IP datacenter a meno del 5% su un proxy residenziale.
TLS fingerprint
Ogni connessione HTTPS inizia con un TLS handshake. L'ordine delle cipher suite, delle estensioni e delle curve supportate nel messaggio ClientHello crea un TLS fingerprint (JA3/JA4). Chromium stock, Chrome headless e Playwright producono ciascuno hash JA3 diversi. Se il TLS fingerprint dice "tool di automazione" mentre lo User-Agent dice "Chrome 126 su macOS", la sessione viene segnalata.
La soluzione: usare un binary del browser che produce un TLS fingerprint da Chrome reale. I proxy a livello di pagina e le librerie HTTP non possono risolvere il TLS fingerprinting perché l'handshake avviene prima che qualsiasi JavaScript venga eseguito.
Geographic alignment
Se il fingerprint del browser riporta locale US English con timezone US ma l'IP geolocalizza un datacenter a Francoforte, i sistemi anti-bot segnalano la discrepanza. Il routing proxy deve allineare la geografia: la posizione dell'IP deve corrispondere a timezone, lingua e locale del fingerprint.
WebRTC leaks
WebRTC può esporre il tuo IP reale anche quando passi attraverso un proxy. Le richieste STUN bypassano la configurazione del proxy HTTP e si connettono direttamente, rivelando l'IP di origine. Questo va gestito a livello di browser, non nel codice applicativo.
Layer 3: Behavioral patterns
Con i livelli 1 e 2 gestiti a livello infrastrutturale, il livello 3 è dove conta il tuo codice applicativo.
I sistemi anti-bot tracciano come la sessione interagisce con la pagina. Gli utenti reali non navigano come gli script: non cliccano elementi entro 5ms dal caricamento pagina, non scrollano a velocità costante di 500px/s e non visitano 200 pagine in 60 secondi senza alcun tempo di inattività.
What to implement
Delay casuali tra le azioni. Non un sleep(2000) fisso — un range randomizzato che varia per tipo di azione.
import random
import asyncio
async def human_delay(min_ms=800, max_ms=2500):
delay = random.uniform(min_ms, max_ms) / 1000Movimenti mouse realistici. Sposta il cursore sull'elemento prima di cliccare, invece di teletrasportarti. Alcuni sistemi anti-bot tracciano le sequenze di eventi mouse e segnalano click senza eventi mousemove precedenti.
async def move_and_click(page, selector):
element = await page.query_selector(selector)
box = await element.bounding_box()
# Move to element with some randomness in the endpoint
x = box["x"] + box["width"] * random.uniform(0.3, 0.7)Comportamento di scroll. Scrolla incrementalmente, non alla posizione esatta dell'elemento. Gli utenti reali scrollano oltre il target e poi tornano indietro.
Pacing delle richieste. Se stai facendo hit sullo stesso dominio, distanzia le richieste così che la sessione non sembri un crawler. 2-5 secondi tra le navigazioni è un punto di partenza ragionevole per la maggior parte dei siti.
Layer 4: Session management
L'ultimo livello riguarda lo stato. I sistemi anti-bot tracciano le sessioni nel tempo e segnalano pattern che nessun utente reale produce.
Cookie persistence
I browser reali accumulano cookie nel corso di più visite. Una sessione che arriva con zero cookie, li accetta tutti e poi si ripresenta cinque minuti dopo di nuovo con zero cookie è palesemente automatizzata. Persisti lo stato dei cookie tra un'esecuzione e l'altra usando profili browser isolati.
Login state
Se la tua automazione effettua login su un account, mantieni quella sessione. Fare login, eseguire un'azione e fare logout ripetutamente da fingerprint diversi segnala l'account.
Session isolation
Quando esegui più sessioni concorrenti (scraping di sezioni diverse, gestione di account multipli), ogni sessione ha bisogno del proprio contesto isolato: cookie separati, local storage separato, fingerprint separato. La cross-contamination tra sessioni — dove i cookie della sessione A finiscono nella sessione B — è una causa frequente di blocchi nell'automazione concorrente.
from playwright.async_api import async_playwright
async def isolated_session(profile_name, target_url):
async with async_playwright() as p:
# Connect to Clawbrowser with an isolated profileRate limiting yourself
Monitora i tuoi pattern di richieste verso un singolo target. Se stai facendo 1.000 richieste all'ora sullo stesso dominio, nessuna gestione di fingerprint ti salverà. Imposta limiti ragionevoli per dominio e ruota le sessioni quando ti avvicini alle soglie. Puoi farlo distribuendo il carico di richieste tra account multipli, ciascuno con il proprio profilo browser e proxy.
Putting it together
I livelli 1 e 2 sono infrastruttura. Non dovresti risolverli nel codice applicativo. Un anti-detect browser con fingerprint gestiti e routing proxy integrato si occupa di entrambi i livelli a livello di engine, così il tuo codice gestisce solo i livelli 3 e 4.
Clawbrowser è un fork di Chromium che gestisce questi livelli infrastrutturali: patch dei fingerprint a livello engine su 20+ superfici, routing proxy integrato con allineamento geografico, prevenzione leak WebRTC e supporto CDP nativo. Il tuo codice Playwright o Puppeteer si connette come a qualsiasi altra istanza Chrome.
from playwright.async_api import async_playwright
import random, asyncio
async def scrape_with_clawbrowser():
async with async_playwright() as p:Inizia copiando il prompt di installazione da clawbrowser.ai e incollandolo nel tuo AI agent — il setup richiede meno di due minuti.
I livelli sono indipendenti. Se vieni bloccato, diagnostica quale livello è la causa. Se hai già confermato che i fingerprint sono puliti e il tuo IP non è segnalato, il problema è nel codice comportamentale o nella gestione delle sessioni. Se il comportamento è realistico ma vieni comunque bloccato, il problema è nell'identità del browser o nel livello di rete. Lavora dal basso verso l'alto.
Per una diagnostica passo-passo quando compaiono i CAPTCHA, vedi Perché la Tua Automazione Continua a Far Scattare i CAPTCHA: Guida Diagnostica dei 7 Segnali.
What doesn't work (and why)
| Approccio | Perché non funziona |
|---|---|
Flag --headless |
Produce un fingerprint diverso dal Chrome headed. Molti siti bloccano headless direttamente. |
| Plugin stealth | Patchano i segnali a livello di pagina. I segnali a livello engine restano esposti. Rilevabili entro mesi da ogni release. |
| Rotazione User-Agent casuali | Cambia 1 segnale su 20+. Crea incoerenza con gli altri segnali fingerprint. |
| Rotazione solo degli IP | Risolve il livello 2 ma lascia il livello 1 completamente scoperto. Un IP pulito con un'identità browser che perde segnali viene comunque bloccato. |
sleep(5) ovunque |
Risolve un aspetto del livello 3. Non tocca i livelli 1, 2 e il resto del livello 3. |
Il filo conduttore: ogni approccio corregge un segnale in un livello. I sistemi anti-bot controllano tutti e quattro i livelli contemporaneamente. Le soluzioni parziali non sopravvivono in produzione.
FAQ
Cloudflare riesce a rilevare Playwright?
Sì. Playwright stock su Chromium standard viene rilevato da Turnstile e Bot Management di Cloudflare in pochi secondi. Il rilevamento avviene principalmente al livello 1 (identità browser): navigator.webdriver, artefatti CDP, differenze nel rendering WebGL e TLS fingerprinting. Per un'analisi dettagliata, vedi Perché i Tuoi Script Playwright Continuano a Essere Bloccati da Cloudflare.
Servono proxy residenziali?
Per i siti con sistemi anti-bot aggressivi, sì. Gli IP datacenter sono catalogati dai provider anti-bot e ricevono controlli più severi. I proxy residenziali da ISP reali riducono significativamente i tassi di blocco. Però un IP residenziale con un fingerprint browser che perde segnali viene comunque bloccato. I proxy risolvono il livello 2, non il livello 1.
La modalità headless viene sempre rilevata?
Chrome headless moderno (--headless=new) è più vicino alla modalità headed rispetto alla vecchia implementazione, ma restano differenze nel rendering GPU, nelle metriche schermo e nella disponibilità dei font. I siti con rilevamento sofisticato (Cloudflare, Akamai, DataDome) distinguono ancora le sessioni headless. Per target ad alto valore, la modalità headed con un anti-detect browser adeguato è la scelta affidabile.
Quanto velocemente posso fare scraping senza essere bloccato?
Non esiste un numero universale. Dipende dai rate limit del sito target e dalla sensibilità del rilevamento. Un punto di partenza ragionevole: 2-5 secondi tra le navigazioni sullo stesso dominio, randomizzati in quel range. Monitora il tasso di blocco e rallenta se aumenta. Alcuni siti tollerano 1 richiesta al secondo. Altri segnalano qualsiasi cosa sopra 1 richiesta ogni 10 secondi da una singola sessione.
L'automazione browser per agenti AI ha gli stessi problemi di rilevamento?
Sì. I framework per agenti AI come Claude Code, Codex, Cursor e Hermes Agent controllano i browser tramite CDP. L'identità del browser è quello che i sistemi anti-bot verificano, non se i comandi provengono da un umano o da un agente. Un agente AI connesso a un'istanza Chrome standard viene bloccato per le stesse ragioni di uno script Playwright. Vedi CDP Browser per Agenti AI: Guida per Sviluppatori per il setup specifico per agenti.
Start from the bottom
L'automazione browser viene bloccata perché i sistemi anti-bot controllano quattro livelli e la maggior parte dell'automazione ne indirizza solo uno o due. Risolvi dal basso verso l'alto: prima l'identità del browser, poi la rete, poi il comportamento, poi le sessioni. I primi due livelli sono problemi infrastrutturali che appartengono al browser, non al tuo codice.
Inizia copiando il prompt di installazione da clawbrowser.ai e incollandolo nel tuo AI agent — il setup richiede meno di due minuti.
Poi concentra il codice sui livelli 3 e 4: timing realistico, movimenti mouse, isolamento delle sessioni e gestione dei rate. Questo è lo stack che regge in produzione.
Continua a leggere
Articoli correlati
Puppeteer-Extra-Stealth è obsoleto: cosa usa l'automazione moderna
puppeteer-extra-plugin-stealth non viene aggiornato dal 2023. Ecco perché fallisce con i sistemi anti-bot moderni e cosa usare al suo posto.
Leggi l’articolo →
Web scraping senza essere rilevati: tecniche che reggono
Guida pratica al web scraping: ricognizione, HTTP o browser, estrazione dati, paginazione, sessioni e scala con Playwright.
Leggi l’articolo →