Un problema molto comune con Puppeteer è questo: le prime richieste vanno a buon fine, poi quelle successive restituiscono un errore 403 o 429, vanno in timeout oppure finiscono su una pagina di verifica. Eppure molte guide continuano a presentare i proxy rotanti come se bastassero due righe di configurazione.
Non è così. Il divario tra un esempio con "aggiungi il flag --proxy-server" e un sistema davvero mantenibile è enorme. Questa guida copre la rotazione a livello di browser, gateway autenticati, sharding del browser o relay esterni, profili browser coerenti, gestione degli errori in ottica produzione e una risposta sincera alla domanda: quando è meglio non gestire i proxy in prima persona.
Che cos'è un proxy rotante e perché Puppeteer ne ha bisogno?
Un proxy fa da intermediario tra la tua istanza di Puppeteer e il sito che stai interrogando. Il sito vede l’IP di uscita del proxy, non quello della tua macchina. Un proxy rotante alterna un pool di IP di uscita — a volte per richiesta, a volte per sessione — così il traffico non sembra provenire da un unico client che martella il server centinaia di volte di fila.
Puppeteer ne ha bisogno in modo particolare perché un browser Chrome headless che invia centinaia di richieste sequenziali dallo stesso IP è esattamente il tipo di schema che i sistemi anti-bot sono progettati per intercettare. La documentazione di Cloudflare descrive diversi livelli di rilevamento attivi contemporaneamente: euristiche, controlli sulle fingerprint JavaScript, modelli di machine learning e analisi delle anomalie comportamentali. Cambiare IP copre solo uno di questi livelli. Uno soltanto.
Vale la pena distinguere tre tipi di proxy, perché non sono intercambiabili:
- Proxy datacenter — economici, veloci e forniti da hosting provider. Sono facili da segnalare perché l’ASN (il blocco di rete) è chiaramente di un data center, non di una rete domestica.
- Proxy residential — transitano attraverso veri ISP consumer, quindi assomigliano a connessioni domestiche reali. Sono più lenti e costosi, ma molto più credibili.
- Proxy mobile — IP di reti mobili, in genere l’opzione più costosa, utile quando serve davvero un’identità da rete mobile.
Gli IP residential possono essere meno evidenti dei datacenter se valutati solo tramite ASN, ma nessuna delle due categorie è immune ai blocchi. Non esiste una soglia universale di rilevamento: il risultato dipende dal target, dalla reputazione dell’IP di uscita, dalla localizzazione, dalla cronologia della sessione, dal profilo del browser e dal comportamento delle richieste.
Un’altra distinzione che spesso crea confusione: una lista statica gestita da te (usi il pool, scegli il prossimo IP, gestisci i fallimenti) è diversa da un proxy backconnect/gateway (ti connetti a un solo endpoint e il provider ruota gli IP dietro le quinte). Entrambi sono validi; semplicemente spostano la complessità in punti diversi.
Perché configurare proxy rotanti in Puppeteer? Casi d'uso comuni
La risposta onesta è: probabilmente non ti servono finché non ti servono davvero. E quando ti servono, ne hai bisogno sul serio.
| Caso d'uso | Perché la rotazione è importante |
|---|---|
| Monitoraggio prezzi su cataloghi prodotto | Richieste ripetute sullo stesso IP possono accumulare limiti di frequenza e segnali di reputazione |
| Arricchimento lead / estrazione dati contatto | Visite ripetute a profili dallo stesso IP sembrano scraping, non navigazione, e vengono intercettate dai motori comportamentali |
| Scraping di SERP | I motori di ricerca sono tra i più aggressivi nel limitare IP e nel mostrare CAPTCHA |
| Analisi della concorrenza | Estrarre ripetutamente dati dallo stesso dominio per giorni costruisce una fingerprint legata all’IP e alla cronologia dei cookie |
| Aggregazione contenuti | Molte pagine, poco valore per pagina: esattamente il profilo di traffico che i sistemi anti-bot sono tarati per bloccare |
Non esiste un numero fisso e citabile del tipo "Amazon blocca al request 51". I siti non pubblicano soglie universali, e i controlli possono cambiare in base all’endpoint, allo stato dell’account, alla reputazione ASN e al tipo di traffico. Parti dal tasso di richieste autorizzato più basso possibile, verifica il contenuto oltre agli status code e aggiungi la rotazione solo quando il comportamento misurato e le policy del target lo giustificano.
Tre strategie di rotazione proxy in Puppeteer: quale ti serve?
Questa è la parte che molti tutorial saltano del tutto o, peggio, mostrano solo nella versione più grezza. Esistono tre livelli di granularità, e scegliere quello sbagliato significa sprecare tempo o complicare inutilmente un lavoro semplice.
| Strategia di rotazione | Granularità | Riavvio del browser? | Complessità | Ideale per |
|---|---|---|---|---|
Per browser (--proxy-server) | 1 proxy per istanza browser | Sì | Bassa | Scraping semplici e a basso volume |
Gestita dal gateway (proxy-chain + endpoint backconnect) | Policy del provider/sessione | No | Media | Gateway rotanti autenticati |
| Sharding del browser o relay esterno | 1 proxy per shard del browser o regola di relay | Nessuno swap nel singolo processo | Alta | Concorrenza controllata e routing fine-grained |
Prima di scegliere, una nota importante: la documentazione di Puppeteer sull’intercettazione delle richieste è esplicita nel dire che setRequestInterception non è un interruttore pulito per "cambiare proxy per ogni richiesta" — ogni richiesta intercettata rimane in sospeso finché non la continui, la rispondi o la annulli esplicitamente. Il vero routing proxy per richiesta, di solito, richiede un gateway locale programmabile (come proxy-chain) invece di gestire direttamente i proxy dentro l’handler di intercettazione. Tienilo presente prima di impegnarti con il Metodo 3 qui sotto.
Come configurare un proxy rotante in Puppeteer: guida passo passo
Difficoltà: Intermedia
Tempo necessario: circa 30–45 minuti per tutti e tre i metodi
Cosa ti serve: Node.js 18+, npm, una lista di proxy o un account presso un provider (formato: protocollo://utente:pass@host:porta) e i pacchetti puppeteer, proxy-chain e puppeteer-extra
Prerequisiti: cosa ti serve prima di iniziare
Installa i pacchetti principali:
npm install puppeteer proxy-chain puppeteer-extra puppeteer-extra-plugin-stealth
Recupera una lista di proxy da un provider (meglio residential se vai oltre i test casuali) oppure, almeno, un piccolo gruppo di proxy di prova per validare il codice prima di bruciare traffico reale. Conserva le credenziali in variabili d’ambiente: non inserirle mai in chiaro e non metterle in un URL che potrebbe finire in un file di log.
Metodo 1: rotazione proxy per browser con --proxy-server
È la base da cui tutti partono, e per una buona ragione: è prevedibile. La documentazione di LaunchOptions di Puppeteer indica args come il modo supportato per passare i flag della riga di comando a Chrome, e --proxy-server è un flag nativo di Chromium.
import puppeteer from 'puppeteer';
const proxyPool = [
'http://proxy1.example:8080',
'http://proxy2.example:8080',
'http://proxy3.example:8080',
];
let proxyIndex = 0;
async function scrapeWithRotation(url) {
const proxy = proxyPool[proxyIndex % proxyPool.length];
proxyIndex++;
const browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${proxy}`],
});
const page = await browser.newPage();
// Se il proxy richiede autenticazione, questo va eseguito prima di qualsiasi navigazione
await page.authenticate({
username: process.env.PROXY_USER,
password: process.env.PROXY_PASS,
});
await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30_000 });
const content = await page.content();
await browser.close(); // chiudi prima di cambiare proxy
return content;
}
Nota che page.authenticate() abilita silenziosamente l’intercettazione delle richieste dietro le quinte, secondo la documentazione di Puppeteer: un piccolo costo prestazionale utile da conoscere se stai cercando di capire perché tutto sembra più lento del previsto.
Risultato atteso: ogni chiamata avvia un browser nuovo collegato a un proxy diverso. Per ruotare, chiudi e riapri: non c’è modo di evitare il costo di startup. Per uno scraping di 50 pagine, aspettati un’esecuzione visibilmente più lenta rispetto agli altri due metodi, solo per il tempo di avvio del browser.
Quando usarlo: script a bassa concorrenza, scraping una tantum, situazioni in cui la semplicità di debug conta più della velocità.
Metodo 2: gateway rotante autenticato con proxy-chain
Chrome non accetta credenziali user:pass@host incorporate direttamente in un URL proxy. Il pacchetto proxy-chain (mantenuto da Apify) risolve il problema dell’autenticazione creando un proxy locale anonimo che inoltra le richieste al proxy upstream autenticato. Se l’upstream è un gateway rotante o backconnect del provider, sarà il provider a cambiare gli IP di uscita dietro quell’unico endpoint secondo la propria policy di sessione. proxy-chain di per sé non assegna un proxy diverso a ogni pagina Puppeteer già aperta.
import puppeteer from 'puppeteer';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
async function scrapeThroughGateway(upstreamProxyUrl, targetUrl) {
const localProxy = await anonymizeProxy(upstreamProxyUrl);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`],
});
const page = await browser.newPage();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true); // pulizia sempre
}
}
Quel blocco finally non è decorativo: i server proxy locali lasciati in giro occupano porte, e mi è capitato di vedere scraper consumare silenziosamente i file descriptor disponibili durante la notte perché nessuno aveva chiuso il proxy anonimizzato. proxy-chain espone anche codici di errore specifici (593 per problemi DNS, 594 per connessione rifiutata, 597 per errore di autenticazione) che sono davvero utili per classificare i fallimenti — ne parliamo più avanti.
Quando usarlo: gateway residential/datacenter autenticati in cui la rotazione è controllata dall’endpoint del provider o dai parametri di sessione. Se ti servono più identità proxy fisse in parallelo, usa processi browser separati (browser sharding) o un relay esterno progettato ad hoc; Puppeteer nativo non offre un proxy per pagina supportato.
Metodo 3: il routing per richiesta richiede un relay esterno
Questa è l’opzione più granulare: in teoria, ogni immagine, script e chiamata API della pagina potrebbe passare da un exit diverso. In pratica è anche la soluzione più fragile e meno documentata, perché l’intercettazione delle richieste di Puppeteer è pensata per filtrare e modificare le richieste, non per cambiare il trasporto di rete a ogni richiesta.
import puppeteer from 'puppeteer';
async function inspectRequests(url) {
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on('request', async (request) => {
// In pratica, cambiare proxy per ogni richiesta richiede di passare
// da un relay locale (proxy-chain) invece di cambiare il trasporto del browser
// al volo — Chrome non lo supporta.
// Nella maggior parte degli ambienti di produzione questo handler viene usato
// per filtrare o bloccare certi tipi di risorse, insieme a browser sharding o gateway.
if (['image', 'font', 'stylesheet'].includes(request.resourceType())) {
request.abort();
} else {
request.continue();
}
});
await page.goto(url, { waitUntil: 'networkidle2' });
await browser.close();
}
Valutazione sincera: il cambio IP per richiesta dentro Puppeteer non è fornito da setRequestInterception(). Se ti serve davvero quel livello di granularità, fai passare Chrome attraverso un relay esterno programmabile oppure usa un framework di scraping costruito attorno alle sessioni proxy. Per la maggior parte dei progetti, un proxy per shard del browser o un gateway rotante gestito dal provider è più facile da operare e da auditare.
Lo stack completo anti-detection: i proxy rotanti da soli non bastano per evitare i blocchi
Una lamentela molto comune è: "Sto usando i proxy e vengo comunque bloccato". L’IP è solo uno dei segnali che un sistema moderno anti-bot può valutare, e ruotarlo mentre tutto il resto resta incoerente può persino creare un’anomalia più forte. Un browser che dichiara Windows Chrome ma riporta valori diversi in client hints, timezone o locale è un esempio evidente.
Livello 1: proxy residential rotanti
Già visto sopra: gli exit residential sono spesso più credibili dei datacenter, ma non esiste una dimensione minima universale del pool. Dimensiona il pool in base al volume di richieste misurato, alla durata delle sessioni, ai tempi di raffreddamento e al comportamento di riuso del provider, non in base a un numero arbitrario di IP.
Livello 2: plugin stealth per mascherare i segnali di Chrome headless
puppeteer-extra-plugin-stealth corregge una serie di indicatori noti del browser headless: navigator.webdriver, stringhe vendor WebGL, oggetti runtime di Chrome mancanti e alcune altre fughe via CDP. È davvero utile come strato di compatibilità, ma il README del progetto è onestamente chiaro: si tratta di una partita a guardie e ladri, e una prevenzione completa probabilmente non è possibile. Usalo come base, non come garanzia.
Livello 3: profili browser coerenti e ritmo responsabile
Le stringhe user-agent devono essere coerenti con tutto il resto che il browser dichiara. I User-Agent Client Hints di Chrome espongono dati strutturati della piattaforma, quindi una stringa user-agent scritta a mano può contraddire la piattaforma reale. Meglio usare il user agent fornito dalla build di Chrome inclusa, mantenere stabili viewport, locale e timezone all’interno della sessione e rallentare le richieste in modo prudente invece di inventare una nuova fingerprint per ogni pagina.
Ecco tutti e tre i livelli collegati in un’unica configurazione di avvio:
import puppeteer from 'puppeteer-extra';
import StealthPlugin from 'puppeteer-extra-plugin-stealth';
import { anonymizeProxy, closeAnonymizedProxy } from 'proxy-chain';
puppeteer.use(StealthPlugin());
function boundedDelay(minMs = 800, maxMs = 1800) {
return new Promise((r) => setTimeout(r, minMs + Math.random() * (maxMs - minMs)));
}
async function stableProfileScrape(targetUrl, upstreamProxy) {
const localProxy = await anonymizeProxy(upstreamProxy);
let browser;
try {
browser = await puppeteer.launch({
headless: true,
args: [`--proxy-server=${localProxy}`, '--lang=en-US'],
});
const page = await browser.newPage();
await page.setViewport({ width: 1366, height: 768 });
await boundedDelay();
await page.goto(targetUrl, { waitUntil: 'domcontentloaded' });
return await page.content();
} finally {
if (browser) await browser.close();
await closeAnonymizedProxy(localProxy, true);
}
}
Questo è il blocco che molte guide concorrenti non mostrano mai: proxy, stealth e randomizzazione della fingerprint nello stesso posto, pronto da copiare e adattare.
Gestione degli errori e controlli di salute dei proxy pronti per la produzione
La maggior parte dei tutorial si ferma nel momento in cui il percorso felice funziona. Lo scraping reale, invece, fallisce continuamente: i proxy muoiono, le credenziali scadono, i target impongono rate limit a metà run — e nulla di tutto questo si risolve sperando per il meglio.
Retry con exponential backoff e jitter
function backoffMs(attempt, base = 1000, cap = 30_000) {
const exponential = Math.min(cap, base * 2 ** attempt);
return Math.floor(exponential * (0.5 + Math.random() * 0.5)); // il jitter evita il thundering herd
}
async function withRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
if (attempt === maxRetries) throw err;
const delay = backoffMs(attempt);
console.warn(`Tentativo ${attempt + 1} fallito: ${err.message}. Riprovo tra ${delay}ms`);
await new Promise((r) => setTimeout(r, delay));
}
}
}
Blacklist automatica dei proxy che falliscono
const proxyStats = new Map(); // proxyUrl -> { success, failure }
function recordResult(proxyUrl, success) {
const stats = proxyStats.get(proxyUrl) || { success: 0, failure: 0 };
success ? stats.success++ : stats.failure++;
proxyStats.set(proxyUrl, stats);
}
function isHealthy(proxyUrl) {
const stats = proxyStats.get(proxyUrl);
if (!stats) return true;
const total = stats.success + stats.failure;
if (total < 5) return true; // dati ancora insufficienti
return stats.failure / total < 0.5; // blacklist se il tasso di fallimento supera il 50%
}
function getHealthyProxy(pool) {
const healthy = pool.filter(isHealthy);
if (healthy.length === 0) throw new Error('Nessun proxy sano rimasto nel pool');
return healthy[Math.floor(Math.random() * healthy.length)];
}
Traccia il tipo di errore, non solo successo o fallimento: un 407 (credenziali errate) e un 429 (rate limit) richiedono risposte completamente diverse. Continuare a martellare un proxy che fallisce l’autenticazione con retry rapidi significa solo sprecare tempo; la soluzione è verificare le credenziali, non ruotare più velocemente.
Risoluzione dei problemi più comuni con i proxy rotanti in Puppeteer
| Errore | Causa probabile | Soluzione |
|---|---|---|
ERR_PROXY_CONNECTION_FAILED | Proxy offline o irraggiungibile | Rimuovilo dal pool, riprova con il proxy successivo |
407 Proxy Authentication Required | Credenziali errate o autenticazione non supportata | Verifica le credenziali di page.authenticate(); usa proxy-chain per l’autenticazione incorporata nell’URL |
TimeoutError | Proxy lento o blocco da parte del target | Aumenta il timeout; passa a un proxy residential |
403 Forbidden | IP o fingerprint segnalati | Ruota il proxy + abilita lo stealth + randomizza lo user agent |
ERR_TUNNEL_CONNECTION_FAILED | Problema nel tunnel HTTPS | Verifica il supporto al metodo CONNECT; prova il tunneling locale con proxy-chain |
Un paio di cose importanti che non entrano bene in tabella: un codice 200 non significa per forza successo. I soft block spesso restituiscono una pagina HTML completa — un login wall o una schermata di challenge — con status code normale, quindi valida il contenuto reale, non solo lo status della risposta. E quando sei bloccato, la guida al debug di Puppeteer consiglia di avviare con headless: false, aggiungere slowMo e impostare NODE_DEBUG="puppeteer:*" per ottenere log di protocollo dettagliati — ma sappi che quei log possono contenere dati sensibili delle richieste, quindi non lasciarli attivi contro credenziali di produzione.
Rotazione proxy gestita in proprio vs gateway proxy vs API di estrazione AI
| Criterio | Rotazione di una lista gestita internamente | Gateway backconnect (Bright Data, Oxylabs, Decodo) | API di estrazione AI (Thunderbit) |
|---|---|---|---|
| Costo (volumi bassi) | Basso–medio | Medio–alto per GB | Basso (free tier, poi per unità) |
| Affidabilità | Dipende dai tuoi health check | Alta (gestita dal provider) | Alta (infrastruttura gestita) |
| Anti-detection | Fai da te — la costruisci tu | Parziale (solo rotazione IP) | Integrata |
| Output strutturato | No (HTML grezzo) | No (HTML grezzo) | Sì (JSON via schema) |
| Tempo di setup | Ore | Minuti | Minuti |
| Controllo | Totale | Limitato all'API del provider | Limitato al modello dello schema |
I prezzi attuali dei fornitori (controllati il 2026-08-07) danno un’idea della curva di costo dell’opzione gateway: il pricing residential di Bright Data offre piani pay-as-you-go e a volume le cui promozioni possono cambiare; Oxylabs mostra 6 $/GB a 5 GB e 2,50 $/GB a 1 TB; Decodo (ex Smartproxy) mostra 3,75 $/GB a 3 GB, 2,75 $/GB a 100 GB e un’offerta pay-as-you-go da 4 $/GB. Decodo pubblicizza anche un pool di oltre 115 milioni di IP e un tasso di successo del 99,92% — dichiarazioni del vendor, non benchmark verificati in modo indipendente.
Il criterio che uso davvero è questo: devi interagire con la pagina — cliccare, scorrere, compilare form, mantenere una sessione di login? Allora Puppeteer con i proxy ha senso. Ti serve solo il dato già presente nella pagina? Valuta prima un’API di estrazione, invece di costruire un’infrastruttura proxy che dovrai mantenere per sempre.
Quando Puppeteer + proxy è eccessivo: estrai dati strutturati con un'API
Arriva un momento, di solito verso la terza volta che ricostruisci un sistema di health check dei proxy per un progetto che in realtà aveva solo bisogno dei prezzi dei prodotti in un foglio di calcolo, in cui tutto diventa chiaro: gran parte di questa infrastruttura esiste per risolvere un problema — estrarre HTML grezzo da una pagina — che in realtà non è il vero obiettivo dello sviluppatore. L’obiettivo è il dato strutturato. L’HTML è solo il formato intermedio scomodo.
L'Open API di Thunderbit tratta l’estrazione come operazione principale, non come effetto collaterale dell’automazione browser. POST /extract accetta un URL e uno JSON Schema e restituisce dati strutturati corrispondenti — gestendo rendering JavaScript, anti-bot e CAPTCHA lato backend, invece di lasciarti montare da solo plugin stealth e pool di proxy:
curl -X POST https://openapi.thunderbit.com/openapi/v1/extract \
-H "Authorization: Bearer $THUNDERBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product",
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"price": {"type": "number"}
},
"required": ["name", "price"]
}
}'
Esiste anche un endpoint POST /distill per i casi in cui vuoi solo Markdown pulito invece di uno schema rigido, oltre al supporto per l’estrazione batch, così puoi applicare lo stesso schema a più URL con una sola chiamata. Secondo i prezzi API attuali di Thunderbit, Distill costa 1 unità per pagina ed Extract 20 unità per pagina — il piano gratuito include 600 unità una tantum, sufficienti per testare il flusso prima di impegnarti.
Per gli sviluppatori che lavorano dentro Claude, Cursor o un altro client compatibile MCP, Thunderbit espone anche thunderbit_extract e thunderbit_distill come tool MCP, permettendo a un agente di decidere durante il task quando ha bisogno di leggere dati da una pagina invece di richiedere un passaggio separato di scraping. Prima di configurare MCP, controllerei la documentazione API live, perché i nomi dei tool e i parametri possono cambiare tra una versione e l’altra.
| Dimensione | Puppeteer + proxy rotanti | Thunderbit API |
|---|---|---|
| Complessità di setup | Alta — pool proxy, logica di rotazione, stealth, retry | Bassa — una chiamata API con JSON Schema |
| Gestione anti-bot | Manuale | Integrata |
| Output | HTML grezzo (serve parsing) | JSON strutturato conforme allo schema |
| Manutenzione | Alta — i selettori si rompono, i proxy si degradano | Bassa |
| Ideale per | Automazione personalizzata, login flow, interazioni specifiche | Estrazione dati su scala |
Per correttezza verso la strada fai-da-te: se il tuo caso d’uso prevede login in un account, un flusso multi-step o qualcosa che richiede mantenere stato durante la sessione, in genere un’API di estrazione non può sostituirlo — la FAQ di Thunderbit è chiara nel dire che i flussi di login interattivi non sono al momento supportati via API. In quel caso Puppeteer più proxy resta la scelta migliore. Ma se il lavoro è "prendere dati da tante pagine pubbliche e portarli in uno schema che definisco io", costruire il tuo stack di rotazione proxy sta risolvendo un problema più difficile di quello che hai davvero. Per i team che preferiscono saltare del tutto il codice, la Thunderbit Chrome Extension offre la stessa estrazione guidata dall’AI con un’interfaccia point-and-click — vale la pena valutarla se stai confrontando il web scraping no-code con una configurazione completa da sviluppatore.
Conclusione e punti chiave
I proxy rotanti in Puppeteer non sono una sola tecnica. La rotazione per browser è semplice e isolata. Un gateway backconnect autenticato può cambiare gli exit dietro un singolo endpoint a livello di browser. Le identità a granularità fine per richiesta o in parallelo richiedono sharding del browser o un relay esterno; l’intercettazione delle richieste da sola non modifica il percorso di rete di Chrome.
Tutto questo, però, conta poco senza il resto dello stack. I proxy risolvono il problema della reputazione IP; i plugin stealth e la coerenza della fingerprint risolvono il problema dei segnali del browser; jitter e pacing risolvono il problema comportamentale. Salta uno di questi livelli e puoi comunque essere bloccato, solo per un motivo diverso.
Se vuoi costruirlo da solo, parti dal repository proxy-chain e dai blocchi di codice sopra: ti porteranno molto più lontano di molti corsi a pagamento. Se invece preferisci evitare del tutto la gestione dei proxy e ricevere direttamente dati strutturati, la documentazione API di Thunderbit merita dieci minuti del tuo tempo prima di buttare un intero weekend su un’infrastruttura di health check che poi dovrai mantenere per sempre. Entrambe le strade sono legittime: l’importante è risolvere il problema reale che hai, non quello che ogni tutorial presume tu abbia. Per una visione più ampia di come l’AI sta cambiando questo settore, dai un’occhiata al nostro approfondimento su AI web scraping e su come si confronta con gli approcci tradizionali.
FAQ
Ogni quanto dovrei ruotare i proxy in Puppeteer?
Dipende da quanto è aggressivo il rate limiting del target. Per siti con rilevamento bot rigido, ruota a ogni pagina o a ogni sessione. Per siti più permissivi, può bastare una rotazione per sessione o persino un singolo IP sticky per l’intera esecuzione. Non esiste un numero universale: considera 403, 429 e timeout come il segnale che devi ruotare in modo più aggressivo, non come un conteggio fisso di richieste.
Posso usare proxy gratuiti per lo scraping con Puppeteer?
Tecnicamente sì, ma non lo consiglierei per nulla oltre a test rapidi. Le liste di proxy gratuiti sono in genere lente, poco affidabili e spesso già blacklistate dai siti che vuoi estrarre. Per qualunque uso in produzione, i proxy residential di un provider a pagamento o un gateway gestito valgono il costo.
puppeteer-extra-plugin-stealth funziona contro tutti i sistemi anti-bot?
No, e la documentazione del plugin lo dice chiaramente. Riduce alcuni segnali comuni di Chrome headless, ma il target può comunque valutare reputazione di rete, caratteristiche TLS, cookie, client hints e comportamento. Consideralo uno strato di compatibilità, non una garanzia.
Qual è la differenza tra proxy-chain e --proxy-server in Puppeteer?
--proxy-server è un flag nativo di Chromium che assegna un endpoint proxy all’intera istanza browser, e Chrome non accetta lì credenziali proxy incorporate. proxy-chain crea un tunnel locale anonimo verso un upstream autenticato. La rotazione poi arriva rilanciando con un upstream diverso, usando un gateway backconnect gestito dal provider o un relay costruito separatamente — non dal fatto che proxy-chain assegni proxy alle singole pagine Puppeteer.
Ruotare i proxy basta per evitare del tutto i blocchi?
No — ed è l’equivoco più comune. I moderni sistemi anti-bot come la bot management di Cloudflare correlano la reputazione IP con fingerprint del browser, pattern comportamentali e cronologia della sessione. I proxy risolvono la parte della reputazione IP; ti servono comunque configurazione stealth, fingerprint coerente e timing realistico per non essere segnalato sugli altri segnali.
Scopri di più
