Límite de tráfico para el scraping de Wildberries y Ozon: cómo no desperdiciar un paquete mensual de proxies en una noche

El vendedor inicia el scraper de precios de competidores por la noche y por la mañana recibe una notificación: el tráfico se ha agotado, el paquete se ha consumido en un 90%. ¿Situación familiar? La mayoría de las veces, la culpa no es del scraper en sí, sino de la falta de límites a nivel de proxies y del script. En este artículo, analizaremos cómo exactamente el tráfico "se escapa" en vano y cómo establecer protecciones para que el paquete mensual de proxies residenciales o móviles dure hasta el final del período de cálculo.

Por qué el tráfico se agota en una noche

Hacer scraping de Wildberries, Ozon o Avito parece una tarea sencilla: envías una solicitud y recibes un JSON con el precio. Pero en la práctica, el tráfico se consume no solo en datos útiles. Las principales fuentes de sobreconsumo son:

• Carga de imágenes y medios. Si el scraper abre la página del producto completamente a través de un navegador (y no hace una solicitud directa a la API), automáticamente carga imágenes, videos, banners: esto puede ser decenas de megabytes por cada tarjeta.
• Solicitudes repetidas debido a CAPTCHAs y bloqueos. El marketplace reconoce al bot, presenta un CAPTCHA o un baneo temporal de IP, el script hace una solicitud repetida: el tráfico se desperdicia y los datos no llegan.
• Falta de almacenamiento en caché de solicitudes. Sin la lógica de "ya se ha scrapeado en esta hora - no repetir", el script puede consultar las mismas tarjetas varias veces durante la noche.
• Flujos paralelos sin limitación. Ejecutar 50-100 flujos simultáneamente parece acelerar el trabajo, pero el tráfico se consume mucho más rápido de lo planeado, y parte de las solicitudes simplemente se bloquean.
• Elección incorrecta del tipo de proxy. Los proxies residenciales y móviles generalmente se facturan por volumen de tráfico (GB), a diferencia de los proxies de centros de datos, donde la facturación suele ser por número de IP o tiempo de alquiler. Si el scraper está configurado para un pool residencial sin control, el límite se agota rápidamente.

La combinación de estos factores lleva a que un script, diseñado para un mes de trabajo, consuma un paquete de tráfico en una sola sesión nocturna de scraping de 10-20 mil tarjetas de productos.

Cómo se calcula el tráfico en diferentes tipos de proxies

Antes de establecer límites, es importante entender por qué exactamente estás pagando. Diferentes tipos de proxies contabilizan el consumo de manera diferente, y esto afecta directamente la estrategia de ahorro.

Tipo de proxy	Facturación	Riesgo de sobreconsumo	Cuándo aplicar
Proxies residenciales	Por volumen de tráfico (GB)	Alto sin límites	Scraping eludiendo la protección anti-bot de los marketplaces
Proxies móviles	Por volumen de tráfico o por tiempo	Alto, el tráfico es más caro	Scraping de versiones móviles de sitios, eludiendo bloqueos severos
Proxies de centros de datos	Por número de IP / tiempo de alquiler	Bajo, el tráfico suele ser ilimitado	Scraping masivo sin estricta protección anti-bot

Si estás haciendo scraping de Wildberries o Ozon, donde la protección contra bots está activa, las IP residenciales o móviles son casi siempre necesarias, ya que las direcciones de centros de datos se bloquean rápidamente. Pero precisamente debido a la facturación por tráfico, aquí es especialmente importante establecer límites de antemano.

Cuánto tráfico realmente se necesita para el scraping

Para establecer un límite adecuado, es necesario basarse en cifras reales, no en sensaciones. Los gastos aproximados en la práctica son:

• Solicitud a la API de la tarjeta de producto (JSON, sin imágenes): 5-30 KB por tarjeta. Para 10,000 tarjetas, alrededor de 50-300 MB.
• Carga de la página del producto a través de un navegador sin cabeza con imágenes: 1-3 MB por tarjeta. Para las mismas 10,000 tarjetas, 10-30 GB.
• Monitoreo de precios una vez por hora para 1000 SKU: con solicitudes ligeras, alrededor de 1-5 GB por día, con carga completa de páginas, 50-100 GB por día.

La diferencia entre el scraping "ligero" y "pesado" es de decenas de veces. Por lo tanto, el primer paso para ahorrar tráfico es desactivar la carga de imágenes, videos y scripts externos donde sea posible, y trabajar directamente con la API del marketplace o la versión móvil del sitio, que pesa menos que la versión de escritorio.

Límites en navegadores anti-detección y administradores de proxies

Para aquellos que hacen scraping a través de un navegador anti-detección (por ejemplo, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) o su propio administrador de proxies, la forma más sencilla de limitar el consumo es configurar límites a nivel de perfil y cuenta del proveedor de proxies.

1. Inicia sesión en el panel de control del proveedor de proxies y busca la sección de gestión de tráfico o límites por sub-usuarios/puertos.
2. Crea una subcuenta o puerto separado para el scraping — no uses el mismo pool de proxies que para la creación de cuentas en Instagram o TikTok. La separación por tareas muestra inmediatamente a dónde va el tráfico.
3. Establece un límite diario o por hora de tráfico en esta subcuenta — por ejemplo, 5 GB por día en lugar de consumir todo el paquete mensual en una sola sesión.
4. En el navegador anti-detección, desactiva la carga automática de imágenes para perfiles que se utilizan exclusivamente para la recolección de datos, no para la visualización visual de páginas.
5. Configura un horario de inicio de perfiles para que el scraping se realice no en una sola sesión larga, sino en intervalos cortos con pausas — esto reduce el riesgo de bloqueo y da tiempo para rastrear el consumo de tráfico entre ejecuciones.

