Patchright Deep-Dive: automazione non rilevata e proxy residenziali

Patchright Deep-Dive: perché l'automazione legittima viene ancora bloccata

Se hai mai lanciato uno script Playwright contro una pagina protetta da Cloudflare Turnstile o DataDome e ti sei ritrovato davanti a un challenge infinito o a un 403 immediato, sai già che il problema non è solo il codice. Il problema è che il browser headless rivela la propria natura in modi che un semplice stealth.min.js non può nascondere. In questo Patchright Deep-Dive esaminiamo nel dettaglio i segnali di detection che i sistemi anti-bot moderni usano, cosa Patchright patcha realmente, cosa lascia scoperto e perché — anche con un browser perfettamente camuffato — la reputazione dell'IP ti blocca comunque se non usi proxy residenziali affidabili.

La domanda di ricerca che guida questo articolo è semplice ma profonda: come fa l'automazione legittima — ricerca di sicurezza autorizzata, raccolta di dati pubblici conforme — a passare pulitamente attraverso i sistemi anti-bot più aggressivi del 2025? La risposta richiede due ingredienti che devono lavorare insieme: un browser che non perda segnali a livello di runtime e di rete, e un'infrastruttura proxy che faccia corrispondere l'IP di uscita al fingerprint TLS del browser.

I segnali di detection che Patchright mira a neutralizzare

Prima di capire cosa fa Patchright, dobbiamo mappare i segnali concreti che i sistemi di detection raccolgono. Questi si dividono in quattro categorie principali: proprietà JavaScript del navigator, leak del protocollo CDP (Chrome DevTools Protocol), flag di avvio del processo, e fingerprint di rete (TLS/HTTP2).

1. navigator.webdriver e proprietà correlate

