En un plan por GB, lo que define el coste no es el número de peticiones: es el peso de lo que circula. La misma rutina puede costar muchas veces más o muchas veces menos según cómo esté escrita.
Este artículo cubre la elección del producto y, sobre todo, cómo reducir el consumo.
Primero: qué producto usar
Tres opciones, con lógicas distintas.
Residencial rotativo (por GB): IP de conexiones domésticas reales, con rotación. Es lo habitual en la recogida de datos: repartir las peticiones entre muchas direcciones reduce la tasa concentrada en una sola IP, que es lo que limitan los destinos. En ProxyBox, el residencial rotativo por GB es de IP de Brasil, con filtro por estado y ciudad; sirve si el contenido que te interesa es el que se ve desde Brasil.
IPv6 en lote (por IP): mucho más barato por dirección, sin cobro por GB, con el país elegido en el checkout. El límite es estricto: solo funciona en destinos que publican un registro AAAA en el DNS. Compruébalo antes de contratar, porque no hay adaptación posible; la prueba está en cómo saber si un sitio acepta IPv6.
API de recogida (por petición): envías la URL y recibes el contenido, con la rotación y el renderizado gestionados por el proveedor. Cuesta más por petición y ahorra semanas de ingeniería.
La elección entre los tres:
| Situación | Producto |
|---|---|
| El destino limita por IP, volumen moderado | Residencial rotativo |
| El destino acepta IPv6 y necesitas muchas direcciones | IPv6 en lote |
| Volumen alto y destino estable | IPv6 o residencial, bien optimizado |
| Destino complejo, equipo pequeño | API de recogida |
| Recogida que exige renderizar JavaScript | API, o residencial con navegador headless |
Quien recoge páginas para alimentar modelos de IA suele usar Crawl4AI; la configuración del proxy por petición y la rotación de una lista están en Crawl4AI con proxy.
Si empiezas de cero, qué es la técnica, cuándo es legítima y por qué la fuente oficial va primero está en qué es el web scraping.
Lo que de verdad consume GB
Este es el dato que cambia el presupuesto: una página de producto de una tienda online pesa varios megabytes. La información que probablemente quieres (nombre, precio, disponibilidad) pesa unos pocos kilobytes.
El resto son imágenes, fuentes, hojas de estilo, scripts de terceros y píxeles de seguimiento. Estás pagando por descargar todo eso.
Una señal de que la rutina es demasiado agresiva es que el sitio responda con el error 429 Too Many Requests: antes de repartir entre IP, conviene leer la cabecera Retry-After y bajar el ritmo, porque el límite puede ser por cuenta o por clave, y entonces ninguna IP lo resuelve.
Cinco ajustes que reducen el consumo drásticamente
1. Bloquea los recursos que no usas
Si usas un navegador headless, bloquea lo que no te interesa antes de que la página cargue:
// Playwright
await page.route('**/*', route => {
const type = route.request().resourceType()
if (['image', 'font', 'media', 'stylesheet'].includes(type)) {
return route.abort()
}
return route.continue()
})
Este ajuste por sí solo suele eliminar la mayor parte del tráfico, sin afectar a la extracción de datos de texto.
2. Prefiere el endpoint JSON a la página renderizada
La mayoría de los sitios modernos alimentan su propia interfaz con llamadas internas a una API. Abre las herramientas de desarrollo, pestaña de red, y observa las peticiones XHR mientras navegas.
Si hay un endpoint que devuelve los datos en JSON, consumirlo en lugar de renderizar la página es la diferencia entre kilobytes y megabytes por artículo.
Además es más estable: los cambios de diseño no rompen la recogida.
3. Evita el navegador cuando basta una petición HTTP
El navegador headless existe para las páginas que solo montan el contenido con JavaScript. Si el HTML devuelto ya contiene el dato, una petición HTTP simple hace el trabajo con una fracción del tráfico y del tiempo.
Prueba primero con curl. Si el dato aparece en el HTML en bruto, no uses navegador.
4. Activa la compresión
curl -H "Accept-Encoding: gzip, deflate, br" --compressed \
-x http://usuario:contrasena@host:puerto https://ejemplo.com
La mayoría de los clientes HTTP lo hacen por defecto, pero conviene confirmarlo. Las respuestas comprimidas ocupan bastante menos en tránsito.
5. Caché y deduplicación
El ajuste más sencillo y el más olvidado: no vuelvas a recoger lo que no ha cambiado.
Guarda un identificador y una marca de la última recogida. Si el artículo se comprobó hace una hora y el destino se actualiza a diario, no hay motivo para buscarlo de nuevo.
En catálogos grandes, esto reduce el consumo en un orden de magnitud.
Cómo estimar el paquete de GB
No lo estimes por intuición. Mide:
- Recoge cien artículos con la rutina ya optimizada.
- Anota el tráfico total consumido.
- Divide entre cien para obtener el peso medio por artículo.
- Multiplica por el volumen mensual previsto.
- Añade un 30 % de margen para reintentos y variaciones.
Ejemplo:
100 artículos = 45 MB consumidos
Peso medio = 450 KB por artículo
Volumen mensual = 50.000 artículos
Estimación = 50.000 × 450 KB ≈ 22 GB
Con un margen del 30 % ≈ 29 GB
Hacer esta medición antes de comprar evita tanto el paquete demasiado pequeño como el exceso comprado por precaución.
Sesión fija: úsala solo donde haga falta
Un proxy residencial rotativo normalmente permite fijar la sesión, es decir, mantener la misma dirección durante unos minutos.
Eso es necesario en flujos con estado: paginación que depende de la sesión, carrito, inicio de sesión. Fuera de esos casos, una sesión larga innecesaria concentra el tráfico en una dirección sin ningún beneficio, y es justo lo que limita el destino.
Usa la sesión fija como excepción, no como norma.
Los tres modos de rotación (fija, por sesión y por petición), y por qué "rotativo ilimitado" no significa tráfico ilimitado, están en rotación de IP: fija, por sesión o por petición.
Lo que el proxy no resuelve
- No reduce el peso de las páginas. El ahorro de GB sale de la rutina, no de la red.
- No sortea límites por cuenta o por clave de API. Si el destino cuenta por usuario, más IP no cambian nada.
- No hace legítima una recogida que los términos prohíben.
Sobre responsabilidad
La recogida de datos públicos es una práctica habitual de investigación de mercado y de seguimiento de la competencia. Eso no significa que todo esté permitido.
Sigues siendo responsable de respetar los términos de uso de cada servicio y la legislación aplicable: el RGPD en la Unión Europea y las leyes locales de protección de datos en otros países, sobre todo al tratar datos personales, para los que necesitas una base legal.
Nuestra política de uso aceptable detalla lo que no está permitido en nuestra red. La recogida de datos personales sin base legal y el uso para fraude están entre los puntos prohibidos.
En muchos casos la fuente oficial evita la recogida de páginas: API públicas, portales de datos abiertos o exportaciones que el propio sitio ofrece. Compruébalo antes de escribir el primer script.
Resumen
- El residencial rotativo por GB es lo habitual en la recogida de datos; el IPv6 en lote es más barato cuando el destino lo acepta.
- El coste lo define el peso de las respuestas, no el número de peticiones.
- Bloquear imágenes, fuentes, multimedia y CSS elimina la mayor parte del tráfico.
- El endpoint JSON en lugar de la página renderizada es la optimización más eficaz.
- Caché y deduplicación antes de ampliar el paquete.
- Mide con una muestra de cien artículos antes de estimar.
Si la misma infraestructura también opera cuentas con sesión iniciada, separa las dos cosas antes de comprar: el criterio de cuántas direcciones pide cada caso está en automatización con proxy: cuántas IP necesitas.
Para elegir el plan, la página de proxy para web scraping resume los productos por escenario y la de proxies residenciales explica el cobro por GB; los precios están en /precios. La configuración en Playwright, Puppeteer y Scrapy está en la guía de automatización.