Los Mbps no dicen nada sobre la calidad de un proxy móvil

La escena te resulta familiar. Compraste un proxy más rápido, pagaste por un canal de 50 Mbps, configuraste el navegador antidetect. Y aun así los perfiles se caen sin motivo, el parser atrapa timeouts por montones y los captchas aparecen donde antes no estaban. Vas con el vendedor a reclamar. En respuesta te envía una captura de un test de velocidad donde todo se ve verde y bonito: el ancho de banda está ahí, la velocidad es excelente. Formalmente tiene razón. En la práctica, tu tarea no funciona.

Entonces, ¿cuál es el problema? El problema es que estabas midiendo lo incorrecto. Los megabits por segundo describen solo una característica del canal: su capacidad de transmisión. Pero la calidad de un proxy móvil se define por otras métricas completamente diferentes. Y ninguna prueba de velocidad en el navegador las muestra. En este artículo, analizaremos qué es lo que realmente rompe tu flujo de trabajo y aprenderemos a medirlo correctamente: con un script, no a simple vista.

Lo que realmente rompe el trabajo

Cuando hablamos de calidad de conexión, casi siempre reducimos todo a un solo número: la velocidad. Es conveniente, pero categóricamente incorrecto. Detrás de una operación estable de proxy hay cuatro variables independientes, y cada una es responsable de una clase de problemas. El ancho de banda es solo una de ellas, y ni siquiera la más importante para la mayoría de las tareas.

Analicemos cada una en orden. Y veremos de inmediato a qué es sensible cada una.

Cuatro variables en lugar de una

RTT es el tiempo que tarda un paquete en llegar al servidor y volver. El RTT determina qué tan receptiva se siente la interfaz. Con un RTT alto, cada acción en el navegador se arrastra, cada captcha carga con retraso y los timeouts en el parser se activan antes de que llegue la respuesta. El ancho de banda puede ser enorme. De nada sirve.

El jitter es la variación de los valores de RTT a lo largo del tiempo. Si la latencia salta de 40 a 300 milisegundos, el comportamiento de la conexión se vuelve impredecible. Las sesiones se rompen en operaciones largas, y los sistemas de análisis de comportamiento detectan una irregularidad antinatural en los patrones de solicitudes. Un canal estable de 15 Mbps con bajo jitter se comporta mucho más limpio que uno inestable de 50.

Pérdida de paquetes: el porcentaje de datos que no llegaron y requirieron reenvío. Incluso un 2-3 por ciento de pérdida convierte una descarga larga en una lotería. El archivo se descarga a medias, la respuesta llega corrupta y una solicitud POST larga se interrumpe a la mitad. Para el scraping de grandes volúmenes, esto es crítico.

Ruta: el camino que sigue el tráfico. Nodos innecesarios, bucles a través de centros de datos lejanos, caer en un sistema autónomo equivocado: todo esto añade latencia y arruina la geolocalización. Un proxy móvil que físicamente no está donde dice estar, se delata fácilmente por su ruta.

La idea clave de toda esta sección es simple. El ancho de banda solo importa al subir contenido multimedia—cuando descargas archivos grandes o transmites video. Todo lo demás—trabajo con antidetect, scraping, automatización de acciones—se trata de estabilidad, no de velocidad. Y la estabilidad reside en esas otras tres variables que el test de velocidad ignora.

Por qué el test de velocidad en el navegador es inútil

Ahora hablemos de la herramienta principal en la que todos confían. El test de velocidad del navegador te da un número en un momento específico. Abre una conexión, descarga un bloque de datos de prueba, mide la velocidad máxima y muestra una flecha bonita. Una medición—un segundo de un día entero.

Ahora recuerda la naturaleza de la red móvil. Es inconstante por definición. Esto es lo que le sucede durante el día:

• Sobrecarga de la celda. Cuando muchos suscriptores se conectan a la estación base simultáneamente, los recursos se dividen entre todos. Tu latencia real aumenta, aunque la velocidad máxima en el momento de la medición pueda seguir siendo alta.
• Cambio de banda de frecuencia. El operador mueve el dispositivo entre bandas de frecuencia según la carga y la intensidad de la señal. Cada cambio es un micro-corte, un pico de jitter y, a veces, pérdida de paquetes.
• Limitación programada. Durante las horas pico, los operadores aplican gestión de tráfico. El ancho de banda está formalmente ahí, pero las prioridades cambian y la latencia fluctúa.

