Proxies pour Firecrawl, Crawl4AI et Crawlee : constituez un corpus RAG sans blocages

Facture numéro un : 403 au lieu de contenu

L'erreur clé lors de la collecte du corpus est de penser que le crawler a fonctionné avec succès s'il ne s'est pas écrasé. Firecrawl et Crawl4AI renvoient non pas une exception sur une page bloquée, mais un résultat : une page de substitution d'anti-bot, une page de vérification du navigateur ou un court texte de refus d'accès. Formelement, c'est un markdown valide, il se glisse tranquillement dans la base vectorielle et y reste jusqu'à la première requête utilisateur.

Par conséquent, la première chose à faire avant toute configuration de proxy est d'ajouter un contrôle de qualité des résultats. La version minimale : rejeter les documents plus courts qu'un certain seuil (pour une page de contenu typique, il est raisonnable de considérer 500–800 caractères de texte) et capturer séparément les marqueurs caractéristiques dans le texte — mentions de vérification de connexion, JavaScript activé, « Accès refusé ». Ces documents ne sont pas envoyés dans la base, mais dans une file d'attente pour un nouveau passage — déjà via le proxy.

Facture numéro deux : des gigaoctets que vous jetez

Ici, l'arithmétique aide. Selon les données de Web Almanac de HTTP Archive pour 2025, la page d'accueil médiane pèse environ 2,86 Mo sur desktop et 2,56 Mo sur mobile. Parmi ceux-ci, environ 1 059 Ko sont consacrés aux images sur les pages d'accueil et 911 Ko sur les pages internes, et 697 Ko et 632 Ko respectivement pour le JavaScript. Donc, les images sont la catégorie la plus lourde, représentant environ un tiers du poids de la page.

Et maintenant, rappelez-vous ce que vous faites avec le résultat. Vous convertissez la page en markdown et la découpez en morceaux pour les embeddings. Les images ne font pas du tout partie de ce pipeline — au mieux, il ne reste qu'une ligne avec le texte alt. Vidéos, polices, scripts analytiques, pixels publicitaires — également à l'écart.

Si vous faites passer le crawl via un proxy résidentiel avec paiement par gigaoctet, vous payez littéralement pour la livraison de données que vous jetez à l'étape suivante du pipeline. Sur un corpus de 100 000 pages, la différence entre « tout tirer » et « tirer uniquement HTML et texte » se mesure non pas en pourcentages, mais en fois. L'économie exacte dépend du thème des sites : les médias et le e-commerce sont plus lourds que la documentation et les blogs.

Étape 1. Escalade au lieu de « proxy pour tout »

Le principal principe architectural qui économise le plus : ne pas faire passer tout le trafic par le proxy. La plupart des domaines lors de la collecte de la base de connaissances — documentation, blogs, sites d'aide, portails gouvernementaux — fournissent du contenu directement et ne bloquent personne. Le proxy est nécessaire pour une minorité.

Le schéma correct est une escalade à plusieurs niveaux : d'abord une requête directe, en cas de signes de blocage — passage au niveau suivant. Et ce n'est pas une rustine maison, les deux grands frameworks savent le faire nativement.

Dans Crawlee, cela se fait avec tieredProxyUrls. Les niveaux sont énumérés du moins cher au plus cher, et le crawler monte lui-même en cas de blocages, puis essaie périodiquement de revenir au niveau inférieur :

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

Un point important de la documentation : tieredProxyUrls fonctionne uniquement lorsqu'il est utilisé via une instance de crawler. Les appels directs à newUrl() donneront un résultat inattendu.

Dans Crawl4AI, un mécanisme similaire est apparu dans la version 0.8.5 et vit dans la branche actuelle (dernier release au moment de la publication — v0.9.2 du 15 juillet 2026). Il s'appelle escalade de proxy et se configure directement dans CrawlerRunConfig : détection de blocage à trois niveaux — fournisseurs anti-bots connus, indicateurs de blocage généraux et vérification de l'intégrité structurelle de la page — plus un retry automatique à travers la chaîne de proxies.

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,
)

Notez que ProxyConfig.DIRECT est le premier élément — c'est « d'abord essayez sans proxy ».

Étape 2. Connexion du proxy dans chaque outil

Ensuite, des détails sur la configuration. L'ordre des actions est le même : d'abord le proxy, puis le filtrage du trafic superflu, puis la vérification.

1. Firecrawl (auto-hébergé). Le proxy est défini par trois variables d'environnement, qui sont passées à Playwright : PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Elles sont écrites dans .env pour apps/api ; dans le commentaire à leur sujet, les développeurs précisent que vous pouvez indiquer un service proxy qui fait tourner les IP à chaque requête au lieu d'une adresse statique.
2. Crawl4AI. Le proxy vit dans BrowserConfig, dans le champ proxy_config — c'est un objet ProxyConfig ou un dictionnaire avec les champs server, username, password. Une configuration de navigateur pour toute la session de crawling ; un CrawlerRunConfig séparé est passé à chaque appel de arun().
3. Crawlee. La classe ProxyConfiguration avec l'option proxyUrls — une liste d'adresses, par laquelle la bibliothèque tourne en rond (round-robin). La valeur null dans la liste signifie « sans proxy ». L'intégration est complète : HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
4. Règles ponctuelles. Si vous savez quels domaines bloquent et lesquels ne bloquent pas, dans Crawlee, il y a newUrlFunction — votre propre logique de sélection de proxy basée sur l'URL de la requête. Pour les domaines blancs, vous renvoyez null, pour les autres — l'adresse du proxy. C'est l'option la moins chère lorsque la liste des cibles est stable.
5. Vérification. Avant de faire un passage en production, passez la page qui renvoie votre IP externe à travers le crawler configuré, et assurez-vous que vous voyez l'adresse du proxy, et non celle du serveur. Trois lignes qui économisent une journée de clarifications.

