El esquema "levanté Firecrawl en Docker, lo dirigí a una lista de dominios, obtuve markdown para RAG" funciona hasta la primera mil páginas. Después llegan dos cuentas. La primera — de los anti-bots: parte de los dominios comienza a devolver 403 en lugar de contenido, y en la base de conocimientos aparecen huecos, de los que te enteras cuando el asistente responde "no hay información en los materiales proporcionados". La segunda cuenta — por el tráfico: el rastreador tira honestamente cada imagen y cada fuente, que en el markdown final de todos modos no se incluirán.
Analicemos cómo conectar un proxy a los tres rastreadores LLM más populares de 2026 — Firecrawl, Crawl4AI y Crawlee — y cómo configurarlos para que el proxy funcione solo donde se necesita, y no consuma gigabytes en cada página.
Para quién es esta guía
Si estás recopilando un corpus de documentos para RAG, llenando una base de conocimientos interna, construyendo un pipeline de datos para reentrenamiento o simplemente descargando regularmente cientos de dominios, este es tu caso. Las tres herramientas a continuación, en la configuración predeterminada, funcionan con la IP de tu servidor y cargan la página completa. Ambas configuraciones predeterminadas deben cambiarse.
La magnitud del problema se entiende por los números de popularidad: Firecrawl tiene alrededor de 170,000 estrellas en GitHub (licencia AGPL-3.0) en el momento de la publicación, Crawl4AI tiene alrededor de 79,000, y Crawlee de Apify tiene aproximadamente 25,000. Ya no son experimentos de nicho, sino herramientas estándar, y los sistemas anti-bots conocen su comportamiento tan bien como tú.
Cuenta uno: 403 en lugar de contenido
El error clave al recopilar un corpus es pensar que el rastreador ha funcionado con éxito si no se ha caído. Firecrawl y Crawl4AI en una página bloqueada no devuelven una excepción, sino un resultado: una página de advertencia de anti-bots, una página de verificación de navegador o un breve texto de denegación de acceso. Formalmente, esto es un markdown válido, se coloca sin problemas en la base de datos vectorial y vive allí hasta la primera consulta del usuario.
Por lo tanto, lo primero que hay que hacer antes de cualquier configuración de proxy es añadir un control de calidad del resultado. La opción mínima: descartar documentos más cortos que un cierto umbral (para una página de contenido típica, es razonable 500–800 caracteres de texto) y capturar por separado marcadores característicos en el texto — menciones de verificación de conexión, JavaScript activado, "Acceso denegado". Tales documentos no se envían a la base, sino a una cola para un nuevo rastreo — ya a través del proxy.
Cuenta dos: gigabytes que estás desperdiciando
Aquí ayuda la aritmética. Según datos de Web Almanac de HTTP Archive para 2025, la página principal mediana pesa aproximadamente 2.86 MB en escritorio y 2.56 MB en móviles. De ellos, alrededor de 1,059 KB son imágenes en las páginas principales y 911 KB en las internas, y 697 KB y 632 KB respectivamente para JavaScript. Es decir, las imágenes son la categoría más pesada, aproximadamente un tercio del peso de la página.
Y ahora recuerda qué haces con el resultado. Convierte la página a markdown y la cortas en fragmentos para embeddings. Las imágenes no entran en este pipeline en absoluto — en el mejor de los casos, solo queda una línea con el texto alt. Videos, fuentes, scripts analíticos, píxeles publicitarios — también se quedan fuera.
Si realizas el rastreo a través de un proxy residencial con pago por gigabyte, literalmente estás pagando por la entrega de datos que desechas en el siguiente paso del pipeline. En un corpus de 100,000 páginas, la diferencia entre "extraer todo" y "extraer solo HTML y texto" se mide no en porcentajes, sino en veces. El ahorro exacto depende de la temática de los sitios: medios y comercio electrónico son más pesados que documentación y blogs.
Paso 1. Escalación en lugar de "proxy para todo"
La principal técnica arquitectónica que más ahorra es: no enviar todo el tráfico a través del proxy. La mayoría de los dominios al recopilar una base de conocimientos — documentación, blogs, sitios de referencia, portales gubernamentales — entregan contenido directamente y no bloquean a nadie. El proxy es necesario para una minoría.
El esquema correcto es una escalación multinivel: primero una solicitud directa, al detectar signos de bloqueo — pasar al siguiente nivel. Y esto no es un parche hecho a mano, ambos marcos adultos lo hacen de forma nativa.
En Crawlee, para esto existe tieredProxyUrls. Los niveles se enumeran de barato a caro, y el rastreador sube automáticamente en caso de bloqueos, y luego intenta volver periódicamente al nivel inferior:
const proxyConfiguration = new ProxyConfiguration({
tieredProxyUrls: [
[null],
['http://user:pass@datacenter-proxy:8080'],
['http://user:pass@residential-proxy:8000'],
]
});Un matiz importante de la documentación: tieredProxyUrls solo funciona al usarlo a través de una instancia del rastreador. Llamadas directas a newUrl() darán un resultado inesperado.
En Crawl4AI, un mecanismo similar apareció en la versión 0.8.5 y vive en la rama actual (la última versión en el momento de la publicación es v0.9.2 del 15 de julio de 2026). Se llama escalación de proxy y se configura directamente en CrawlerRunConfig: detección de bloqueo de tres niveles — proveedores de anti-bots conocidos, indicadores generales de bloqueo y verificación de integridad estructural de la página — más reintentos automáticos en cadena 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,
)Presta atención a ProxyConfig.DIRECT como primer elemento — eso significa "primero intenta sin proxy".
Paso 2. Conectar el proxy en cada herramienta
A continuación, la especificidad de la configuración. El orden de las acciones es el mismo: primero el proxy, luego el corte del tráfico innecesario, luego la verificación.
- Firecrawl (autoalojado). El proxy se establece mediante tres variables de entorno que se pasan a Playwright:
PROXY_SERVER,PROXY_USERNAME,PROXY_PASSWORD. Se escriben en.envparaapps/api; en el comentario a ellas, los desarrolladores indican que en lugar de una dirección estática se puede especificar un servicio de proxy que rota IP en cada solicitud. - Crawl4AI. El proxy vive en
BrowserConfig, en el campoproxy_config— es un objetoProxyConfigo un diccionario con los camposserver,username,password. Una configuración de navegador para toda la sesión de rastreo; unCrawlerRunConfigseparado se pasa a cada llamada aarun(). - Crawlee. La clase
ProxyConfigurationcon la opciónproxyUrls— una lista de direcciones, por la cual la biblioteca va en círculo (round-robin). Un valornullen la lista significa "sin proxy". La integración es completa:HttpCrawler,CheerioCrawler,JSDOMCrawler,PlaywrightCrawler,PuppeteerCrawler. - Reglas puntuales. Si se sabe qué dominios bloquean y cuáles no, en Crawlee hay
newUrlFunction— su propia lógica para elegir el proxy en función de la URL de la solicitud. Para dominios blancos, devuelvesnull, para los demás — la dirección del proxy. Esta es la opción más económica, cuando la lista de objetivos es estable. - Verificación. Antes de la ejecución en producción, pasa a través del rastreador configurado una página que devuelve tu IP externa y asegúrate de que ves la dirección del proxy, no la del servidor. Tres líneas que ahorran un día de aclaraciones.
Paso 3. Cortar todo lo que no se convierta en texto
Cuando el proxy está conectado, activa el ahorro de tráfico — de lo contrario, la cuenta por gigabytes llegará más rápido de lo que se recopile el corpus.
En Firecrawl, esto lo maneja la variable BLOCK_MEDIA. En el ejemplo oficial de configuración, tiene un comentario literal: establece esto si deseas bloquear solicitudes de medios para ahorrar ancho de banda del proxy. Este es el modo más rápido de eliminar el principal artículo de gastos.
En Crawl4AI, mecanismos similares viven en BrowserConfig: text_mode desactiva imágenes y acelera el rastreo de texto, light_mode apaga algunas funciones de fondo del navegador, avoid_css bloquea la carga de CSS. Se pueden combinar. Para recopilar un corpus para RAG, este es casi siempre el conjunto correcto — no necesitas el diseño, necesitas texto.
En Crawlee, la lógica es diferente: si el contenido se entrega en HTML, utiliza CheerioCrawler o HttpCrawler en lugar de los basados en navegador. Una solicitud HTTP normal en lugar de un renderizado completo — no solo es ahorro de tráfico, es un orden diferente de gastos. Deja los rastreadores basados en navegador (PlaywrightCrawler, PuppeteerCrawler) solo para páginas que no se pueden recopilar sin JavaScript.
Trampas
Sesiones contra rotación. Cambiar IP en cada solicitud parece sospechoso y rompe escenarios de múltiples pasos — paginación, transiciones dentro de un mismo dominio. En Crawlee, cada llamada a newUrl() vincula el proxy con un objeto Session, y se rotan junto con las huellas del navegador y los encabezados. No rompas esta conexión manualmente.
Medios desactivados, pero el contenido ha desaparecido. Algunos sitios cargan de manera perezosa no solo imágenes, sino también texto. Después de activar text_mode o BLOCK_MEDIA, asegúrate de pasar una muestra de control de 20–30 páginas y compara el volumen de texto con el estándar.
Reintentos sin límite. La escalación a través de niveles de proxy significa que una página obstinada puede ser descargada tres veces — y las tres veces pagadas. Limita max_retries y crea una lista de dominios que después de N intentos fallidos se excluyen completamente del rastreo.
Robots.txt y marco legal. La recopilación de datos para entrenamiento y RAG en 2026 está regulada más estrictamente que hace un par de años — desde requisitos de divulgación de fuentes hasta mecanismos de exclusión de text and data mining. Asegúrate de que tu pipeline respete estas señales antes de que funcione en cientos de miles de páginas.
Qué tipo de proxy elegir para el pipeline de RAG
La respuesta depende de en qué nivel de escalación te encuentres.
- Nivel cero — sin proxy. Documentación, proyectos de código abierto, sitios gubernamentales, la mayoría de los blogs corporativos. Aquí la IP del servidor funciona bien, y no hay nada por lo que pagar.
- Nivel medio — proxy de datacenter. Rápidos y baratos, son adecuados contra limitaciones de tasa simples y restricciones regionales. Al recopilar grandes corpus, son un caballo de batalla: cuando el volumen se mide en cientos de gigabytes, la diferencia de precio por gigabyte se convierte en el factor principal.
- Nivel superior — proxy residenciales. Para dominios con una protección anti-bots seria, donde las subredes de datacenter son filtradas en la entrada. Por eso no se pueden establecer como nivel predeterminado — pagar por gigabyte convierte cada imagen adicional en una línea de gastos.
Antes de construir el pipeline, vale la pena calcular honestamente la economía: hemos analizado el costo total de raspar un millón de páginas teniendo en cuenta el peso de las páginas, reintentos y gastos ocultos. Y una pregunta separada que es útil hacer antes de escribir la primera línea de código: ¿realmente necesitas el rastreo? — en el análisis de API oficial contra conjuntos de datos listos y raspado se ve que para algunas fuentes, los datos listos son más baratos que un rastreador propio.
Conclusión
El proxy en el rastreador LLM no es un interruptor "encender/apagar", sino un esquema de tres niveles. Solicitud directa como nivel predeterminado, proxy de datacenter en el medio, residenciales — solo para dominios que de otro modo no se pueden obtener. Además, un corte estricto de medios, porque estás recopilando texto y pagando por bytes.
El orden de trabajo es simple: primero control de calidad del resultado (de lo contrario, no sabrás que la mitad del corpus son páginas de advertencia), luego escalación del proxy utilizando las herramientas del propio marco, luego ahorro de tráfico. En ese orden — y el corpus será completo, y la cuenta predecible.
```