¿Ves el truco? Un test de velocidad ejecutado a las 14:00 te mostrará una imagen perfecta. Pero tu parser fallará a las 21:00, cuando la celda está sobrecargada por el tráfico nocturno. El vendedor mostrará su captura diurna y técnicamente tendrá razón. Una sola medición describe un segundo—y no dice nada sobre cómo se comporta el canal los otros 86,399 segundos del día.

La conclusión es obvia. Para entender la calidad real de un proxy móvil, necesitas medir continuamente y medir las variables correctas. Con un clic en el navegador no se hace eso.

Método: medir con script, no a simple vista

Ya que la medición manual no funciona, automatizamos el proceso. La idea es simple: un pequeño script se ejecuta según un horario, recopila todas las métricas necesarias y las guarda en un archivo. Después de un día, tienes una imagen completa del comportamiento del canal—no una instantánea al azar.

Para esto, es útil usar SpeedMeter—una utilidad de consola que mide no solo el ancho de banda, sino también RTT, jitter y pérdida de paquetes, dando el resultado en un formato legible por máquina. Es exactamente una herramienta, no un tema de conversación: simplemente hace su trabajo y calla.

Paso 1. Instalación del CLI

La utilidad se distribuye como un solo binario sin dependencias. Lo descargas, lo haces ejecutable, lo pones en el PATH. Verificación de funcionamiento—con un solo comando.

curl -sL https://speedmeter.dev/cli -o speedmeter && chmod +x speedmeter && sudo mv speedmeter /usr/local/bin/ && speedmeter --version

Sin bibliotecas, intérpretes ni entornos virtuales. El binario pesa alrededor de 400 kilobytes y se ejecuta en cualquier host Linux, VPS, o incluso en un router con suficiente memoria.

Paso 2. Ejecución con salida JSON y acumulación en archivo

El flag --json convierte la salida en una estructura fácil de analizar. Añadimos el resultado a un archivo con la marca de tiempo—ese es nuestro acumulador de métricas.

speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl

Cada ejecución añade una línea JSON. El formato JSONL (una entrada por línea) es ideal para el análisis posterior—cualquier herramienta puede leerlo.

Paso 3. Cron cada 15 minutos

Configuramos la tarea en el horario. Cada 15 minutos—son 96 mediciones al día, una densidad suficiente para ver todas las caídas y picos.

*/15 * * * * /usr/local/bin/speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl 2>&1

Y para un análisis rápido de lo acumulado, usamos jq. Así es como se calcula el RTT promedio y el jitter máximo en un segundo:

jq -s 'map(.rtt_ms) | add/length' /var/log/proxy_metrics.jsonljq -s 'map(.jitter_ms) | max' /var/log/proxy_metrics.jsonl

Listo. Tres bloques cortos de código—y tienes un monitoreo funcional de la calidad del canal. Ahora hablemos de lo que este monitoreo mostrará.

Experimento: un día completo en una sola SIM

Para demostrar claramente la diferencia entre ancho de banda y calidad, montamos un experimento simple. Las condiciones eran extremadamente limpias y reproducibles:

• Una tarjeta SIM, un operador móvil.
• Medición cada 15 minutos mediante cron.
• 96 puntos de datos en un día completo.
• Registramos ancho de banda, RTT, jitter y pérdida de paquetes sincrónicamente.

La hipótesis era la siguiente: esperábamos ver una caída de calidad por la noche entre las 19:00 y las 23:00, cuando la red está cargada por el tráfico doméstico. Y que la caída fuera principalmente en el jitter, no en el ancho de banda.

Qué mostró el gráfico

A continuación, la imagen promedio de RTT y jitter por hora del día. Observa la forma de las curvas.

Jitter (ms) por hora del día:00 |#### 12 ms03 |###9 ms06 |#### 13 ms09 |###### 22 ms12 |####### 26 ms15 |######## 31 ms18 |########### 48 ms19 |################ 71 ms20 |################### 95 ms21 |#################### 110 ms22 |################ 74 ms23 |########### 49 msRTT (ms) por hora del día:00 |#### 45 ms09 |###### 68 ms15 |######## 92 ms20 |############ 140 ms21 |############### 175 ms23 |####### 85 ms

La imagen habla por sí sola. Por la noche y temprano en la mañana, el canal se comportaba perfectamente: RTT alrededor de 45 milisegundos, jitter por debajo de 15. Pero a partir de las 19:00 comenzaba un aumento rápido. Hacia las 21:00, el jitter crecía casi diez veces en comparación con el mínimo nocturno, y el RTT casi se triplicaba.