Este enfoque es especialmente importante para agencias y freelancers que realizan scraping en varios marketplaces al mismo tiempo: sin separación por subcuentas, es difícil entender qué proyecto "consume" el tráfico.

Límite de tráfico a nivel de script y API

Si el scraper está escrito de forma independiente en Python o Node.js, los límites se pueden y deben integrar directamente en el código — esto proporciona un control más preciso que la configuración de la interfaz del proveedor de proxies.

Un ejemplo de un simple contador de tráfico en Python utilizando requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # límite de 5 GB por día
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("El límite diario de tráfico se ha agotado, scraping detenido")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# ejemplo de llamada
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Tráfico utilizado:", round(used_bytes / 1024 / 1024, 2), "MB")

La lógica es simple: el script cuenta el volumen de cada respuesta en bytes y se detiene tan pronto como se alcanza el límite establecido. Esto protege contra la situación en la que, debido a un error en el ciclo o una repetición infinita de solicitudes, el script "consume" el paquete mensual de tráfico en pocas horas.

Además, vale la pena agregar:

• Retraso exponencial en caso de errores (retry con backoff) — en lugar de repetir inmediatamente la solicitud ante un CAPTCHA o baneo, el script espera un intervalo creciente (5 seg, 15 seg, 60 seg), lo que reduce el número de solicitudes inútiles.
• Límite en el número de flujos paralelos — por ejemplo, no más de 10-20 conexiones simultáneas a través del pool de proxies, para no provocar bloqueos y no desperdiciar tráfico.
• Desactivar la carga de recursos en el navegador sin cabeza — si el scraping se realiza a través de Selenium o Puppeteer, en la configuración del navegador se pueden bloquear la carga de imágenes, fuentes y CSS, dejando solo las respuestas HTML/JSON.

Monitoreo del consumo en tiempo real

Un límite sin monitoreo funciona peor, porque solo te enteras del problema después de que el script se detiene. Para controlar el consumo sobre la marcha:

• Activa las notificaciones en el panel de control del proveedor de proxies sobre el alcance del 50%, 80% y 100% del paquete mensual de tráfico — la mayoría de los servicios admiten tales alertas por correo electrónico o en Telegram.
• Mantén un registro simple en el propio script: registra en un archivo o base de datos el volumen de tráfico por horas, para ver los picos de consumo y encontrar rápidamente la fuente del problema.
• Separa el tráfico por tareas a través de subcuentas o etiquetas separadas — una para el scraping de Wildberries, otra para Ozon, otra para Avito. Esto simplifica el análisis de qué proyecto consume más.
• Compara el consumo con el volumen de datos esperado: si para 10,000 tarjetas se gastaron 20 GB en lugar de los 300 MB calculados, significa que se están cargando recursos adicionales o se están realizando solicitudes repetidas.

Lista de verificación para el control del presupuesto de tráfico

Errores comunes de principiantes

En la práctica, la mayoría de los paquetes de tráfico "quemados" se explican por varios errores típicos:

• Ejecutar el scraping "por la noche sin supervisión" sin límites. El script funciona 8-10 horas sin detenerse, y si en algún lugar ocurre un ciclo de solicitudes repetidas, el tráfico se consume continuamente hasta la mañana.
• Un pool de proxies común para todas las tareas. La creación de cuentas en Instagram, la prueba de anuncios en Facebook Ads y el scraping de Ozon utilizan el mismo tráfico — es imposible entender qué lo consume.
• Ignorar los CAPTCHAs. En lugar de reducir la frecuencia de solicitudes ante los primeros signos de un CAPTCHA, el script sigue golpeando el sitio con la misma intensidad, gastando tráfico en respuestas inútiles con código de error.
• Elegir proxies residenciales donde son suficientes los de centros de datos. Si el marketplace no bloquea estrictamente las IP de centros de datos, el sobrepago por el tráfico del pool residencial no está justificado — para objetivos menos protegidos, se pueden utilizar proxies de centros de datos con otro modelo de facturación.
• Falta de una prueba de ejecución. Antes de iniciar un scraping completo de miles de tarjetas, es recomendable ejecutar el script en 50-100 tarjetas y medir el consumo real de tráfico para extrapolarlo a todo el volumen.

Conclusión

El tráfico para el scraping "se quema" no por el volumen de datos, sino por la falta de control: imágenes innecesarias, solicitudes repetidas ante bloqueos, flujos paralelos sin limitaciones y un pool de proxies común para todas las tareas. La solución es dividir el tráfico por proyectos, establecer límites diarios a nivel de cuenta de proxies, integrar un contador de consumo en el propio script y configurar el monitoreo con notificaciones antes de que el paquete realmente se agote.

Si estás haciendo scraping de marketplaces con protección activa contra bots como Wildberries o Ozon, te recomendamos utilizar proxies residenciales para eludir bloqueos y, adicionalmente, IP móviles para los escenarios más sensibles a la protección anti-bot — pero en ambos casos, asegúrate de establecer límites de tráfico de antemano para que el paquete mensual no se agote en una sola sesión nocturna.