Étape 3. Couper tout ce qui ne deviendra pas texte

Lorsque le proxy est connecté, activez l'économie de trafic — sinon, la facture pour les gigaoctets arrivera plus vite que le corpus ne sera assemblé.

Dans Firecrawl, cela est géré par la variable BLOCK_MEDIA. Dans l'exemple de configuration officiel, il y a un commentaire littéral : définissez-le si vous souhaitez bloquer les requêtes médias pour économiser la bande passante du proxy. C'est le moyen le plus rapide de réduire la principale dépense.

Dans Crawl4AI, des leviers similaires se trouvent dans BrowserConfig : text_mode désactive les images et accélère le crawl textuel, light_mode désactive certaines fonctions de fond du navigateur, avoid_css bloque le chargement de CSS. Ils peuvent être combinés. Pour la collecte de corpus pour RAG, c'est presque toujours le bon ensemble — vous n'avez pas besoin de mise en page, vous avez besoin de texte.

Dans Crawlee, la logique est différente : si le contenu est renvoyé en HTML, utilisez CheerioCrawler ou HttpCrawler au lieu des crawlers basés sur le navigateur. Une requête HTTP normale au lieu d'un rendu complet — ce n'est pas seulement une économie de trafic, c'est un autre ordre de dépenses. Réservez les crawlers basés sur le navigateur (PlaywrightCrawler, PuppeteerCrawler) uniquement pour les pages qui ne peuvent pas être collectées sans JavaScript.

Pièges

Sessions contre rotation. Changer d'IP à chaque requête semble suspect et casse les scénarios à plusieurs étapes — pagination, transitions à l'intérieur d'un même domaine. Dans Crawlee, chaque appel à newUrl() associe le proxy à un objet Session, et ils tournent ensemble avec les empreintes du navigateur et les en-têtes. Ne rompez pas ce lien manuellement.

Média désactivés, mais le contenu a disparu. Certaines sites chargent paresseusement non seulement des images, mais aussi du texte. Après avoir activé text_mode ou BLOCK_MEDIA, passez impérativement un échantillon de contrôle de 20 à 30 pages et comparez le volume de texte avec la référence.

Retries sans plafond. L'escalade par niveaux de proxy signifie qu'une page obstinée peut être téléchargée trois fois — et les trois fois payées. Limitez max_retries et établissez une liste de domaines qui, après N échecs, sont complètement exclus du crawl.

Robots.txt et cadre légal. La collecte de données pour l'apprentissage et RAG en 2026 est régulée plus strictement qu'il y a quelques années — des exigences de divulgation des sources aux mécanismes de refus de text and data mining. Assurez-vous que votre pipeline respecte ces signaux avant qu'il ne fonctionne sur des centaines de milliers de pages.

Quel type de proxy choisir pour le pipeline RAG

La réponse dépend du niveau d'escalade où vous vous trouvez.

• Niveau zéro — sans proxy. Documentation, projets open source, sites gouvernementaux, la plupart des blogs d'entreprise. Ici, l'IP du serveur fonctionne normalement, et il n'y a rien à payer.
• Niveau moyen — proxy de datacenter. Rapides et peu coûteux, adaptés contre le simple rate limiting et les restrictions régionales. Lors de la collecte de grands corpus, c'est un cheval de bataille : lorsque le volume est mesuré en centaines de gigaoctets, la différence de prix par gigaoctet devient le facteur principal.
• Niveau supérieur — proxies résidentiels. Pour les domaines avec une protection anti-bot sérieuse, où les sous-réseaux de datacenter sont filtrés à l'entrée. C'est pourquoi ils ne peuvent pas être définis par défaut — le paiement par gigaoctet transforme chaque image superflue en ligne de dépenses.

Avant de construire le pipeline, il vaut la peine de calculer honnêtement l'économie : nous avons examiné le coût total du parsing d'un million de pages en tenant compte du poids des pages, des retries et des coûts cachés. Et une question distincte, qu'il est utile de poser avant d'écrire la première ligne de code : le crawl est-il vraiment nécessaire — dans l'analyse de l'API officielle contre les ensembles de données prêts à l'emploi et le parsing, il est évident que pour certaines sources, les données prêtes à l'emploi sont moins chères qu'un crawler maison.

Conclusion

Le proxy dans un crawler LLM n'est pas un interrupteur « on/off », mais un schéma à trois niveaux. Requête directe comme niveau par défaut, proxy de datacenter au niveau moyen, résidentiels — uniquement pour les domaines qui ne peuvent pas être collectés autrement. De plus, un filtrage strict des médias, car vous collectez du texte et payez pour des octets.

L'ordre des opérations est simple : d'abord le contrôle de qualité des résultats (sinon, vous ne saurez pas que la moitié du corpus est constituée de pages de substitution), puis l'escalade du proxy via les moyens du framework lui-même, puis l'économie de trafic. Dans cet ordre — le corpus sera complet et la facture prévisible.