Y aquí está lo más interesante. El ancho de banda durante esa misma ventana nocturna seguía siendo bastante decente: la caída era pequeña y completamente imperceptible a simple vista. Un test de velocidad a las 21:00 habría mostrado casi los mismos megabits que al mediodía. Nunca habrías sospechado que el canal se estaba desmoronando en ese momento.

La conclusión del experimento es inequívoca. Es precisamente en la ventana nocturna donde tus tareas fallan: las sesiones de antidetect se rompen, los timeouts del parser se activan, las huellas de comportamiento se vuelven irregulares. Y esto es exactamente lo que el test de velocidad del navegador no ve, porque solo mira el ancho de banda y solo en un momento. Y tus tareas, como era de esperar, a menudo se ejecutan precisamente por la noche.

Valor práctico del hallazgo

Tan pronto como veas este gráfico para tu proxy, obtendrás un conocimiento concreto. Por ejemplo:

• El scraping pesado es mejor ejecutarlo de noche, cuando el jitter es mínimo.
• El calentamiento de múltiples cuentas tiene sentido moverlo a las horas de la mañana.
• Si la caída nocturna es demasiado profunda, vale la pena cambiar de proveedor o nodo—y ahora tienes números para una conversación fundamentada.

Umbrales: qué valores son aceptables para tu tarea

El gráfico está bien, pero necesitas una vara de medir. A continuación, una tabla de umbrales con la que puedes verificar a tu proveedor tú mismo. Simplemente compara los valores promedio de tu registro de métricas con estas cifras y entenderás de inmediato si el canal es adecuado para tu tarea específica.

Analicemos la lógica de estos umbrales para que entiendas de dónde vienen los números.

Scraping y extracción

Aquí lo más importante es la baja pérdida de paquetes y un RTT predecible. Las solicitudes largas y los recorridos página por página son sensibles a las interrupciones. El ancho de banda casi no importa—estás descargando texto y HTML, no terabytes. Un proxy de 5 Mbps será suficiente si el jitter se mantiene dentro de lo normal.

Multi-cuentas

La tarea más exigente en cuanto a jitter. Cada cuenta debe comportarse como un usuario real desde una única conexión móvil estable. Un jitter irregular delata la automatización y arruina el perfil de comportamiento. Por eso, los umbrales aquí son los más estrictos en cuanto a estabilidad, y los más flexibles en cuanto a ancho de banda.

Automatización SMM

Publicaciones, comentarios, reacciones—todas son acciones interactivas cortas. Un RTT bajo garantiza la capacidad de respuesta, y un jitter bajo garantiza la naturalidad. El ancho de banda es moderado, principalmente para subir imágenes a las publicaciones.

Trabajo con video

La única tarea de la lista donde el ancho de banda es realmente crítico. Aquí elevamos los requisitos de capacidad a 25 Mbps o más. Sin embargo, las tolerancias para jitter y pérdidas son un poco más flexibles—el buffer suaviza las pequeñas irregularidades.

Cinco formas prácticas de usar SpeedMeter

Ahora que el método está claro, mostramos escenarios concretos donde la medición regular de métricas ahorra tiempo, dinero y dolores de cabeza. Cada forma es una receta lista.

Forma 1. Aceptación del proxy antes de comprar

Para quién: para todos los que compran o alquilan proxies móviles. Para qué: para no pagar por una prueba de velocidad bonita, sino obtener calidad real.

El algoritmo es simple. Pide al vendedor un acceso de prueba por un día. Configura un cron para medir cada 15 minutos. Después de un día, calcula el jitter promedio y máximo, el RTT promedio y el porcentaje de pérdida. Compáralo con la tabla de umbrales anterior.

1. Obtienes las credenciales de prueba.
2. Ejecutas la tarea cron durante 24 horas.
3. Analizas el registro con jq: RTT promedio, pico de jitter, pérdidas.
4. Comparas con los umbrales para tu tarea.
5. Tomas una decisión basada en números, no en promesas.

Resultado de la práctica: en una prueba, el vendedor mostraba 48 Mbps. La medición de un día reveló un jitter nocturno de hasta 130 ms y un 4 por ciento de pérdidas. Para multi-cuentas, el canal era completamente inadecuado, aunque el ancho de banda se veía genial. Negarse a comprar ahorró un mes de pago y un montón de perfiles caídos.

Forma 2. Planificación de ventanas para tareas pesadas

Para quién: para aquellos que ejecutan scraping de gran volumen o calentamiento masivo de cuentas. Para qué: para ejecutar cargas cuando el canal está en su mejor forma.

