Tutoriales de VPS
Por qué el VPS se ralentiza en horas punta (2026): cómo distinguir congestión de red, sobreventa y cambios de ruta de retorno
Que un VPS se ralentice en horas punta no siempre significa que el proveedor esté sobrevendiendo. Este artículo analiza la congestión de red, la contención de recursos del host y los cambios de ruta de retorno, y explica cómo los usuarios normales deben hacer pruebas comparativas, leer ping/MTR/carga del sistema y decidir cuándo abrir un ticket y cuándo migrar.
Por qué el VPS se ralentiza en horas punta (2026): cómo distinguir congestión de red, sobreventa y cambios de ruta de retorno
Cuando soluciono problemas de VPS yo mismo, la situación que más temo es esta: todo parece normal durante el día y, después de las 8 de la noche, de repente empieza a ir lento.
No es una caída total, sino un molesto estado de "medio muerto":
- SSH conecta, pero los comandos se sienten flotantes
- El sitio abre, pero la primera pantalla es notablemente más lenta
- Las descargas no están completamente muertas, pero la velocidad fluctúa
pinga veces parece bien, pero el acceso real es un desastre
Muchas personas llegan a este punto y concluyen de inmediato: "este proveedor está sobrevendiendo" o "las especificaciones de este VPS son basura".
El problema es que la lentitud en horas punta tiene más de una causa. Si lo juzgas mal desde el principio, fácilmente abrirás el ticket equivocado, cambiarás al centro de datos equivocado o incluso migrarás sin necesidad.
Normalmente divido el problema en 3 categorías primero: congestión de red, sobreventa del host y cambios de ruta de retorno. Este artículo explica, de forma que los usuarios normales puedan entender, cómo distinguir estas tres.
No te apresures a ejecutar un montón de pruebas todavía; primero establece el marco de juicio en tu cabeza.
| Criterio | Más como congestión de red | Más como sobreventa | Más como cambio de ruta de retorno |
|---|---|---|---|
| Patrón temporal | Claramente peor en horas punta | Se expone más fácilmente en horas punta | Más fluctuación en horas punta |
| Carga interna de la máquina | Posiblemente normal | A menudo empeora junto | Posiblemente normal |
| Comportamiento de la red externa | Peor para cierto ISP o región | Experiencia general más lenta | Jitter, pérdida de paquetes y desvíos más evidentes |
| Acción adecuada | Abrir ticket, cambiar ruta/nodo | Observar el comportamiento del host, considerar migrar | Comparar rutas, evaluar cambiar de región |
Recuerda primero esta regla en lenguaje sencillo:
- Solo el "acceso externo" empeora en horas punta mientras la máquina parece bien — más como un problema de red
- Incluso SSH, la descompresión y la respuesta de la base de datos se arrastran juntos — más como contención de recursos del host
- La ruta es normal durante el día, pero por la noche la ruta de retorno a China de repente se desvía y el jitter crece — más como un cambio de ruta de retorno
La congestión de red es lo que más encuentran los usuarios normales, y también lo más fácil de juzgar erróneamente como "la máquina es mala".
Su característica más típica no es "lento todo el día", sino lento en una ventana horaria muy regular. Por ejemplo, bien durante el día y luego fallando de 8 a 11 de la noche; o el acceso por China Unicom claramente afectado mientras China Mobile está bien.
Para este tipo de problema, normalmente reviso dos cosas primero:
- ¿Solo se ve afectado el acceso nacional?
- ¿Es más evidente solo para ciertos ISP o ciertas regiones?
Si es así, no culpes de inmediato a la CPU y la memoria. A menudo la máquina no tiene presión alguna; lo que está congestionado es un segmento de la ruta de red.
Herramientas como mtr están hechas exactamente para esto. Envían continuamente paquetes de sondeo con TTL bajo, registrando el tiempo de respuesta y la proporción de pérdida de paquetes de cada salto; el manual de mtr también señala explícitamente que si un segmento de la ruta muestra una pérdida de paquetes evidente o un aumento repentino del tiempo de respuesta, a menudo significa que ese enlace tiene un problema o ya está sobrecargado.
Por eso tampoco me gusta mirar solo un gráfico de prueba de velocidad: una prueba de velocidad solo te dice "qué tan rápido es en este momento", pero no "qué segmento del camino está realmente congestionado".
Muchas personas equiparan directamente "lentitud en horas punta" con "congestión de red", y eso también es incorrecto.
Una vez caí en un error muy típico: las páginas abrían lento y pensé que era la red; pero al entrar en la máquina, incluso el refresco de top se trababa, descomprimir archivos era lento y la respuesta de la base de datos se arrastraba.
Eso no es un problema puramente de red; se parece más a contención de recursos del host, es decir, lo que la gente suele llamar sobreventa, vecinos acaparando recursos o la máquina anfitriona demasiado ocupada.
Para juzgar esta categoría, reviso de paso dos señales:
top
vmstat 1
iostat -x 1
No te intimiden estos comandos; a los usuarios normales les basta con mirar unos pocos puntos.
La documentación de virtualización de Red Hat es muy directa sobre steal time: significa que la máquina virtual quería usar CPU, pero el host tomó ese tiempo de CPU para atender otras máquinas virtuales.
Y este valor aparece directamente en /proc/stat, y también lo muestran herramientas como top y vmstat.
Así que si encuentras:
- La carga de trabajo de la máquina no es pesada
- Pero
%stse mantiene alto - Más evidente en horas punta
Entonces es difícil culparlo todo a "el programa no está optimizado". Esto se parece más a presión de recursos en la capa del host.
El manual de iostat explica %iowait como: la CPU está inactiva, pero el sistema todavía tiene solicitudes de E/S de disco sin completar.
En el mismo manual, await se refiere al tiempo medio de espera de las solicitudes de E/S.
Mirar estos dos valores juntos es especialmente útil.
Si, cuando va lento por la noche, encuentras:
%iowaitsubeawaittambién se alarga claramente- El sitio, SSH, la base de datos y la descompresión se ralentizan todos juntos
Entonces se parece más a que los recursos subyacentes de todo el VPS están apretados, no solo a que una ruta de red esté congestionada.
En ese caso, incluso si cambias a una CDN o ajustas Nginx, lo más probable es que solo trates los síntomas, no la causa raíz.
El término "cambio de ruta de retorno" suena misterioso para muchas personas, pero no lo es tanto.
En pocas palabras, significa:
- La ruta por la que salen tus solicitudes y la ruta por la que vuelven los datos no son necesariamente la misma
- La ruta de retorno durante el día y por la noche tampoco es necesariamente la misma
La documentación de Network Manager de AWS incluso incluye "analizar la ruta de retorno" como una opción separada.
Eso al menos demuestra una cosa: la ruta de retorno es inherentemente una variable que necesita análisis separado, no es que la gente piense demasiado.
Los síntomas comunes de este tipo de problema son:
pingno es lo peor, pero el jitter crece de repente- La carga de la página es rápida un momento y lenta al siguiente
- Por la noche, el acceso para usuarios de China continental es especialmente evidente, mientras que el acceso desde el extranjero puede no empeorar al mismo ritmo
- Durante el día traceroute o MTR parece bien, pero al probar de nuevo por la noche, los niveles de ruta y la distribución de latencia son diferentes
Cuidado aquí: un cambio de ruta de retorno no significa que puedas sacar una conclusión con un solo traceroute.
La documentación de Cloudflare sobre traceroute advierte específicamente que detalles como la herencia de TTL y el filtrado de ruta inversa pueden por sí mismos hacer que los resultados "se vean mal" o incluso "sean inutilizables". Así que el enfoque correcto no es confiar en un solo mapa de ruta, sino comparar los resultados del día y de las horas punta.
Si no quieres profundizar demasiado de inmediato, te sugiero seguir este orden.
No te guíes por la sensación.
El método más simple es guardar un registro durante el día y otro por la noche.
Incluso hacer lo siguiente es mucho mejor que decir "por la noche va muy lento" sin pruebas:
ping your-server-ip
mtr -rw your-server-ip
La documentación de Oracle define estas dos herramientas de forma básica y práctica:
pingmide la conectividad y el tiempo de ida y vueltatracerouterastrea la ruta que siguen los paquetes
Mi propia costumbre es:
- Probar una vez durante el día
- Probar una vez en horas punta
- Preferiblemente en el mismo ordenador y el mismo entorno de red
Así obtienes "datos comparativos", no emoción.
He visto a muchas personas concluir que la red está bien solo porque ping parece decente. Eso es peligroso.
La documentación AIM de Cloudflare también señala que la velocidad de subida y bajada por sí sola no puede representar completamente la calidad de la red; lo que realmente afecta la experiencia también incluye:
- latency
- packet loss
- loaded latency
- jitter
En términos sencillos:
No puedes mirar solo "si conecta"; también debes mirar "si tiembla, si es estable y si se deforma bajo carga".
Así que al diagnosticar, es mejor observar también:
- Si la primera pantalla del sitio se ralentiza notablemente
- Si la entrada por SSH se siente flotante
- Si las descargas fluctúan continuamente
- Si la base de datos o el panel de administración también van lentos
Si el acceso externo es lento pero la máquina es estable por dentro, se parece más a un problema de red o de ruta de retorno.
Si va lento por fuera y también por dentro, entonces sospecha aún más de contención de recursos del host.
No necesitas entenderlo todo en este paso; poder ver "si lo de dentro empeora junto" ya es muy útil.
ping puede mostrar conectividad y RTT, pero no puede explicar toda la experiencia.
Lo trato como un "chequeo básico", no como un veredicto final.
La mayor característica de los problemas en horas punta es la "ventana horaria".
Si pruebas solo una vez, y ni siquiera en horas punta, el resultado tiene muy poco valor de referencia.
La documentación de calidad de red de Cloudflare también advierte específicamente que la interferencia Wi-Fi, estar demasiado lejos del router y la mala calidad de la banda ancha local pueden por sí mismos arruinar el jitter y la pérdida de paquetes.
Así que si usas Wi-Fi doméstico, no te apresures a culpar completamente al VPS.
A veces no es la red del VPS la que está mal, sino:
- Un plugin de WordPress explotó
- Las consultas a la base de datos lo arrastran
- Alguna API externa responde lento por la noche
En este caso, si solo miras "la página va lenta", es fácil juzgarlo erróneamente como un problema de red.
La sobreventa ciertamente existe, pero no la trates como una explicación universal.
A veces realmente es congestión de red en horas punta, a veces realmente es un cambio de ruta de retorno, y a veces incluso las tres se acumulan juntas.
Mi propio criterio es simple.
- Ya tienes resultados comparativos del día y de la noche
- Puedes describir claramente qué ventana horaria, qué carga de trabajo y qué tipo de acceso se ve afectado
- La carga interna del VPS parece normal, más como un problema de red o de nodo
Al abrir un ticket, no escribas "su VPS va muy lento, arréglenlo ya".
Una forma más eficaz es escribir claramente la hora, los síntomas y los resultados de las pruebas. También puedes consultar la plantilla de este enlace interno:
Cómo redactar un ticket de soporte de VPS (2026)
- Se reproduce en horas punta durante varios días seguidos
- Ya has hecho el diagnóstico básico
- Las respuestas del proveedor siempre son vacías, solo te dicen "observa un poco más"
- Tu carga de trabajo ya requiere alta estabilidad en horas punta
En este caso, seguir perdiendo tiempo a veces es peor que cambiar directamente a una región o ruta más adecuada.
Si sospechas que es un problema de recursos del host, también puedes revisar este artículo:
Cómo juzgar la sobreventa de un VPS (2026)
Qué hacer cuando limitan la velocidad de un VPS (2026)
- Primero confirma si el problema solo ocurre en horas punta
- Prueba una vez durante el día y otra por la noche; no te bases en un solo gráfico de prueba de velocidad
- Usa
pingpara conectividad básica, ymtrotraceroutepara ruta y fluctuación - Entra en el VPS para ver si señales internas como
%st,%iowaityawaitempeoran juntas - Lento por fuera, estable por dentro — más como red o ruta de retorno
- Lento por fuera, lento por dentro también — sospecha aún más de contención de recursos del host
- Abre un ticket con datos comparativos; si no hay progreso, prepárate para migrar pronto
En definitiva, la lentitud en horas punta no es un "problema místico", sino un problema de "no mirar solo una métrica".
Con solo mirar juntos la ventana horaria, la ruta externa y la carga interna, tu juicio será mucho más preciso que el de la mayoría.