Configuration de proxy pour Crawl4AI et Firecrawl : ingestion RAG sans blocages (2026)

Crawl4AI et Firecrawl sont devenus la manière par défaut d'alimenter les pipelines de LLM en données web — ils crawlent, rendent et restituent du Markdown propre que votre modèle peut réellement utiliser. Puis vous les pointez vers une cible réelle et vous découvrez ce que tout scraper finit par apprendre : la couche d'extraction n'a jamais été la partie difficile. La partie difficile, c'est que votre crawler s'exécute depuis une seule IP de centre de données, et le web peut le voir.

Ce guide montre la configuration de proxy fonctionnelle pour les deux outils — Crawl4AI auto-hébergé et les deux modes de Firecrawl — ainsi que la stratégie de session qui empêche les jobs d'ingestion pour RAG de mourir à la page 50. Il prolonge notre guide des proxies pour agents IA et notre guide browser-use aux frameworks de crawling.

Pourquoi les crawlers de LLM se font bloquer plus vite que les scrapers

• Ils collectent largement, pas chirurgicalement. Un job d'ingestion pour RAG extrait des centaines de pages sur tout un domaine en quelques minutes — exactement le motif de vélocité que les systèmes de réputation d'IP notent le plus durement (voir la détection d'ASN expliquée).
• Ils exécutent Chromium headless par défaut. Crawl4AI utilise Playwright en interne ; sans flags, il expose les artefacts headless standards.
• Ils réessaient bêtement. Le retry-on-failure par défaut contre un mur anti-bot ne fait qu'enfoncer davantage la réputation de l'IP.

Crawl4AI : configuration du proxy

Crawl4AI (open-source, auto-hébergé) accepte les proxies au niveau de BrowserConfig — un proxy par instance de crawler :

from crawl4ai import AsyncWebCrawler, BrowserConfig, CrawlerRunConfig

browser_cfg = BrowserConfig(
    headless=True,
    proxy_config={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME",
        "password": "PASSWORD",
    },
)

async with AsyncWebCrawler(config=browser_cfg) as crawler:
    result = await crawler.arun(
        url="https://example.com/docs",
        config=CrawlerRunConfig(),
    )
    print(result.markdown[:500])

Pour les crawls profonds, faites tourner l'identité par instance de crawler, pas par page — les pages d'une même visite de site devraient partager une seule IP de sortie (un humain ne change pas de ville entre la page 3 et la page 4) :

def crawler_for(site_id: str) -> BrowserConfig:
    # Sticky session per site: cookies + IP move together
    return BrowserConfig(
        headless=True,
        proxy_config={
            "server": "us.jibaoproxy.com:913",
            "username": f"USERNAME-session-{site_id}",
            "password": "PASSWORD",
        },
    )

# site A crawled through exit A, site B through exit B, in parallel

Firecrawl : deux modes, deux réponses

API cloud : le proxy est un paramètre de la requête — Firecrawl route à travers ses propres pools. Vous contrôlez le niveau de qualité, pas les IP :

from firecrawl import FirecrawlApp

app = FirecrawlApp(api_key="fc-YOUR-KEY")
result = app.scrape_url(
    "https://example.com/pricing",
    params={"proxy": "stealth"},   # basic | stealth | auto
)

Le hic : les requêtes de niveau stealth sont facturées à un multiple des crédits basic, et vous ne pouvez ni épingler précisément les pays ni maintenir des sessions sticky entre les appels. Parfait pour des pages occasionnelles ; cher et imprécis à un volume d'ingestion élevé.

Firecrawl auto-hébergé : vous fournissez votre propre proxy via des variables d'environnement, avec un contrôle total :

# .env for self-hosted Firecrawl
PROXY_SERVER=http://us.jibaoproxy.com:1000
PROXY_USERNAME=USERNAME
PROXY_PASSWORD=PASSWORD

Auto-hébergé + votre propre passerelle résidentielle est la configuration rationnelle en coût une fois que vous ingérez à grande échelle : vous payez au GB de bande passante au lieu de crédits par page avec un multiplicateur stealth.

Stratégie de session pour les jobs d'ingestion RAG

• Un site = une identité sticky. Cookies, cache et IP de sortie restent cohérents pendant tout le crawl du site ; faites tourner entre les sites. (Contexte : sticky vs rotatif.)
• Respectez le rythme par site. Les options semaphore_count / delay de Crawl4AI existent pour ça — 2–4 pages concurrentes par site suffisent largement ; répartissez le parallélisme entre les sites.
• Faites échouer la page, pas le job. Sur un 403/challenge, marquez l'URL, faites tourner l'identité et continuez — les retries aveugles à travers la même sortie empoisonnent son score.
• Validez le Markdown. Un interstitiel anti-bot se convertit en Markdown sans problème — un « Verifying you are human » incrusté dans votre base de données vectorielle est un mode d'échec bien réel. Faites un grep de la sortie d'ingestion à la recherche de marqueurs de pages de challenge avant d'indexer.
• Mettez en cache agressivement. Re-crawler des pages inchangées brûle de la bande passante et de la réputation pour rien — respectez ETag/Last-Modified là où le framework le permet.

Mise au point sur les coûts

Configuration	Vous payez pour	Idéal quand
Firecrawl cloud, proxy stealth	Crédits par page × multiplicateur stealth	Faible volume, zéro ops
Firecrawl auto-hébergé + GB résidentiels	Bande passante seule (~$10/GB)	Volume d'ingestion régulier
Crawl4AI + GB résidentiels	Bande passante seule, contrôle total	Pipelines sur mesure, crawls profonds

Une page typique riche en texte coûte 100–300 KB à travers un proxy — soit environ 3 000–10 000 pages par GB. Les boucles de blocage-et-retry sont ce qui fait exploser le budget, ce qui est une raison de plus pour corriger la détection avant de monter en volume.

Résumé

• Crawlers de LLM bloqués = détection d'IP + headless, pas le framework ; corrigez d'abord la couche réseau.
• Crawl4AI : proxy_config dans BrowserConfig ; identité sticky par site, rotation entre les sites.
• Firecrawl cloud : paramètre proxy: "stealth", coûteux à grand volume ; auto-hébergé : votre propre passerelle via variables d'environnement.
• Validez la sortie Markdown en cherchant du texte de pages de challenge avant qu'il n'atteigne votre base de données vectorielle.
• Le résidentiel au GB l'emporte sur les crédits stealth par page une fois l'ingestion régulière.