Por qué el proxy móvil funciona peor por la noche mientras el test de velocidad muestra el máximo
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.
| Magnitud | De qué se encarga |
|---|---|
| Latencia (ping) | Capacidad de respuesta de la interfaz, activación de timeouts |
| Jitter | Variación de la latencia. Rompe conexiones largas y websockets |
| Pérdida de paquetes | Interrupciones de solicitudes, descargas corruptas, reintentos |
| Ruta | Hops 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.

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
| Tarea | Jitter | Pérdidas |
|---|---|---|
| Parsing, scraping | hasta 30 ms | hasta 1% |
| Multi-cuentas, antidetect | hasta 50 ms | hasta 2% |
| Automatización de SMM | hasta 60 ms | hasta 2% |
| Video, llamadas | hasta 30 ms | hasta 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.
| Hora | Velocidad, Mbit/s | Ping, ms | Jitter, ms | Pérdidas, % | Mediciones |
|---|---|---|---|---|---|
| 00:00 | 66 | 134 | 52.1 | 4.12 | 140 |
| 01:00 | 61 | 135 | 56.8 | 4.99 | 125 |
| 02:00 | 42 | 167 | 57.9 | 5.37 | 113 |
| 03:00 | 34 | 135 | 60.8 | 2.67 | 86 |
| 04:00 | 43 | 132 | 42.8 | 1.94 | 72 |
| 05:00 | 45 | 131 | 40.8 | 2.50 | 92 |
| 06:00 | 42 | 115 | 34.3 | 2.49 | 131 |
| 07:00 | 54 | 111 | 39.8 | 2.48 | 140 |
| 08:00 | 57 | 113 | 25.0 | 2.44 | 210 |
| 09:00 | 54 | 108 | 44.2 | 1.57 | 302 |
| 10:00 | 64 | 84 | 37.7 | 0.79 | 309 |
| 11:00 | 66 | 89 | 34.6 | 1.06 | 363 |
| 12:00 | 60 | 101 | 38.9 | 1.00 | 388 |
| 13:00 | 60 | 100 | 29.1 | 1.80 | 348 |
| 14:00 | 61 | 95 | 35.2 | 1.45 | 340 |
| 15:00 | 61 | 100 | 40.1 | 1.83 | 322 |
| 16:00 | 66 | 97 | 47.5 | 1.33 | 356 |
| 17:00 | 63 | 95 | 47.1 | 1.06 | 330 |
| 18:00 | 59 | 100 | 60.6 | 0.97 | 348 |
| 19:00 | 61 | 98 | 48.9 | 1.02 | 328 |
| 20:00 | 68 | 112 | 64.1 | 1.74 | 368 |
| 21:00 | 59 | 104 | 57.6 | 2.53 | 322 |
| 22:00 | 62 | 112 | 61.5 | 2.56 | 266 |
| 23:00 | 54 | 149 | 86.1 | 3.86 | 165 |
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.