Configuração de proxy para Crawl4AI e Firecrawl: ingestão para RAG sem bloqueios (2026)

Crawl4AI e Firecrawl se tornaram a forma padrão de alimentar dados da web em pipelines de LLM — eles rastreiam, renderizam e devolvem Markdown limpo que seu modelo realmente consegue usar. Aí você os aponta para um alvo real e descobre o que todo scraper acaba aprendendo: a camada de extração nunca foi a parte difícil. A parte difícil é que seu crawler roda a partir de um único IP de datacenter, e a web consegue vê-lo.

Este guia mostra a configuração de proxy funcional para as duas ferramentas — Crawl4AI autoalojado e ambos os modos do Firecrawl — além da estratégia de sessão que impede que trabalhos de ingestão para RAG morram na página 50. Ele estende nosso guia de proxy para agentes de IA e o guia do browser-use para os frameworks de crawling.

Por que crawlers de LLM são bloqueados mais rápido que scrapers

• Eles buscam de forma ampla, não cirúrgica. Um trabalho de ingestão para RAG puxa centenas de páginas de um domínio inteiro em minutos — exatamente o padrão de velocidade que os sistemas de reputação de IP pontuam com mais severidade (veja detecção por ASN explicada).
• Eles rodam Chromium headless por padrão. O Crawl4AI usa Playwright por baixo dos panos; sem flags, ele exibe os artefatos headless padrão.
• Eles tentam de novo de forma burra. O retry-on-failure padrão contra um muro anti-bot só queima ainda mais a reputação do IP.

Crawl4AI: configuração de proxy

O Crawl4AI (open-source, autoalojado) recebe proxies no nível do BrowserConfig — um proxy por instância 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])

Para crawls profundos, rotacione a identidade por instância de crawler, não por página — páginas dentro de uma mesma visita ao site devem compartilhar um único IP de saída (um humano não muda de cidade entre a página 3 e a página 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: dois modos, duas respostas

Cloud API: o proxy é um parâmetro da requisição — o Firecrawl roteia pelos seus próprios pools. Você controla o nível de qualidade, não os IPs:

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
)

O porém: requisições no nível stealth são cobradas a um múltiplo dos créditos básicos, e você não consegue fixar países com precisão nem manter sessões sticky entre chamadas. Bom para páginas ocasionais; caro e impreciso em volume de ingestão.

Firecrawl autoalojado: você fornece seu próprio proxy via variáveis de ambiente, com controle total:

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

Autoalojado + seu próprio gateway residencial é a configuração mais racional em custo quando você já faz ingestão em escala: você paga por GB de banda em vez de créditos por página com um multiplicador stealth.

Estratégia de sessão para trabalhos de ingestão para RAG

• Um site = uma identidade sticky. Cookies, cache e IP de saída permanecem consistentes durante todo o crawl do site; rotacione entre sites. (Contexto: sticky vs rotativo.)
• Respeite o ritmo por site. As opções semaphore_count / delay do Crawl4AI existem para isso — 2–4 páginas concorrentes por site já bastam; distribua o paralelismo entre os sites.
• Falhe a página, não o trabalho. Em um 403/desafio, marque a URL, rotacione a identidade e continue — retries cegos pelo mesmo IP de saída envenenam sua pontuação.
• Valide o Markdown. Um intersticial anti-bot converte para Markdown perfeitamente — "Verificando se você é humano" embutido no seu banco de dados vetorial é um modo de falha real. Faça grep na saída da ingestão buscando marcadores de páginas de desafio antes de indexar.
• Use cache agressivamente. Re-rastrear páginas inalteradas queima banda e reputação à toa — respeite ETag/Last-Modified onde o framework permitir.

Conferência da realidade dos custos

Configuração	Você paga por	Melhor quando
Firecrawl cloud, proxy stealth	Créditos por página × multiplicador stealth	Baixo volume, zero operação
Firecrawl autoalojado + GB residencial	Apenas banda (~$10/GB)	Volume de ingestão constante
Crawl4AI + GB residencial	Apenas banda, controle total	Pipelines customizados, crawls profundos

Uma página típica com muito texto custa de 100–300 KB através de um proxy — aproximadamente 3.000–10.000 páginas por GB. São os loops de bloqueio-e-retry que estouram o orçamento, o que é mais um motivo para corrigir a detecção antes de escalar o volume.

Resumo

• Crawlers de LLM bloqueados = detecção de IP + headless, não o framework; corrija a camada de rede primeiro.
• Crawl4AI: proxy_config no BrowserConfig; identidade sticky por site, rotacione entre sites.
• Firecrawl cloud: parâmetro proxy: "stealth", caro em volume; autoalojado: seu próprio gateway via variáveis de ambiente.
• Valide a saída Markdown buscando texto de página de desafio antes que ela chegue ao seu banco de dados vetorial.
• Residencial por GB ganha dos créditos stealth por página assim que a ingestão é constante.