Proxy per Firecrawl, Crawl4AI e Crawlee: guida 2026

Lo schema "ho avviato Firecrawl in Docker, l'ho indirizzato su un elenco di domini, ho ottenuto markdown per RAG" funziona fino alla prima mille pagine. Dopo arrivano due fatture. La prima — dagli anti-bot: alcuni domini iniziano a restituire 403 invece di contenuti, e nel database delle conoscenze si formano buchi di cui si viene a conoscenza quando l'assistente risponde "non ci sono informazioni nei materiali forniti". La seconda fattura — per il traffico: il crawler scarica onestamente ogni immagine e ogni font, che comunque non finiranno nel markdown finale.

Analizziamo come collegare un proxy ai tre crawler LLM più utilizzati del 2026 — Firecrawl, Crawl4AI e Crawlee — e come configurarli in modo che il proxy funzioni solo dove necessario, senza consumare gigabyte su ogni pagina.

Per chi è questa guida

Se stai raccogliendo un corpus di documenti per RAG, riempiendo un database interno, costruendo un data pipeline per il riaddestramento o semplicemente scaricando regolarmente centinaia di domini — questo è il tuo caso. Tutti e tre gli strumenti qui sotto, nella configurazione predefinita, operano con l'IP del tuo server e caricano la pagina interamente. Entrambi questi valori predefiniti devono essere modificati.

La scala del problema è evidente dai numeri di popolarità: Firecrawl ha circa 170.000 stelle su GitHub al momento della pubblicazione (licenza AGPL-3.0), Crawl4AI circa 79.000, Crawlee di Apify circa 25.000. Questi non sono più esperimenti di nicchia, ma strumenti standard, e i sistemi anti-bot conoscono il loro comportamento non meno di te.

Prima fattura: 403 invece di contenuti

L'errore chiave nella raccolta del corpus è pensare che il crawler abbia funzionato correttamente se non è andato in crash. Firecrawl e Crawl4AI su una pagina bloccata restituiscono non un'eccezione, ma un risultato: una pagina di sostituzione dell'anti-bot, una pagina di verifica del browser o un breve testo di rifiuto di accesso. Formalmente è un markdown valido, si inserisce tranquillamente nel database vettoriale e rimane lì fino alla prima richiesta dell'utente.

Quindi la prima cosa da fare prima di qualsiasi configurazione del proxy è aggiungere un controllo della qualità del risultato. La versione minima: scartare documenti più corti di una certa soglia (per una tipica pagina di contenuti è ragionevole 500–800 caratteri di testo) e catturare separatamente i marcatori caratteristici nel testo — menzioni di verifica della connessione, JavaScript attivato, "Accesso negato". Tali documenti non vengono inviati al database, ma messi in coda per una nuova scansione — già tramite proxy.

Seconda fattura: gigabyte che stai sprecando

Qui aiuta l'aritmetica. Secondo i dati di Web Almanac di HTTP Archive per il 2025, la pagina principale mediana pesa circa 2,86 MB su desktop e 2,56 MB su mobile. Di questi, le immagini rappresentano circa 1.059 KB sulle pagine principali e 911 KB su quelle interne, mentre JavaScript pesa 697 KB e 632 KB rispettivamente. Quindi le immagini sono la categoria più pesante, circa un terzo del peso della pagina.

E ora ricorda cosa fai con il risultato. Converti la pagina in markdown e la dividi in chunk per gli embedding. Le immagini non entrano affatto in questo pipeline — nel migliore dei casi rimane solo una riga con il testo alt. Video, font, script analitici, pixel pubblicitari — anche questi vengono ignorati.

Se esegui la scansione tramite un proxy residenziale con pagamento per gigabyte, stai letteralmente pagando per la consegna di dati che scarti nel passaggio successivo del pipeline. Su un corpus di 100.000 pagine, la differenza tra "scaricare tutto" e "scaricare solo HTML e testo" si misura non in percentuali, ma in volte. Il risparmio esatto dipende dal tema dei siti: media ed e-commerce sono più pesanti della documentazione e dei blog.

Passo 1. Escalation invece di "proxy per tutto"