Recopilas el perfil de calidad diario usando el método del experimento. Encuentras las ventanas verdes en el gráfico—generalmente de noche y temprano en la mañana. Configuras el programador de tareas para que los trabajos más pesados comiencen precisamente en esas horas.

• Ejecutar el parser de noche en lugar de por la tarde reduce drásticamente la proporción de timeouts.
• Calentar multi-cuentas por la mañana produce huellas de comportamiento más limpias.
• Las subidas que consumen muchos recursos van a las horas más tranquilas del día.

Truco: si tienes varios proxies de diferentes operadores, captura el perfil de cada uno. La caída nocturna ocurre en diferentes momentos para diferentes operadores—puedes alternar canales y mantener la estabilidad las 24 horas.

Forma 3. Monitoreo constante y alertas

Para quién: para equipos donde los proxies son parte de la infraestructura de producción. Para qué: para enterarse de la degradación del canal antes de que las tareas fallen.

El cron ya escribe métricas en JSONL. Añade un vigilante simple que lea la última entrada y la compare con el umbral. Si el jitter o las pérdidas superan el límite, enviamos una notificación al mensajero.

tail -n1 /var/log/proxy_metrics.jsonl | jq 'if .jitter_ms > 60 or .loss_pct > 2 then "ALERT" else "OK" end'

Esta verificación también la pones en cron—y obtienes una advertencia temprana. Cuando el canal comienza a degradarse, lo sabes en minutos, no después del hecho por las tareas caídas.

Consejo de experto: guarda los registros históricos durante al menos un mes. Son invaluables en una discusión con el proveedor—tienes la dinámica objetiva en tus manos, no emociones.

Forma 4. Comparación justa de proveedores

Para quién: para quienes eligen entre varias ofertas. Para qué: para comparar con una misma metodología, no con capturas ajenas.

Toma acceso de prueba de tres o cuatro candidatos. Ejecuta la misma medición para cada uno durante los mismos días. Resume los resultados en una tabla y compara las cuatro variables a la vez.

1. Metodología única—el mismo intervalo, las mismas métricas.
2. Mismo intervalo de tiempo—eliminamos la influencia de la hora del día.
3. Comparación por jitter y pérdidas, no solo por ancho de banda.

Resultado: a menudo, el canal más caro con el mayor ancho de banda pierde frente a uno más barato en estabilidad. Una comparación justa ahorra presupuesto y aumenta la tasa de éxito de las tareas.

Forma 5. Diagnóstico de una conexión problemática

Para quién: para todos aquellos a quienes algo se les ha caído y no entienden por qué. Para qué: para saber en minutos si el canal es el culpable o no.

Cuando una tarea comienza a fallar, la primera pregunta es si el problema es el proxy. Ejecuta una medición puntual ahora mismo y observa el perfil. ¿RTT alto? Busca el problema en la ruta. ¿Jitter fluctuante? La celda está sobrecargada. ¿Pérdidas en aumento? Posiblemente señal débil o limitación.

• Aumento repentino de RTT con jitter normal—probablemente cambió la ruta.
• RTT normal, pero jitter enorme—sobrecarga de la celda o cambio de banda.
• Alta pérdida de paquetes—señal débil, interferencia o gestión de tráfico.

Este diagnóstico rápido ahorra horas. En lugar de adivinar, obtienes una dirección de búsqueda con un solo comando.

Comparación con alternativas

La pregunta lógica: ¿por qué una utilidad separada si existen herramientas conocidas? Comparemos honestamente los enfoques.

La diferencia clave es que SpeedMeter mide las cuatro variables a la vez y entrega el resultado en un formato legible por máquina. Esto lo hace adecuado para la automatización desde el primer momento. No necesitas combinar tres herramientas diferentes y unir sus salidas con scripts—un solo comando cubre todo.

Además, no intenta ser una navaja suiza. Nada de paneles, bases de datos ni agentes. Un pequeño binario sin dependencias que puedes colocar en cualquier lugar y ejecutar como quieras. Es precisamente esta concisión lo que lo convierte en una herramienta cómoda, no en otra plataforma pesada.

Errores típicos al evaluar la calidad del proxy

Hemos recopilado los rastrillos en los que la gente pisa más a menudo. Revisa si tú también.

• Centrarse solo en el ancho de banda. El error más común. Los megabits son fascinantes, pero solo importan al trabajar con medios.
• Una sola medición. Una verificación en un momento conveniente del día miente. Hay que medir las 24 horas.
• Ignorar el jitter. Es precisamente el jitter el que más a menudo mata las cuentas múltiples y rompe las sesiones. Y todos se olvidan de él.
• Confiar en capturas ajenas. El test de velocidad del vendedor es su mejor segundo. Mide tú mismo.
• Falta de historial. Sin registros, no puedes demostrar la degradación ni planificar ventanas.
• Medir en el vacío. Verifica el canal usando el mismo protocolo que usarás en tu tarea.