Il segnale più noto è navigator.webdriver === true, che il W3C WebDriver protocol imposta quando un browser è controllato da automazione. Playwright imposta questa proprietà per default. Ma i sistemi anti-bot non si limitano a questo: controllano anche navigator.languages (un array vuoto o con una sola lingua è sospetto), navigator.plugins.length (Chrome reale riporta almeno PDF Viewer e Chrome PDF Plugin), e window.chrome (l'oggetto runtime che esiste nei Chrome reali ma non nei build Chromium generici).

Patchright rimuove o normalizza questi segnali patchando il codice sorgente di Playwright a livello di compilazione, non tramite iniezione JavaScript a runtime. Questo è un punto critico: le librerie come puppeteer-extra-stealth e playwright-stealth iniettano script dopo il caricamento della pagina, ma esiste una finestra temporale in cui le proprietà originali sono visibili prima che lo script di patch venga eseguito. Patchright elimina questa race condition.

2. Leak del protocollo CDP: Runtime.enable e oltre

Questo è il segnale più sottile e più difficile da nascondere. Quando Playwright si connette a Chrome tramite CDP, invia comandi come Runtime.enable, Page.enable, Network.enable e Emulation.setDeviceMetricsOverride. Alcuni di questi comandi lasciano tracce rilevabili dal contesto JavaScript della pagina.

Ad esempio, l'esecuzione di Runtime.enable causa la presenza di Error.stackTraceLimit con valore 10 (invece del default di undefined o Infinity in alcuni build). Inoltre, l'uso di console.debug con stack trace attivati rivela frame di stack che contengono riferimenti al contesto CDP. I sistemi anti-bot avanzati come DataDome eseguono controlli come:

const stack = new Error().stack;
// Analizza i frame per rilevare contesti CDP

Patchright affronta questo problema patchando i comandi CDP inviati da Playwright in modo che non attivino questi side effect rilevabili. In particolare, evita di chiamare Runtime.enable quando non strettamente necessario e modifica il modo in cui Playwright gestisce gli stack trace. Questo è un vantaggio fondamentale rispetto a playwright-stealth, che non può intervenire a questo livello perché opera solo nel contesto della pagina.

3. Flag di avvio del processo e --disable-blink-features=AutomationControlled

Chrome, quando lanciato da Playwright/Puppeteer, aggiunge flag di avvio come --enable-automation, --disable-extensions, e altri che modificano il comportamento del browser. Il flag --enable-automation in particolare causa la visualizzazione della barra "Chrome is being controlled by automated test software" e imposta navigator.webdriver = true.

Patchright inietta --disable-blink-features=AutomationControlled nei flag di avvio, che è il flag standard per sopprimere il segnale navigator.webdriver a livello di Blink (il motore di rendering di Chrome). Ma va oltre: rimuove anche altri flag rivelatori come --enable-automation e --disable-blink-features=AutomationControlled viene applicato in modo che non appaia nella lista dei flag visibili tramite chrome://version o altre interfacce interne.

4. TLS/JA3 e l'uso di channel='chrome'

Forse il contributo più importante di Patchright è l'uso di channel='chrome' invece del Chromium bundled. Quando avvii Playwright con il Chromium di default, il ClientHello TLS (il cui hash è noto come JA3 o JA4) corrisponde al fingerprint di Chromium, non di Chrome. Questo è un segnale immediato per sistemi come Cloudflare: il JA3 dice "Chromium headless" ma l'User-Agent dice "Chrome".

Usando channel='chrome', Patchright si assicura che il browser lanciato sia il vero Chrome installato sul sistema, con il suo stack TLS nativo. Questo significa che il JA3/JA4 fingerprint corrisponde esattamente a quello di un Chrome reale. La differenza è misurabile: il JA3 di Chromium headless ha un fingerprint come 771,4865-4866-4867-49195-49199-...,..., mentre Chrome stabile ha un fingerprint leggermente diverso per via delle curve ellittiche e delle estensioni supportate.

Per approfondire il formato JA3, la RFC 8446 (TLS 1.3) definisce la struttura del ClientHello, e strumenti come JA3 di Salesforce documentano come l'hash venga calcolato dai campi del ClientHello.

Cosa Patchright patcha — e cosa non patcha

È cruciale capire i limiti di Patchright. Non è una soluzione magica che rende il browser indistinguibile da un umano. Ecco una tabella comparativa delle aree coperte:

Segnale	Patchright	playwright-stealth	Camoufox
navigator.webdriver	Patchato a sorgente	Patchato via JS injection	N/A (Firefox-based)
CDP Runtime.enable leak	Patchato	Non patchato	N/A
Flag di avvio del processo	Patchato	Parzialmente	Diverso approccio
TLS/JA3 fingerprint	Tramite channel='chrome'	Non gestito	Firefox JA3 nativo
Canvas fingerprint	Non patchato	Parzialmente (noise)	Patchato (noise controllato)
WebGL fingerprint	Non patchato	Parzialmente	Patchato
Fonts enumerate	Non patchato	Non patchato	Patchato
Segnali comportamentali (mouse, timing)	Non patchato	Non patchato	Parzialmente

Come si vede, Patchright chiude i leak più tecnici e rilevanti (CDP, flag, TLS), ma lascia aperti i fingerprint basati su rendering. Questo significa che se il sito target fa canvas fingerprinting — ovvero legge i pixel renderizzati di un elemento <canvas> per generare un hash unico del tuo hardware/driver — Patchright non ti aiuta. Il canvas hash di un server Linux headless con driver software sarà diverso da quello di un Windows 11 con GPU NVIDIA.

Differenze con Camoufox

Camoufox prende un approccio diverso: è un fork di Firefox, non di Chrome. Questo ha vantaggi e svantaggi. Il vantaggio principale è che Camoufox patcha canvas, WebGL, e font a livello di motore di rendering (Gecko), generando rumore controllato o valori realistici. Lo svantaggio è che Firefox ha una quota di mercato del ~3% globale, quindi un fingerprint Firefox è intrinsecamente meno comune e può destare sospetto in certi contesti geografici o verticali.

La scelta tra Patchright e Camoufox dipende dal target: se il sito usa Cloudflare con sfiducia verso Firefox, Chrome è più sicuro. Se il sito fa canvas fingerprinting aggressivo, Camoufox è superiore. Per la maggior parte dei casi d'uso di scraping su infrastrutture Cloudflare/DataDome, Patchright con Chrome è il punto di partenza migliore.

Perché la reputazione dell'IP conta ancora dopo aver chiuso i leak CDP

Qui arriviamo al cuore del problema. Anche se Patchright chiude tutti i leak a livello di browser — navigator.webdriver è false, CDP non lascia tracce, il JA3 corrisponde a Chrome reale — il sistema anti-bot ha ancora un segnale potentissimo: l'IP da cui arriva la richiesta.

Cloudflare Turnstile e DataDome assegnano un punteggio di rischio all'IP basato su molteplici fattori:

• ASN type: datacenter ASN (es. OVH, DigitalOcean, AWS) riceve un punteggio di rischio alto per default. ASN residenziali (Comcast, AT&T, Vodafone) ricevono un punteggio basso.
• Storico dell'IP: se l'IP è stato visto fare richieste automated in passato, o se è in blacklist note.
• Geolocalizzazione vs. browser locale: se l'IP è in Germania ma navigator.language è en-US e il fuso orario è Pacifico, c'è una discrepanza.
• Volumetria: se lo stesso IP fa 500 richieste/minuto a un sito, anche con un browser perfetto, il rate limit scatta.

Un datacenter IP con un punteggio di rischio alto viene sottoposto a challenge più aggressivi o bloccato direttamente, indipendentemente dal fingerprint del browser. Dati pubblici di Cloudflare indicano che il sistema assegna un phishing score e un bot score separati, e l'IP reputation pesa fino al 40% del bot score iniziale.

Ecco perché i proxy residenziali sono non negoziabili per l'automazione seria. Un IP residenziale di un ISP statunitense (es. Comcast, Spectrum) ha un punteggio di rischio basso per default perché è lo stesso tipo di IP da cui navigano milioni di utenti reali. Cloudflare non può bloccare tutti gli IP Comcast senza bloccare utenti legittimi.

Proxy residenziali vs. datacenter vs. mobile

Tipo	Reputazione IP	Costo	Stabilità sessione	Caso d'uso ideale
Datacenter	Bassa (alto rischio)	$0.5–2/GB	Alta	Testing, API non protette
Residenziale	Alta (basso rischio)	$2–8/GB	Media (rotazione)	Scraping Cloudflare/DataDome
Mobile (4G/5G)	Altissima	$4–12/GB	Bassa (NAT condiviso)	Sfide anti-bot estreme

I proxy mobile hanno la reputazione più alta perché gli IP cellulari sono condivisi tra migliaia di dispositivi reali tramite NAT carrier-grade. Ma la stabilità della sessione è bassa perché l'IP cambia frequentemente. Per la maggior parte dei workflow di scraping, i residenziali con sessioni sticky offrono il miglior compromesso.

Allineamento TLS/HTTP2: far coincidere IP e fingerprint

C'è un aspetto tecnico che molti ingegneri trascurano: l'allineamento tra il fingerprint TLS del browser e l'IP di uscita. Se il tuo browser ha un JA3 di Chrome 120 su Windows, ma il tuo IP residenziale è assegnato a un dispositivo Android in una rete mobile coreana, c'è una discrepanza che un sistema anti-bot avanzato può rilevare.

Il principio è: l'IP, il JA3, il JA4, l'HTTP/2 fingerprint (Akamai fingerprint) e l'User-Agent devono raccontare una storia coerente.

Ad esempio:

• IP residenziale USA + Chrome JA3 + UA Chrome Windows + navigator.language = en-US + fuso orario America/New_York = storia coerente.
• IP residenziale Germania + Chrome JA3 + UA Chrome Windows + navigator.language = de-DE + fuso orario Europe/Berlin = storia coerente.
• IP datacenter USA + Chrome JA3 + UA Chrome Mac + navigator.language = ja-JP + fuso orario Asia/Tokyo = storia incoerente, alta probabilità di blocco.

Con ProxyHat puoi specificare il paese di uscita nel username del proxy, assicurando che l'IP residenziale corrisponda alla geolocalizzazione del browser. Ad esempio, se configuri user-country-US-session-abc123, ottieni un IP residenziale statunitense che resta stabile per la durata della sessione. Puoi verificare le locazioni disponibili per allineare paese del proxy e fingerprint del browser.

Esempio pratico: Patchright con proxy residenziali ProxyHat

Vediamo un esempio concreto di automazione legittima: un ricercatore di sicurezza che racclie dati pubblici da una pagina protetta, usando Patchright con un proxy residenziale sticky di ProxyHat. Lo scenario è un test di penetration testing autorizzato su un sito pubblico che usa Cloudflare Turnstile.

from patchright.sync_api import sync_playwright
import urllib.parse

# Configurazione proxy ProxyHat — sessione sticky residenziale USA
proxy_user = 'user-country-US-session-abc123'
proxy_pass = 'PASSWORD'
proxy_host = 'gate.proxyhat.com'
proxy_port = 8080

proxy_url = f'http://{urllib.parse.quote(proxy_user)}:{urllib.parse.quote(proxy_pass)}@{proxy_host}:{proxy_port}'

with sync_playwright() as p:
    # Usa channel='chrome' per il vero stack TLS di Chrome
    browser = p.chromium.launch_persistent_context(
        user_data_dir='./browser_profile',
        channel='chrome',
        headless=False,
        proxy={'server': proxy_url},
        no_viewport=True,
        args=[
            '--disable-blink-features=AutomationControlled',
        ],
    )
    
    page = browser.new_page()
    
    # Naviga alla pagina protetta
    page.goto('https://example.com/protected-page', wait_until='networkidle')
    
    # Attendi che la pagina carichi completamente
    page.wait_for_timeout(3000)
    
    # Verifica che siamo passati attraverso il challenge
    content = page.content()
    if 'challenge' in content.lower():
        print('Ancora in challenge — possibile problema di fingerprint')
    else:
        print('Pagina caricata con successo')
        # Estrai dati pubblici
        title = page.title()
        print(f'Titolo: {title}')
    
    browser.close()

Alcuni punti chiave di questo esempio:

• launch_persistent_context invece di launch: mantiene cookie, localStorage e stato tra le esecuzioni, simulando un browser reale che ha una cronologia.
• channel='chrome': usa il Chrome installato sul sistema, non il Chromium bundled, garantendo un JA3/JA4 autentico.
• user_data_dir: una directory persistente che accumula stato, rendendo il browser più credibile.
• Sessione sticky: session-abc123 mantiene lo stesso IP per tutta la durata della sessione, evitando rotazioni che triggererebbero re-authentication.

Versione con curl per testing rapido del proxy

Prima di lanciare il browser completo, puoi verificare che il proxy residenziale funzioni e che l'IP di uscita sia corretto:

curl -x http://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:8080 \
  https://api.ipify.org?format=json

Questo dovrebbe restituire un IP statunitense. Se cambi session-abc123 in session-xyz789, ottieni un IP diverso ma sempre statunitense. Per approfondire le opzioni di configurazione, consulta la documentazione ufficiale di ProxyHat.

Versione Node.js con Patchright

const { chromium } = require('patchright');

const proxyConfig = {
  server: 'http://gate.proxyhat.com:8080',
  username: 'user-country-US-session-abc123',
  password: 'PASSWORD'
};

(async () => {
  const browser = await chromium.launchPersistentContext('./browser_profile', {
    channel: 'chrome',
    headless: false,
    proxy: proxyConfig,
    args: ['--disable-blink-features=AutomationControlled']
  });

  const page = await browser.newPage();
  await page.goto('https://example.com/protected-page', {
    waitUntil: 'networkidle'
  });

  await page.waitForTimeout(3000);
  console.log('Title:', await page.title());
  await browser.close();
})();

Errori comuni e edge case

1. Dimenticare di impostare channel='chrome'

Se ometti channel='chrome', Patchright userà il Chromium bundled, che ha un JA3 diverso da Chrome. Questo è il singolo errore più comune e il più difficile da diagnosticare, perché tutto il resto sembra funzionare ma il sito continua a mostrare challenge.

2. Usare headless=True su siti aggressivi

Anche se Patchright patcha molti segnali headless, alcuni siti rilevano ancora il headless mode tramite timing di rendering (headless renderizza più velocemente, senza GPU reale). Per siti con protezione massima, usa headless=False con un display virtuale (Xvfb su Linux) o un servizio come xvfb-run.

3. Rotazione IP troppo frequente

Se cambi IP ad ogni richiesta senza una sessione sticky, il sito vede un pattern di richieste da IP sempre diversi con lo stesso fingerprint browser. Questo è più sospetto di un singolo IP che fa molte richieste. Usa sessioni sticky di 10–30 minuti per simulare una sessione utente reale.

4. Discrepanza tra geolocalizzazione del proxy e del browser

Se il proxy è in USA ma il browser ha navigator.language = 'de-DE' e Intl.DateTimeFormat().resolvedOptions().timeZone = 'Europe/Berlin', il sistema anti-bot rileva l'incongruenza. Imposta sempre:

context = browser.new_context(
    locale='en-US',
    timezone_id='America/New_York',
    geolocation={'latitude': 40.7128, 'longitude': -74.0060},
    permissions=['geolocation']
)

5. Non gestire il canvas fingerprint

Patchright non patcha il canvas. Se il sito target fa canvas fingerprinting, considera di aggiungere una libreria di noise injection sul canvas (con cautela, perché un noise troppo aggressivo è anch'esso rilevabile). In alternativa, usa Camoufox per questi target specifici.

Dove questo è appropriato — e dove non lo è

È fondamentale essere chiari sui limiti etici e legali di queste tecniche. L'uso di Patchright con proxy residenziali è appropriato per:

• Ricerca di sicurezza autorizzata: penetration testing con consenso scritto del proprietario del sistema target.
• Raccolta di dati pubblici conforme: scraping di pagine pubbliche che non richiedono login, rispettando robots.txt e i Terms of Service.
• Monitoraggio di prezzi e SERP: raccolta di dati di pricing pubblici per analisi competitiva, nel rispetto dei limiti di rate.
• QA automation: test della propria infrastruttura o di servizi per cui si ha autorizzazione.

Non è appropriato per:

• Accesso non autorizzato a sistemi protetti da login.
• Creazione di account falsi o manipolazione di sistemi di autenticazione.
• Frode pubblicitaria o click fraud.
• Violazione di Terms of Service o di leggi come il Computer Fraud and Abuse Act (CFAA) negli USA o il GDPR in Europa per dati personali.

Il GDPR, in particolare, richiede una base legale per il trattamento di dati personali, anche se raccolti da fonti pubbliche. Se i dati che raccogli contengono informazioni personali di individui UE, devi avere una base legale (consenso, interesse legittimo, ecc.) e rispettare i principi di minimizzazione dei dati. Per approfondire, consulta le linee guida GDPR.

Ottimizzazione delle performance e della affidabilità

Oltre alla detection, ci sono considerazioni pratiche di performance quando si usa Patchright con proxy residenziali:

• Latency: i proxy residenziali aggiungono 50–200ms di latency rispetto ai datacenter. Pianifica di usare wait_until='domcontentloaded' invece di 'networkidle' quando possibile per ridurre i timeout.
• Concorrenza: con ProxyHat puoi mantenere 100+ sessioni sticky concorrenti, ma ogni sessione dovrebbe avere il proprio user_data_dir per evitare conflitti di stato.
• Retry logic: implementa retry con backoff esponenziale (es. 3 retry con 2s, 4s, 8s) per gestire occasionali fallimenti di proxy.
• Success rate target: con Patchright + proxy residenziali ProxyHat, un success rate del 90–95% è realistico su siti protetti da Cloudflare. Siti con DataDome possono richiedere ottimizzazione aggiuntiva.

Per i costi, consulta la pagina prezzi di ProxyHat per i piani residenziali. Per use case specifici come web scraping o SERP tracking, ProxyHat offre configurazioni ottimizzate.

Key Takeaways

Patchright chiude i leak tecnici, non i fingerprint di rendering. Navigator.webdriver, CDP Runtime.enable, flag di avvio e JA3 sono gestiti. Canvas, WebGL, font e segnali comportamentali richiedono soluzioni aggiuntive.

L'IP reputation è il 40% del bot score iniziale. Anche con un browser perfetto, un IP datacenter ti blocca. I proxy residenziali non sono opzionali per l'automazione su siti protetti.

L'allineamento IP-fingerprint è critico. Il paese del proxy, il JA3, l'User-Agent e navigator.language devono raccontare una storia coerente.

channel='chrome' è il singolo setting più importante. Senza di esso, il JA3 non corrisponde a Chrome reale e tutto il resto è inutile.

L'uso legittimo è non negoziabile. Ricerca di sicurezza autorizzata e raccolta di dati pubblici conforme sono i casi d'uso appropriati. Frode, abuso di login e violazione dei ToS sono fuori scope.

Conclusione e prossimi passi

Patchright rappresenta un avanzamento significativo nell'automazione non rilevata: patchando a livello di sorgente i leak che librerie come playwright-stealth non possono raggiungere, riduce drasticamente la superficie di detection. Ma da solo non basta. La combinazione di Patchright con proxy residenziali affidabili — che forniscano IP con buona reputazione e allineamento geografico — è ciò che permette all'automazione legittima di passare pulitamente attraverso sistemi come Cloudflare Turnstile e DataDome.

Per iniziare, registra un account su ProxyHat, configura una sessione sticky residenziale con il paese appropriato, e testa con l'esempio di codice sopra. Misura il success rate su 100 richieste e ottimizza da lì. Per scenari avanzati con fingerprint canvas, valuta Camoufox come complemento.