Il principale approccio architettonico che fa risparmiare di più: non far passare tutto il traffico attraverso il proxy. La maggior parte dei domini nella raccolta del database delle conoscenze — documentazione, blog, siti di riferimento, portali governativi — fornisce contenuti direttamente e non blocca nessuno. Il proxy è necessario per una minoranza.

Lo schema corretto è un'escalation multilivello: prima una richiesta diretta, in caso di segni di blocco — passare al livello successivo. E non si tratta di un rimedio fatto in casa, entrambi i framework principali lo sanno fare così out-of-the-box.

In Crawlee c'è tieredProxyUrls per questo. I livelli sono elencati dal più economico al più costoso, e il crawler sale autonomamente in caso di blocchi, per poi provare periodicamente a tornare al livello inferiore:

const proxyConfiguration = new ProxyConfiguration({
    tieredProxyUrls: [
        [null],
        ['http://user:pass@datacenter-proxy:8080'],
        ['http://user:pass@residential-proxy:8000'],
    ]
});

Un'importante nota dalla documentazione: tieredProxyUrls funziona solo se utilizzato tramite un'istanza del crawler. Le chiamate dirette a newUrl() daranno risultati inaspettati.

In Crawl4AI un meccanismo simile è apparso nella versione 0.8.5 ed è presente nel ramo attuale (l'ultima versione al momento della pubblicazione è v0.9.2 del 15 luglio 2026). Si chiama escalation del proxy e si configura direttamente in CrawlerRunConfig: rilevamento del blocco a tre livelli — noti fornitori di anti-bot, indicatori generali di blocco e verifica dell'integrità strutturale della pagina — più retry automatico tramite la catena di proxy.

from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig

config = CrawlerRunConfig(
    proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
    max_retries=2,
)

Nota ProxyConfig.DIRECT come primo elemento — questo è "prova prima senza proxy".

Passo 2. Collegamento del proxy in ogni strumento

Successivamente, dettagli sulla configurazione. L'ordine delle azioni è lo stesso: prima il proxy, poi il taglio del traffico superfluo, poi il controllo.

Firecrawl (self-hosted). Il proxy è impostato tramite tre variabili d'ambiente, che vengono passate a Playwright: PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Vengono scritte in .env per apps/api; nei commenti a esse, gli sviluppatori scrivono chiaramente che invece di un indirizzo statico si può indicare un servizio proxy che ruota gli IP ad ogni richiesta.
Crawl4AI. Il proxy vive in BrowserConfig, nel campo proxy_config — è un oggetto ProxyConfig o un dizionario con i campi server, username, password. Una configurazione del browser per l'intera sessione di crawling; un separato CrawlerRunConfig viene passato ad ogni chiamata di arun().
Crawlee. La classe ProxyConfiguration con l'opzione proxyUrls — un elenco di indirizzi, attraverso il quale la libreria gira in tondo (round-robin). Il valore null nella lista significa "senza proxy". L'integrazione è totale: HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
Regole specifiche. Se si sa quali domini bloccano e quali no, in Crawlee c'è newUrlFunction — la propria logica di selezione del proxy basata sull'URL della richiesta. Per i domini bianchi restituisci null, per gli altri — l'indirizzo del proxy. Questa è l'opzione più economica quando l'elenco degli obiettivi è stabile.
Controllo. Prima di un test operativo, fai passare attraverso il crawler configurato una pagina che restituisce il tuo IP esterno e assicurati di vedere l'indirizzo del proxy, non quello del server. Tre righe che risparmiano un giorno di indagini.

Passo 3. Tagliare tutto ciò che non diventa testo

Quando il proxy è collegato, attiva il risparmio di traffico — altrimenti la fattura per i gigabyte arriverà più velocemente di quanto si raccolga il corpus.

In Firecrawl questo è gestito dalla variabile BLOCK_MEDIA. Nell'esempio ufficiale di configurazione, c'è un commento letterale: impostala se vuoi bloccare le richieste multimediali per risparmiare banda del proxy. Questo è il modo più veloce per eliminare la principale voce di spesa.

In Crawl4AI leve simili si trovano in BrowserConfig: text_mode disabilita le immagini e accelera la scansione testuale, light_mode disattiva alcune funzioni di background del browser, avoid_css blocca il caricamento del CSS. Possono essere combinati. Per la raccolta del corpus per RAG, questo è quasi sempre il set corretto — non hai bisogno di layout, hai bisogno di testo.

In Crawlee la logica è diversa: se il contenuto viene restituito in HTML, usa CheerioCrawler o HttpCrawler invece di quelli browser. Una normale richiesta HTTP invece di un rendering completo — non è solo risparmio di traffico, è un diverso ordine di spese. I crawler basati su browser (PlaywrightCrawler, PuppeteerCrawler) devono essere lasciati solo per le pagine che non possono essere raccolte senza JavaScript.

Insidie

Sessioni contro rotazione. Cambiare IP ad ogni richiesta di per sé appare sospetto e rompe scenari a più passaggi — paginazione, transizioni all'interno di un dominio. In Crawlee ogni chiamata a newUrl() collega il proxy all'oggetto Session, e vengono ruotati insieme alle impronte del browser e agli header. Non rompere manualmente questo legame.

Media disabilitati, ma il contenuto è scomparso. Alcuni siti con caricamento pigro tirano su non solo immagini, ma anche testo. Dopo aver attivato text_mode o BLOCK_MEDIA, assicurati di eseguire un campione di controllo di 20-30 pagine e confronta il volume di testo con quello di riferimento.

Retry senza tetto. L'escalation ai livelli di proxy significa che una pagina ostinata può essere scaricata tre volte — e tutte e tre le volte pagata. Limita max_retries e crea un elenco di domini che dopo N tentativi falliti vengono esclusi completamente dalla scansione.

Robots.txt e quadro legale. La raccolta di dati per l'addestramento e RAG nel 2026 è regolata più rigidamente rispetto a qualche anno fa, dai requisiti di divulgazione delle fonti ai meccanismi di rifiuto del text and data mining. Assicurati che il tuo pipeline rispetti questi segnali, prima che funzioni su centinaia di migliaia di pagine.

Che tipo di proxy utilizzare per il pipeline RAG

La risposta dipende dal livello di escalation in cui ti trovi.

Livello zero — senza proxy. Documentazione, progetti open source, siti governativi, la maggior parte dei blog aziendali. Qui l'IP del server funziona normalmente e non c'è nulla da pagare.
Livello medio — proxy di data center. Veloci ed economici, adatti contro il semplice rate limiting e le restrizioni regionali. Nella raccolta di grandi corpus, sono un cavallo di battaglia: quando il volume è misurato in centinaia di gigabyte, la differenza di prezzo per gigabyte diventa il fattore principale.
Livello alto — proxy residenziali. Per domini con una seria protezione anti-bot, dove le sottoreti dei data center vengono filtrate all'ingresso. Ecco perché non possono essere impostati come livello predefinito — il pagamento per gigabyte trasforma ogni immagine superflua in una voce di spesa.

Prima di costruire il pipeline, vale la pena calcolare onestamente l'economia: abbiamo analizzato il costo totale di parsing di un milione di pagine tenendo conto del peso delle pagine, dei retry e delle spese nascoste. E una domanda separata, che è utile porsi prima di scrivere la prima riga di codice: è davvero necessario il crawling — nell'analisi di API ufficiale contro dataset pronti e parsing si vede che per alcune fonti i dati pronti risultano più economici del proprio crawler.

Conclusione

Il proxy in un crawler LLM non è un interruttore "on/off", ma uno schema a tre livelli. Richiesta diretta come livello predefinito, proxy di data center a livello medio, residenziali — solo per domini che altrimenti non possono essere acquisiti. Inoltre, un severo taglio dei media, perché stai raccogliendo testo e pagando per byte.

L'ordine delle operazioni è semplice: prima il controllo della qualità del risultato (altrimenti non saprai che metà del corpus sono pagine di sostituzione), poi l'escalation del proxy tramite gli strumenti stessi del framework, poi il risparmio di traffico. In questo ordine — e il corpus sarà completo, e la fattura prevedibile.