Un paquete de tráfico casi siempre se acaba antes de lo que preveía el presupuesto, y casi nunca por un precio por gigabyte demasiado alto. El motivo es que el consumo se calcula por tarea, pero se gasta según lo que realmente pesa cada página cargada: entre una solicitud de texto y una página con gráficos completos y vídeo hay un orden de magnitud de diferencia. Veamos de dónde sale el sobreconsumo, cómo calcularlo de antemano y qué hacer cuando el límite se agota en plena faena.

Por qué el paquete de gigabytes se acaba de golpe

El cálculo «cien páginas, o sea, poco tráfico» se rompe con la primera ficha con imágenes: una página de catálogo en texto pesa entre 0,3 y 1 MB, mientras que una ficha de producto con fotos ya pesa entre 2 y 5 MB, es decir, varias veces más. Un feed con reproducción automática de vídeo suma decenas de megabytes por minuto, aunque nadie vea el vídeo completo. Mil comprobaciones de fichas de producto ya son entre 3 y 5 GB, y no «mil solicitudes» abstractas, como suelen calcular los principiantes.

La segunda fuente de consumo invisible es la carga accesoria: las fuentes, los rastreadores de analítica, los scripts publicitarios y la precarga de páginas vecinas consumen tráfico incluso cuando la automatización accede a una sola URL. Esos bytes no se ven en el registro de solicitudes, pero se descuentan del mismo paquete.

Control del consumo por tu cuenta

No basta con fiarse del panel del proveedor del canal: allí el consumo se ve a posteriori, por lo general con retraso y sin desglose por tarea o script concreto. Un contador propio, a nivel del cliente HTTP o de una capa intermedia sobre el proxy, cuenta los bytes de cada solicitud y permite ver de inmediato qué parte de la automatización gasta más que el resto.

Referencias para planificar: mil páginas de texto, cerca de 1 GB; cien fichas de producto con imágenes, de 0,3 a 0,5 GB; el monitoreo diario de cien páginas, de 1,5 a 3 GB al mes. Comparar el consumo real con estas cifras muestra rápido qué tarea se salió de lo previsto; de la misma manera conviene revisar el resto de las métricas del canal, que analizamos en el artículo cómo comprobar la calidad de un proxy.

Límites estrictos en la automatización

El control blando, es decir, el aviso cuando se supera un umbral, funciona solo cuando el tráfico ya se ha gastado. El control estricto se aplica en el propio script: un máximo de solicitudes por sesión o por hora y un máximo de peso por respuesta; si una página responde con un cuerpo mayor de lo esperado, la conexión se corta en lugar de descargarse por completo. Esta misma regla cubre el caso de una descarga de vídeo que se queda colgada o de un archivo multimedia abierto por error en lugar de HTML.

Por separado, conviene bloquear la carga de imágenes, fuentes y rastreadores allí donde la automatización no necesita un resultado visual: el ahorro se consigue así, y no eligiendo el canal más barato, porque las sesiones rotas y los reintentos en un canal inestable cuestan más que los gigabytes ahorrados. El análisis de dónde el ahorro en el canal es ilusorio está en el artículo proxies baratos frente a proxies caros.

Alertas por umbral

Una notificación cuando el paquete ya se agotó no sirve de nada: la tarea ya se detuvo. Lo que funciona es una alerta escalonada: un aviso al 70–80 % de la cuota da tiempo para recargar el saldo o frenar los procesos en segundo plano, y el umbral del 95 % es la señal para pausar las tareas no críticas hasta la siguiente recarga. Estos umbrales se configuran en tu propio control del consumo, y no se espera a que los avise el proveedor del canal.

Reparto de cuotas y plan para cuando se acabe el tráfico

Un paquete de tráfico común para todas las tareas y todos los empleados casi garantiza que un proceso sin límites, por ejemplo un ciclo de rotación olvidado mediante API, se coma la cuota que necesitaba una tarea prioritaria. La práctica que funciona es dividir el volumen en subcuotas por tarea o por persona, aunque físicamente sea el mismo paquete de GB del proveedor.

Cuando la cuota se acaba de todos modos en plena faena, el orden de acciones es sencillo: detener primero las tareas en segundo plano y las no urgentes, dejar solo el proceso crítico, recargar tráfico para la tarea concreta y no para el fondo común, y anotar qué script se pasó de lo calculado; de lo contrario, el sobreconsumo se repetirá en el siguiente ciclo.

Preguntas frecuentes

¿Se puede calcular de antemano el consumo exacto de tráfico de una tarea?

Exacto, no, pero con un margen de error del 20–30 % sí, si calculas no por el número de solicitudes, sino por tipo de página: de texto, con imágenes, con vídeo. La primera semana con el control de consumo activado por tu cuenta te da cifras reales para esa tarea concreta.

¿Qué conviene más con un consumo impredecible: una dirección dedicada o el pago por tráfico?

Una dirección dedicada de centro de datos o ISP se cobra por mes con una suma fija, independientemente del volumen, por eso, para tareas con tráfico impredecible pero poco exigentes en geolocalización, elimina el riesgo de sobreconsumo. Los canales residenciales y móviles se cobran por gigabyte con asignación de dirección por sesión: aquí importa más el control que la elección de la tarifa.

¿Cómo distinguir un consumo normal de uno anómalo?

Una anomalía es un salto brusco respecto a tu propio promedio de los días anteriores, y no la superación de una cifra absoluta. Si una tarea suele gastar 1 GB al día y en una hora se fueron 2 GB, es motivo para detener el proceso y revisar los registros, y no para adivinar a partir de páginas sueltas.

Las tarifas por tráfico y las direcciones dedicadas mensuales están en el catálogo de proxies; allí mismo puedes separar los pools para distintas tareas y configurar límites desde tu cuenta.