Tomamos 5964 mediciones en redes móviles y observamos cómo se comporta el canal a lo largo de las horas del día. Resulta que la cifra que todos usan para elegir un proxy sube justo cuando trabajar se vuelve más difícil.

Por qué los megabits no describen en absoluto la calidad del canal, lo analizamos en el artículo «Los Mbit/s no dicen nada sobre la calidad de un proxy móvil». Aquí está la misma idea, pero con datos: cómo se comportan la latencia, el jitter y las pérdidas a lo largo de las horas del día.

Un panorama conocido

Compras un proxy más rápido, pero el antidetect igual cierra tus sesiones, el parser llena de timeouts y las descargas se cortan a la mitad. Abres el test de velocidad y ves cuarenta megabits, todo en orden. El vendedor se encoge de hombros: el canal está bien, míralo tú mismo.

El canal realmente está bien según la magnitud que mediste. El problema es que no mediste lo correcto.

Lo que realmente arruina tu trabajo

El ancho de banda resuelve exactamente un problema: qué tan rápido se descarga un archivo grande. Todo lo demás — abrir páginas, mantener sesiones, resolver captchas, consultas largas del parser — depende de otras magnitudes.

MagnitudDe qué se encarga
Latencia (ping)Capacidad de respuesta de la interfaz, activación de timeouts
JitterVariación de la latencia. Rompe conexiones largas y websockets
Pérdida de paquetesInterrupciones de solicitudes, descargas corruptas, reintentos
RutaHops extra, caer en un sistema autónomo ajeno

La red móvil no se diferencia de la cableada por ser más lenta. Es inestable: la celda se satura por la noche, el operador cambia de bandas, el shaping se activa según horario. Una sola medición en el navegador describe un segundo del día — y normalmente el segundo en el que decidiste revisar.

Cómo se ve esto en los datos

Recopilamos mediciones realizadas a través de las redes de MTS durante diez meses y las promediamos por hora del día. Tres magnitudes en tres escalas distintas — deliberadamente separadas: combinarlas en un solo eje sería ajustar la imagen a conveniencia.

Tomamos 5964 mediciones en redes móviles y observamos cómo se comporta el canal a lo largo de las horas del día. Resulta que la cifra que todos usan para elegir...

De arriba hacia abajo: velocidad de descarga (Mbit/s), jitter (ms), pérdida de paquetes (%). 5964 mediciones en redes MTS, septiembre de 2025 — agosto de 2026. Cada punto es el promedio de una hora, con 72 a 388 mediciones por hora. El intervalo nocturno de 18:00 a 23:00 está resaltado en naranja; ×3,4 y ×6,8 indican cuántas veces crece la magnitud hacia la noche. Los puntos marcan el mínimo y el máximo diario.

Lo principal en este gráfico

La velocidad casi no cambia. Desde las siete de la mañana hasta la medianoche se mantiene en un rango de 54 a 68 Mbit/s. Una persona que ejecute un test de velocidad a cualquier hora del día verá más o menos el mismo número y concluirá que el canal está bien.

El jitter, en el mismo periodo, crece 3,4 veces — de 25 ms a las ocho de la mañana a 86 ms a las once de la noche. La pérdida de paquetes crece 6,8 veces: de 0,79% durante el día a 5,37% cerca de la madrugada.

Y la coincidencia más desagradable: a las 20:00 la velocidad alcanza su máximo diario — 68 Mbit/s — mientras que el jitter a esa misma hora es de 64 ms, dos veces y media más que por la mañana. El test de velocidad en ese momento muestra el mejor resultado del día. Trabajar en ese momento es lo peor que puedes hacer.

Por eso las quejas del tipo «por la noche todo va lento, pero el test muestra velocidad normal» no son invento ni efecto placebo. El test mide la magnitud que no se deteriora por la noche.

Cómo medir correctamente

No necesitas una sola medición, sino una serie. Instala la CLI, prográmala y acumula los resultados en un archivo:

speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonl

En cron, cada quince minutos:

*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonl

En un día obtienes 96 puntos, y con ellos se ve de inmediato si tu canal tiene una caída nocturna. El binario es autónomo, de unos 400 KB, sin dependencias — se instala en cualquier servidor donde corra tu automatización.

Qué valores considerar aceptables

TareaJitterPérdidas
Parsing, scrapinghasta 30 mshasta 1%
Multi-cuentas, antidetecthasta 50 mshasta 2%
Automatización de SMMhasta 60 mshasta 2%
Video, llamadashasta 30 mshasta 1%

Nota que en esta tabla no hay nada: no hay una columna de megabits. Para las tareas mencionadas, el ancho de banda deja de ser una limitación a partir de unos diez megabits.

Datos por hora

Los mismos números del gráfico, para que puedas verificarlos o compararlos con tus propias mediciones.

HoraVelocidad, Mbit/sPing, msJitter, msPérdidas, %Mediciones
00:006613452.14.12140
01:006113556.84.99125
02:004216757.95.37113
03:003413560.82.6786
04:004313242.81.9472
05:004513140.82.5092
06:004211534.32.49131
07:005411139.82.48140
08:005711325.02.44210
09:005410844.21.57302
10:00648437.70.79309
11:00668934.61.06363
12:006010138.91.00388
13:006010029.11.80348
14:00619535.21.45340
15:006110040.11.83322
16:00669747.51.33356
17:00639547.11.06330
18:005910060.60.97348
19:00619848.91.02328
20:006811264.11.74368
21:005910457.62.53322
22:006211261.52.56266
23:005414986.13.86165

Aclaración sobre los datos

Esto es un promedio de muchos usuarios y muchas celdas, no de una sola SIM bajo control. Este corte muestra la forma de la curva diaria, pero no reemplaza la medición de tu canal específico — tienes que hacerla tú mismo con el script de arriba.

La herramienta con la que se recopilaron estos números es abierta y gratuita: speedmeter.dev. Mide el jitter y las pérdidas del lado del servidor, no confía en el informe del navegador, y devuelve el resultado en JSON para scripts.