Configuración de proxy para Crawl4AI y Firecrawl: ingesta para RAG sin bloqueos (2026)

Crawl4AI y Firecrawl se han convertido en la forma por defecto de alimentar datos web a las pipelines de LLM — rastrean, renderizan y devuelven Markdown limpio que tu modelo realmente puede usar. Luego los apuntas a un objetivo real y descubres lo que todo scraper acaba aprendiendo: la capa de extracción nunca fue la parte difícil. La parte difícil es que tu rastreador se ejecuta desde una sola IP de centro de datos, y la web puede verlo.

Esta guía muestra la configuración de proxy funcional para ambas herramientas — Crawl4AI autoalojado y ambos modos de Firecrawl — más la estrategia de sesión que evita que los trabajos de ingesta para RAG mueran en la página 50. Amplía nuestra guía de proxies para agentes de IA y la guía de browser-use a los frameworks de crawling.

Por qué los rastreadores de LLM se bloquean más rápido que los scrapers

• Recogen de forma amplia, no quirúrgica. Un trabajo de ingesta para RAG extrae cientos de páginas de todo un dominio en minutos — el patrón exacto de velocidad que los sistemas de reputación de IP puntúan con más dureza (consulta la detección de ASN explicada).
• Ejecutan Chromium headless por defecto. Crawl4AI usa Playwright por debajo; sin flags, muestra artefactos headless estándar.
• Reintentan de forma estúpida. El reintento-ante-fallo por defecto contra un muro antibot solo hunde más la reputación de la IP.

Crawl4AI: configuración del proxy

Crawl4AI (open-source, autoalojado) acepta proxies a nivel de BrowserConfig — un proxy por instancia de rastreador:

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 rastreos profundos, rota la identidad por instancia de rastreador, no por página — las páginas dentro de una misma visita al sitio deberían compartir una IP de salida (un humano no cambia de ciudad entre la página 3 y la 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: dos modos, dos respuestas

API en la nube: el proxy es un parámetro de la petición — Firecrawl enruta a través de sus propios pools. Controlas el nivel de calidad, no las 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
)

La pega: las peticiones de nivel stealth se facturan a un múltiplo de los créditos basic, y no puedes fijar países con precisión ni mantener sesiones sticky entre llamadas. Bien para páginas ocasionales; caro e impreciso a volumen de ingesta.

Firecrawl autoalojado: proporcionas tu propio proxy mediante variables de entorno, con control total:

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

Autoalojado + tu propia puerta de enlace residencial es la configuración racional en cuanto a coste una vez que ingieres a escala: pagas por GB de ancho de banda en lugar de créditos por página con un multiplicador de stealth.

Estrategia de sesión para trabajos de ingesta para RAG

• Un sitio = una identidad sticky. Cookies, caché e IP de salida se mantienen consistentes durante todo el rastreo del sitio; rota entre sitios. (Contexto: sticky vs. rotativo.)
• Respeta el ritmo por sitio. Las opciones semaphore_count / delay de Crawl4AI existen para esto — 2–4 páginas concurrentes por sitio es de sobra; reparte el paralelismo entre sitios.
• Falla la página, no el trabajo. Ante un 403/challenge, marca la URL, rota la identidad y continúa — los reintentos ciegos a través de la misma salida envenenan su puntuación.
• Valida el Markdown. Un intersticial antibot se convierte a Markdown sin problema — "Verificando que eres humano" incrustado en tu base de datos vectorial es un modo de fallo real. Haz grep de la salida de ingesta en busca de marcadores de páginas de challenge antes de indexar.
• Cachea de forma agresiva. Re-rastrear páginas sin cambios quema ancho de banda y reputación para nada — respeta ETag/Last-Modified donde el framework lo permita.

Reality check de costes

Configuración	Pagas por	Mejor cuando
Firecrawl en la nube, proxy stealth	Créditos por página × multiplicador de stealth	Bajo volumen, cero operaciones
Firecrawl autoalojado + GB residenciales	Solo ancho de banda (~$10/GB)	Volumen de ingesta constante
Crawl4AI + GB residenciales	Solo ancho de banda, control total	Pipelines a medida, rastreos profundos

Una página típica con mucho texto cuesta 100–300 KB a través de un proxy — aproximadamente 3.000–10.000 páginas por GB. Los bucles de bloqueo-y-reintento son lo que dispara el presupuesto, lo cual es otra razón para arreglar la detección antes de escalar el volumen.

Resumen

• Rastreadores de LLM bloqueados = detección de IP + headless, no el framework; arregla la capa de red primero.
• Crawl4AI: proxy_config en BrowserConfig; identidad sticky por sitio, rota entre sitios.
• Firecrawl en la nube: parámetro proxy: "stealth", costoso a volumen; autoalojado: tu propia puerta de enlace vía variables de entorno.
• Valida la salida en Markdown buscando texto de páginas de challenge antes de que llegue a tu base de datos vectorial.
• El residencial por GB le gana a los créditos stealth por página una vez que la ingesta es constante.