Tutoriales de VPS
Optimización de red en VPS en la práctica (2026): ¿cómo reducir latencia, jitter y pérdida de paquetes? Del diagnóstico al ajuste
"La red va lenta" no siempre significa poco ancho de banda; muchas veces es pérdida de paquetes, jitter, acumulación en colas o desajuste de MTU/MSS. Este artículo sigue un orden práctico: primero usa ping/mtr/iperf3 para distinguir el tipo de problema y luego aplica optimizaciones reversibles en BBR+FQ, DNS, MTU/MSS y búferes TCP; cada paso incluye un método de verificación para evitar ajustes a ciegas.
Mucha gente dice "la red del VPS va lenta" y su primera reacción es: el ancho de banda es demasiado pequeño.
Pero lo que veo más a menudo es:
- Pérdida de paquetes (incluso un 1%-2% resulta muy molesto)
- Jitter alto, escribir por SSH se siente errático
- Acumulación en colas (bufferbloat): el test de velocidad se ve bien, pero la interacción real va con lag
- Desajuste de MTU/MSS, HTTPS/descargas se atascan sin motivo aparente
Este artículo no es "pega un montón de sysctl y listo". Lo escribo en orden práctico: primero diagnosticar y luego optimizar; cada paso se puede verificar y revertir.
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
dnsalto: atiende primero el DNSconnectalto: latencia del enlace/pérdida de paquetes/desvío de rutattfbalto: el servicio del otro lado va lento (no necesariamente es la red de tu VPS)
ping -c 50 1.1.1.1
ping -c 50 8.8.8.8
En Debian/Ubuntu, instala primero:
sudo apt-get update && sudo apt-get install -y mtr
Prueba desde tu equipo local al VPS:
sudo mtr -rwzc 200 <VPS_IP>
Desde el VPS a un sitio objetivo (por ejemplo, un sitio que visitas a menudo):
sudo mtr -rwzc 200 example.com
Cómo interpretarlo (con estas dos reglas basta):
- La pérdida de paquetes empieza en un salto y todos los saltos posteriores también pierden paquetes: ese tramo del enlace es más sospechoso
- Un salto intermedio muestra mucha pérdida de paquetes pero los posteriores no: a menudo ese router solo limita ICMP, no es pérdida real
Debian/Ubuntu:
sudo apt-get update && sudo apt-get install -y iperf3
Necesitas un servidor iperf3 (puede ser otro VPS tuyo).
# client
iperf3 -c <SERVER_IP> -t 15
iperf3 -c <SERVER_IP> -P 4 -t 15
Un valor bajo en un solo hilo y alto en varios hilos suele indicar que te afecta más "latencia + control de congestión" que "no se te está dando ancho de banda".
Para una ruta de diagnóstico más completa, lee directamente este artículo (primero atribuye el problema a una etapa concreta):
- Cómo solucionar una red VPS lenta: de las pruebas de velocidad al diagnóstico de pérdida de paquetes
Si tienes un enlace transfronterizo con latencia alta, BBR suele ser "el aumento de velocidad más barato".
El tutorial completo de BBR ya existe en el sitio, así que no lo repito aquí:
Solo recuerda una combinación:
tcp_congestion_control=bbrdefault_qdisc=fq
Verificación:
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
2) Trata el bufferbloat: el culpable cuando el test de velocidad no es lento pero "se siente con lag"
Síntomas típicos:
- speedtest se ve bien
- pero abrir páginas web, SSH y llamadas a API "se atasca"
Puedes hacer ping mientras descargas para ver si la latencia se dispara de repente:
# 终端 A：持续 ping
ping 1.1.1.1
# 终端 B：随便跑个大下载/同步
# 例如 curl/wget/apt update 等
Si al empezar la descarga la latencia de ping salta de 30ms a 300ms+, es un problema típico de acumulación en colas.
fq suele mejorar notablemente este tipo de lag interactivo.
Primero mira qué DNS estás usando ahora:
cat /etc/resolv.conf
Verifica el tiempo de resolución DNS (en Debian/Ubuntu, instala primero):
sudo apt-get update && sudo apt-get install -y dnsutils
/usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @1.1.1.1
Puedes cambiar temporalmente a Cloudflare/Google (el método exacto depende de cómo gestiones tu entorno):
- IPv4:
1.1.1.1/8.8.8.8 - IPv6:
2606:4700:4700::1111/2001:4860:4860::8888
Síntomas:
- Los archivos pequeños no dan problemas
- En cuanto es HTTPS o un paquete algo más grande, se atasca
Prueba el Path MTU:
# 1472 = 1500 - 28
ping -c 3 -M do -s 1472 1.1.1.1
# 不通就逐步减小
ping -c 3 -M do -s 1452 1.1.1.1
Para una solución de emergencia, usa MSS clamp (no es una cura definitiva, pero muchas veces mejora de inmediato):
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
En enlaces de alta latencia, ampliar adecuadamente los búferes puede mejorar el rendimiento; pero ajustar a ciegas solo hace que los problemas sean más difíciles de diagnosticar.
Principio recomendado:
- Primero usa iperf3 para confirmar que "el ancho de banda no se satura"
- Luego considera ajustar
rmem/wmem
Puedes anotar primero los valores actuales (para facilitar la reversión):
sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
Parte de la lentitud no es de red en absoluto.
Ejecuta primero estos comandos; muchas veces se ve de un vistazo:
uptime
free -h
df -hT
- CPU al máximo: todo va lento
- Memoria agotada: empieza el swap/se dispara el OOM, y se siente como "la red se volvió lenta de repente"
- Disco lleno: no se puede escribir, los servicios fallan de diversas formas
Para el diagnóstico relacionado con CPU, lee directamente este artículo:
Para apagar incendios relacionados con el disco, lee este:
Te sugiero seguir este orden (cada paso se puede revertir):
curl -wdistinguir DNS/enlace/TTFBping/mtr/iperf3identificar el tipo de problema- BBR + FQ (lo más rentable)
- Optimización de DNS
- Solución de problemas de MTU/MSS
- Tocar los búferes TCP solo cuando sea necesario
Un último recordatorio:
Si lo que mides es "congestión en hora punta/desvío de ruta", por mucho que ajustes sysctl, no podrás salvar el enlace físico.
En ese momento, las soluciones más realistas son: cambiar de región, cambiar de ruta o usar un CDN.