Estás ejecutando un parser o calentando cuentas a través de un proxy, estimas el consumo según el tamaño de las páginas y recibes una factura 2-3 veces mayor de lo esperado. No se trata de un engaño por parte del proveedor: el tráfico incluye todo lo que realmente ha pasado por el canal: encabezados de solicitudes, apretón de manos TLS, reintentos de conexión y paquetes de control. Analizamos de qué se compone el "cheque" por el tráfico y cómo reducir el consumo sin perder calidad en el trabajo.
Lo que el proveedor realmente considera tráfico
Cuando evalúas el consumo "a ojo", generalmente tienes en mente la fórmula: tamaño de la página HTML más imágenes. Pero el proveedor de proxy considera el volumen total de datos que ha pasado por ambas direcciones del canal: saliente (solicitud) y entrante (respuesta). Este volumen incluye no solo la carga útil, sino también todo el tráfico de control: encabezados de protocolo, metadatos TLS, paquetes ACK TCP, reintentos de conexión en caso de timeouts.
Para una solicitud a una página normal, la relación de "datos útiles" a "datos de control" puede ser 80/20. Pero si trabajas con APIs, donde las respuestas son pequeñas (unos pocos kilobytes de JSON) y hay muchos encabezados y apretón de manos, la relación puede invertirse fácilmente. Es por eso que los arbitrajistas que realizan decenas de miles de pequeñas solicitudes a APIs publicitarias o marketplaces a menudo se sorprenden por la factura: cada solicitud lleva un "impuesto" fijo independientemente del tamaño de la carga útil.
Otro punto importante: el proveedor calcula el tráfico a nivel del servidor proxy, es decir, todo el tráfico que realmente ha pasado por la IP, incluyendo intentos fallidos, redirecciones, y recargas de recursos en la página (estilos, scripts, rastreadores) que tu script o navegador solicitó automáticamente, incluso si solo necesitabas el texto.
Encabezados HTTP/HTTPS: el peso oculto de cada solicitud
Cada solicitud HTTP y cada respuesta llevan un conjunto de encabezados: User-Agent, Cookie, Accept-Language, Referer, Content-Type y decenas de otros. En los navegadores modernos y herramientas anti-detección (Dolphin Anty, AdsPower, Multilogin), el conjunto de encabezados puede ocupar de 500 bytes a 2-3 KB por solicitud, especialmente si en las cookies se ha acumulado una sesión con decenas de valores.
Ejemplo: si haces 10,000 solicitudes a la API de un marketplace con cookies de sesión de 1.5 KB, solo para los encabezados se irán alrededor de 15 MB de tráfico, y esto sin contar el cuerpo de la respuesta. Al escalar a varias cuentas y perfiles, esta cifra crece linealmente.
| Tipo de encabezado | Tamaño promedio | Impacto en el tráfico |
|---|---|---|
| User-Agent | 100-150 bytes | Bajo, pero se acumula a gran escala |
| Cookie (sesión) | 500-2000 bytes | Alto en sesiones largas |
| Referer / Origin | 50-200 bytes | Bajo |
| Encabezados Accept-* | 150-300 bytes | Bajo |
| Encabezados de respuesta del servidor | 300-800 bytes | Promedio, no depende de ti |
Conclusión práctica: si estás escribiendo un script para monitorear precios en Wildberries o Ozon, limpia las cookies de valores no utilizados y no arrastres en la solicitud encabezados innecesarios que hayas copiado "por si acaso" desde DevTools del navegador.
Apretón de manos TLS: cuánto tráfico consume la encriptación
Prácticamente toda la web moderna funciona a través de HTTPS, lo que significa que cada nueva conexión comienza con un apretón de manos TLS: el intercambio de certificados, claves de encriptación y parámetros del protocolo. Un apretón de manos TLS completo (TLS 1.2 o 1.3) pesa entre 4 y 8 KB dependiendo del tamaño del certificado del sitio y de las extensiones del protocolo utilizadas.
Si abres una nueva conexión para cada solicitud (y no utilizas una conexión persistente), el apretón de manos TLS se repite cada vez. Con 10,000 solicitudes sin reutilizar la conexión, obtendrás 40-80 MB adicionales de tráfico solo para la encriptación, lo que puede ser más que el contenido útil en sí.
TLS 1.3 es un poco más ligero que TLS 1.2 debido a la reducción en el número de round-trips, pero la diferencia es notable solo con un gran número de conexiones. Para proxies móviles, donde la propia red del operador añade su latencia y reinstalaciones de sesiones, el overhead de TLS se siente especialmente notable; esto debe tenerse en cuenta al elegir proxies móviles para tareas con solicitudes cortas frecuentes.
Reintentos: cómo las solicitudes repetidas duplican el consumo
Los reintentos son el artículo de gasto de tráfico más imperceptible y más costoso. Si tu parser o script está configurado para reintentar automáticamente en caso de timeout o error 429/503, cada solicitud fallida ya ha consumido tráfico para establecer la conexión, el apretón de manos TLS y los encabezados, y luego todo este proceso se repite de nuevo.
Un error común en la automatización de SMM y el scraping de marketplaces es una política agresiva de reintentos sin un retraso exponencial: el script hace 5 intentos seguidos con un intervalo de un segundo ante el primer signo de bloqueo de IP. Como resultado, para una respuesta "útil" se consume el tráfico de cinco intentos fallidos más la solicitud exitosa final.
Esto es especialmente crítico al trabajar con proxies de centros de datos en sitios con protección agresiva (por ejemplo, Avito o grandes marketplaces), que pueden devolver un captcha o bloquear la mayoría de las solicitudes desde una IP "caliente". En este caso, tiene sentido considerar proxies residenciales, ya que son menos propensos a ser bloqueados desde la primera solicitud, lo que reduce el número de reintentos y, por lo tanto, el consumo real de tráfico.
Keep-Alive vs nuevas conexiones
HTTP Keep-Alive permite reutilizar una sola conexión TCP/TLS para varias solicitudes consecutivas, evitando el apretón de manos repetido. Esta es una de las optimizaciones de tráfico más efectivas, disponible en casi todos los clientes HTTP y navegadores anti-detección.
Si utilizas bibliotecas para scraping (requests, httpx, axios) sin especificar explícitamente una sesión con conexión persistente, cada solicitud por defecto puede abrir una nueva conexión TCP. En combinación con proxies, esto significa: nueva conexión hasta el servidor proxy, nuevo TLS hasta el sitio objetivo, y todo el overhead se repite en cada llamada.
| Modo de conexión | Overhead en 1000 solicitudes |
|---|---|
| Nueva conexión para cada solicitud | 4-8 MB (solo TLS) |
| Keep-Alive, una sesión para 50 solicitudes | 0.1-0.2 MB (un apretón de manos por grupo) |
La diferencia es enorme, y esto es un ahorro puro de tráfico sin ningún cambio en la carga útil de las solicitudes.
Cómo diferentes tipos de proxy calculan el tráfico
El modelo de facturación del tráfico depende del tipo de proxy. En los proxies de centros de datos, es más común encontrar tarifas basadas en el volumen de tráfico o en la cantidad de IP/puertos, ya que la infraestructura es más rápida y añade un overhead mínimo en la ruta. En los proxies residenciales y móviles, el tráfico generalmente se factura de manera más estricta, porque las IP reales de los usuarios son un recurso más caro y limitado, y la ruta a través del operador o proveedor doméstico añade saltos adicionales y, por lo tanto, un poco más de datos de control.
Los proxies móviles son en este sentido los más "costosos" en tráfico: las redes celulares añaden sus propios mecanismos de reinstalación de sesiones, traducción NAT y a veces compresión/descompresión de tráfico a nivel de operador, lo que aumenta el contador de datos transmitidos en comparación con la misma solicitud a través de una red fija.
Si la tarea es un alto volumen estable de solicitudes con un overhead mínimo (por ejemplo, scraping masivo de precios en Wildberries o Ozon), los proxies de centros de datos son más adecuados, ya que son más rápidos y predecibles en el consumo de tráfico para tareas homogéneas.
Cómo reducir el consumo de tráfico en la práctica
Analicemos pasos concretos que reducen el consumo real de tráfico sin perder funcionalidad en el parser, la automatización o el multi-cuentas.
1. Desactiva la carga de recursos innecesarios. Si solo necesitas el texto de la página o la respuesta JSON de la API, desactiva la carga de imágenes, fuentes, scripts analíticos y rastreadores publicitarios en la configuración del navegador anti-detección o herramienta sin cabeza. Esto a menudo reduce el consumo de tráfico en un 60-80% para tareas de scraping.
2. Utiliza Keep-Alive y un pool de conexiones. Configura el cliente HTTP para reutilizar la sesión para un grupo de solicitudes a un mismo host; esto reduce drásticamente el número de apretón de manos TLS.
3. Configura una política razonable de reintentos. Un retraso exponencial (1s → 2s → 4s) con un límite de 3 intentos en lugar de agresivos 5-10 intentos consecutivos reduce el tráfico innecesario de solicitudes fallidas y al mismo tiempo disminuye el riesgo de un bloqueo adicional de IP.
4. Limpia las cookies y encabezados de sesión. Periódicamente elimina los valores acumulados de cookies que no son utilizados por el sitio objetivo, especialmente relevante para sesiones largas de calentamiento de cuentas en Instagram o TikTok a través de navegadores anti-detección.
5. Almacena en caché respuestas estáticas. Si los datos (por ejemplo, el catálogo de productos) no cambian cada minuto, almacena la respuesta localmente en lugar de hacer una nueva solicitud a través del proxy en cada ciclo de monitoreo.
6. Utiliza compresión. Asegúrate de que el encabezado Accept-Encoding: gzip se envía y que el servidor realmente devuelve una respuesta comprimida; esto reduce el volumen de tráfico entrante en páginas con mucho texto o JSON.
Herramientas para monitorear el tráfico
Para entender a dónde se va realmente el tráfico, es útil observar no solo el contador del proveedor, sino también el desglose detallado de las solicitudes. Para esto son útiles:
- Charles Proxy / Fiddler — muestran el tamaño de cada solicitud y respuesta, incluidos los encabezados, lo que ayuda a encontrar cookies "pesadas" o recursos innecesarios.
- Wireshark — para un análisis profundo del overhead TCP/TLS a nivel de paquetes, si necesitas evaluar el peso real del apretón de manos.
- Contadores de tráfico integrados en navegadores anti-detección (Dolphin Anty, AdsPower, GoLogin) — muchos muestran el consumo por cada perfil por separado, lo que es conveniente para distribuir el presupuesto entre cuentas.
- Registro a nivel de cliente HTTP — al escribir tus propios scripts de scraping, es útil registrar el tamaño de la solicitud/respuesta para cada llamada, para identificar anomalías.
Comparar las lecturas de tus herramientas con el contador del proveedor de proxy ayuda a entender rápidamente dónde se pierde tráfico: en reintentos, TLS o carga de recursos innecesarios.
Lista de verificación de optimización antes del lanzamiento
Antes de un lanzamiento masivo del parser, automatización de SMM o calentamiento de cuentas publicitarias, revisa esta breve lista:
- Desactivada la carga de imágenes, fuentes, analíticas donde no son necesarias;
- Configurado Keep-Alive / reutilización de sesión para una serie de solicitudes a un mismo host;
- La política de reintentos limitada a 2-3 intentos con retraso, en lugar de repeticiones infinitas;
- Las cookies de sesión limpiadas periódicamente de valores no utilizados;
- Compresión de respuestas habilitada (gzip/deflate/br);
- Cache local para solicitudes estáticas repetidas;
- Tipo de proxy seleccionado según la tarea: centro de datos para velocidad y volumen, residenciales para evitar bloqueos, móviles para redes sociales y plataformas publicitarias.
Conclusión
El consumo de tráfico a través de proxies no son solo los datos útiles de la página, sino también todo el overhead de control: encabezados, apretón de manos TLS, reintentos en caso de errores. Comprender esta mecánica permite planificar mejor el presupuesto para proxies y evitar sorpresas desagradables en la factura, especialmente al escalar el scraping de marketplaces, la automatización de SMM o el calentamiento de cuentas publicitarias.
Si tu tarea es un scraping estable con un consumo de tráfico predecible, considera los proxies de centros de datos. Para trabajar con redes sociales y plataformas publicitarias, donde la baja frecuencia de bloqueos es importante, los proxies móviles son más adecuados. Y si necesitas un equilibrio entre anonimato y estabilidad para sortear la protección de sitios, considera los proxies residenciales, que reducen el número de reintentos gracias a bloqueos menos frecuentes.