La factura por tráfico residencial rara vez coincide con lo que esperaba quien automatiza: una tarea pensada para un par de gigabytes en la práctica consume el doble. Vamos a ver qué entra exactamente en el volumen facturable, de dónde sale la diferencia entre lo esperado y lo cobrado, cómo estimar de antemano el peso de tu tarea y qué prácticas permiten ahorrar tráfico sin perder estabilidad en las sesiones.
Qué se factura exactamente
El contador suma todo el volumen que pasó por el nodo asignado en ambos sentidos: no solo la respuesta HTML útil, sino literalmente todo lo que el navegador o el script solicitó por ese canal. Esto incluye imágenes, fuentes, estilos, scripts de analítica y banners publicitarios de la página: si un elemento se carga a través del proxy, sus bytes van a la misma cuenta que el contenido objetivo.
Las solicitudes de servicio son un capítulo aparte del consumo. Junto con la página principal, el navegador consulta trackers, contadores de impresiones, sincronización de cookies y comprobaciones de actualizaciones; parte de estas llamadas no se ve en la interfaz de automatización, pero cada una pasa por el mismo canal de pago.
Por qué el contador sube más rápido de lo esperado
La causa principal es subestimar el peso de la página al empezar el cálculo. Una ficha de producto con imágenes pesa entre 2 y 5 MB, y no entre 0,3 y 1 MB como una página de resultados en texto; un feed con reproducción automática de video añade decenas de megabytes por minuto sin un solo clic del usuario. Si el presupuesto se calculó con el peso de una página de texto, pero la tarea real abre fichas con contenido multimedia, la diferencia con la factura será de varias veces.
La segunda causa son las repeticiones. Una sesión cortada a mitad de la carga no devuelve el tráfico gastado: el navegador pide la página de nuevo, y los bytes del intento fallido se cobran igual que los del exitoso. Cuanto más inestable sea el canal o el script, más recargas de este tipo aparecen en la factura sin aportar ningún resultado útil. Ahorrar con el canal más barato puede salir en un sobrecosto; hay más detalles en el artículo proxies baratos contra caros: dónde el ahorro es ilusorio.
Cómo medir el peso de la tarea de antemano
Solo una prueba real da un pronóstico preciso: toma de 10 a 20 solicitudes típicas de la tarea, ejecútalas por el canal con el conteo de tráfico activado y calcula el peso promedio por solicitud. Después multiplica esa cifra por el número planeado de solicitudes; es más confiable que cualquier referencia general.
Si no hay prueba, puedes partir del tipo de página: una página de catálogo en texto, de 0,3 a 1 MB; una ficha de producto con imágenes, de 2 a 5 MB. Mil revisiones de fichas caben en unos 3–5 GB, cien en 0,3–0,5 GB, mil páginas de texto en cerca de 1 GB. El monitoreo diario de cien páginas llega a 1,5–3 GB al mes. Estas referencias sirven para una primera estimación del presupuesto, pero la cifra exacta para un sitio concreto solo la da una prueba con URL reales.
Prácticas para ahorrar tráfico
Lo primero y lo más importante: desactivar la carga de imágenes, fuentes y video donde la automatización solo necesita el texto o la estructura de la página. Un navegador headless puede bloquear tipos de recursos a nivel de solicitud, en lugar de renderizar toda la página por un solo campo. Lo segundo: bloquear por lista los dominios de redes publicitarias y trackers: no aportan datos útiles, pero se suman puntualmente a la factura.
Lo tercero: no perseguir el canal más barato a costa de la estabilidad. Una sesión rota sale más cara: la recarga de la página consume tráfico otra vez, y un canal inestable genera justamente esas repeticiones. Lo que hay que calcular no es el precio por gigabyte, sino el costo de un resultado exitoso; las métricas que conviene mirar al elegir proveedor están reunidas en el artículo cómo comprobar la calidad de un proxy.
En qué se diferencia el consumo del canal móvil
En la mecánica de tarificación no hay diferencia: ambos canales entregan una dirección por sesión y cuentan el tráfico según el uso real, gigabyte a gigabyte. La diferencia está en el precio de ese gigabyte y en el motivo por el que cuesta lo que cuesta. La IP móvil funciona a través del NAT del operador celular, donde una sola dirección atiende al mismo tiempo a cientos de abonados reales; el funcionamiento de este mecanismo se explica en el artículo por qué es difícil bloquear los proxies móviles. Por la escasez de estas direcciones y su resistencia al bloqueo, el precio por gigabyte de tráfico móvil suele ser más alto que el del residencial.
Conclusión práctica: si para tu tarea lo crítico es la resistencia al baneo, y no simplemente un ASN «doméstico», el sobrecosto del tráfico móvil se compensa con la cantidad de sesiones exitosas por gigabyte: en una tarea así el canal residencial se banea más a menudo, y los reintentos se comen la diferencia de precio que habías ahorrado.
Preguntas frecuentes
¿Se cuenta el tráfico si la solicitud terminó con error?
Sí, el contador registra los bytes transmitidos sin importar el resultado de la solicitud. Una conexión cortada o una respuesta con error igualmente pasaron por el canal y entraron en el volumen facturado.
¿Se puede limitar desde el script qué se carga a través del proxy?
Sí, la mayoría de los navegadores headless y bibliotecas de automatización permiten bloquear tipos de recursos (imágenes, fuentes, multimedia) o dominios concretos antes de ejecutar la solicitud, y esto reduce la factura sin cambiar la tarifa del canal.
¿Por qué distintos proveedores dan un consumo diferente en la misma tarea?
Por lo general la diferencia no está en la tarifa, sino en la estabilidad del nodo: un proveedor con cortes frecuentes de sesión obliga al script a volver a pedir las páginas, y a la factura se suma el tráfico de los intentos fallidos, que no existiría en un canal estable.
Las tarifas residenciales y móviles por tráfico están en el catálogo de proxies. Si tu tarea no requiere que la dirección tenga origen doméstico, un canal de centro de datos con precio mensual fijo sale más barato; el análisis está en el artículo proxies de centro de datos: cuándo son suficientes.