FAQ: preguntas prácticas

¿Cuál es la diferencia entre jitter y RTT en palabras simples?

El RTT es la latencia promedio, mientras que el jitter es su variación. Puedes tener un RTT bajo pero un jitter alto: en promedio rápido, pero irregular e impredecible. Es precisamente la irregularidad lo que daña las sesiones estables.

¿Por qué un proxy de 15 Mbps a veces es mejor que uno de 50?

Porque 15 Mbps pueden venir con bajo jitter y pérdidas mínimas, mientras que 50 pueden tener picos nocturnos e interrupciones. Para scraping y multi-cuentas, la estabilidad es más importante que la velocidad máxima.

¿Con qué frecuencia debo medir las métricas?

Cada 15 minutos es un buen equilibrio. Son 96 puntos al día, suficiente para ver todos los picos. Para monitoreo de producción, puedes hacerlo más seguido; para la aceptación de un proxy, 15 minutos es más que suficiente.

¿Se necesitan privilegios de administrador para la instalación?

Solo para colocar el binario en el PATH del sistema. Puedes prescindir de eso—ejecutarlo desde una carpeta local. La utilidad no requiere privilegios para las mediciones en sí.

¿Cuánto espacio ocupan los registros de métricas?

Una entrada JSONL son unos pocos cientos de bytes. En un día con medición cada 15 minutos, se acumulan unos 30-50 kilobytes. Un registro mensual ocupa unos pocos megabytes. Puedes almacenarlo durante mucho tiempo.

¿Puedo medir varios proxies a la vez?

Sí. Crea una tarea cron separada y un archivo de registro separado para cada proxy. Luego compara los perfiles. Esto es conveniente para alternar canales y comparar proveedores de manera justa.

¿Qué hago si el jitter es constantemente alto las 24 horas?

Es una señal de un problema sistémico: celda sobrecargada, equipo deficiente del proveedor o una ruta desfavorable. Recopila un registro de un día y discute con el proveedor el cambio de nodo basándote en los números.

¿Funciona la utilidad en un router o mini-PC?

Sí, si hay suficiente memoria. El binario es diminuto y sin dependencias, por lo que es adecuado para hosts de baja potencia. Muchos lo instalan justo al lado del equipo del módem.

¿Cómo saber si el problema es la ruta y no la celda?

Observa el carácter de las métricas. Un RTT constantemente alto con jitter bajo generalmente indica una ruta larga o subóptima. Un jitter fluctuante con un RTT promedio normal suele indicar sobrecarga de la celda.

¿Es obligatorio saber usar jq?

No. La salida JSON se puede leer con cualquier herramienta, y los comandos básicos de jq del artículo se pueden copiar y adaptar. Incluso sin conocimientos profundos, obtendrás los valores promedio y los picos en un minuto.

Conclusiones: para quién es esto y cómo empezar

Resumamos. Los megabits por segundo son una de cuatro variables, y para la mayoría de las tareas no es la principal. La calidad real de un proxy móvil vive en el RTT, el jitter, la pérdida de paquetes y la ruta. Y el test de velocidad del navegador no ve ninguna de las tres últimas variables y mide solo un segundo del día.

El enfoque correcto es medir con script, las 24 horas, según un horario. Entonces verás la caída nocturna de calidad, encontrarás ventanas verdes para tareas pesadas, compararás proveedores de manera justa y obtendrás números para una conversación fundamentada. Esto es lo que cambia la situación de conjeturas a hechos.

¿Para quién es esto? Para todos los que trabajan seriamente con proxies móviles: scrapers, especialistas en multi-cuentas, equipos de SMM y aquellos que construyen automatización sobre infraestructura de proxy. Empezar no podría ser más fácil: descarga el binario, configura el cron, recopila un día de métricas, compáralo con la tabla de umbrales.

La herramienta es abierta y gratuita. Un binario de 400 kilobytes sin dependencias—instálalo y olvídalo. Por cierto, nosotros mismos medimos nuestros canales con esta misma utilidad y publicamos las métricas abiertamente. Porque creemos que la calidad del proxy debe demostrarse con números, no con capturas bonitas. Mide tu proxy hoy—y te sorprenderá lo diferente que es la imagen en comparación con lo que mostraba el test de velocidad.