Conexión lenta al servidor: cómo saber si es la red, el VPS o el sitio

Dos minutos para descartar lo obvio

• Mirá la página de estado del servicio. Si hay un incidente en curso, no hace falta medir nada.
• Abrí el sitio desde el celular con datos móviles, sin wifi. Si así anda bien, el problema está entre tu computadora y tu proveedor de internet.
• Si desde la oficina no abre nada y desde los datos móviles sí, puede que un firewall haya bloqueado la IP de la oficina después de varios intentos fallidos de contraseña. En un VPS lo hace tu propio fail2ban; en el hosting, el desbloqueo se pide en la página de desbloqueo de IP.
• Pedí un archivo estático, como /robots.txt o una imagen. Si llega al instante y la portada tarda, la red funciona y lo lento es lo que arma la página.

Paso 1: desarmar el tiempo con curl

curl puede informar cuánto tardó cada etapa de un pedido. Es la medición que ordena todo lo demás, porque separa lo que es red de lo que es servidor:

curl -so /dev/null https://tudominio.com.ar/ -w 'dns:         %{time_namelookup}\nconexion:    %{time_connect}\ntls:         %{time_appconnect}\nprimer byte: %{time_starttransfer}\ntotal:       %{time_total}\n'

• Los tiempos están en segundos y son acumulados: cada uno incluye a los anteriores.
• Corrélo tres o cuatro veces. La primera suele ser más lenta porque el nombre todavía no estaba en la caché del DNS.
• En Windows 10 y 11, curl viene instalado, pero en Windows PowerShell escribí curl.exe: a secas, curl llama a otro comando.

Cómo leer cada tramo

Si la conexión se abre en 20 ms y el primer byte llega al segundo, la red no tiene nada que ver.

La contraprueba, desde el propio VPS

Para confirmar que el lento es el servidor, repetí la medición desde el VPS contra sí mismo. Con --resolve el pedido va a la máquina local pero conserva el nombre del sitio y su certificado, así que pasa por la misma configuración que un visitante:

curl -so /dev/null -w '%{time_starttransfer}\n' --resolve tudominio.com.ar:443:127.0.0.1 https://tudominio.com.ar/

• Si desde adentro el primer byte también tarda, la red quedó fuera de la discusión.
• Si desde adentro es rápido y desde afuera no, el problema está en el camino o en algo que se interpone, como un firewall que inspecciona el tráfico.

Paso 2: latencia y pérdida, con ping y mtr

ping -c 30 tudominio.com.ar resume cuatro números al final: mínimo, promedio, máximo y mdev, la desviación. El promedio es la latencia; la desviación es lo que se siente como entrecortado. Treinta milisegundos parejos andan mejor que quince que saltan a doscientos cada tanto.

Para ver en qué tramo aparece el problema, mtr combina ping y traceroute. En Debian y Ubuntu se instala con apt install mtr-tiny; en AlmaLinux, con dnf install mtr. Un informe de doscientos ciclos, con nombres y direcciones, se pide así:

mtr -r -w -b -c 200 tudominio.com.ar
# si en el camino filtran ICMP, por TCP al puerto del sitio
mtr -r -w -b -c 200 -T -P 443 tudominio.com.ar

Qué dice cada patrón en un informe de mtr

Hacé un informe en cada sentido: desde tu computadora hacia el VPS y desde el VPS hacia la IP pública de tu conexión, porque la ida y la vuelta pueden ir por caminos distintos. Después leelos con esta guía:

Paso 3: ancho de banda real, con iperf3

Las pruebas de velocidad de los navegadores miden tu enlace contra un servidor de la propia prueba, cercano a vos. No dicen nada del camino hasta tu VPS. Para medir ese camino, iperf3 hace de servidor en un extremo y de cliente en el otro. En el ejemplo, reemplazá 203.0.113.10 por la IP de tu VPS:

# en el VPS: abrí el puerto solo mientras dure la prueba
sudo ufw allow 5201/tcp          # o: sudo firewall-cmd --add-port=5201/tcp
iperf3 -s
# en tu computadora
iperf3 -c 203.0.113.10 -t 20      # subida hacia el VPS
iperf3 -c 203.0.113.10 -t 20 -R   # bajada desde el VPS

• Si el resultado se acerca a lo que tenés contratado con tu proveedor de internet, el camino está bien y el cuello de botella es otro.
• Si da mucho menos solo en un sentido, anotalo: es un dato valioso para cualquier reclamo.
• En los servidores cloud la salida es de hasta 100 Mbps: unos 11 MB/s reales son el techo del plan, no una falla.
• Al terminar, cortá iperf3 con Ctrl+C y cerrá el puerto con sudo ufw delete allow 5201/tcp. En firewalld, la regla sin --permanent desaparece sola al recargarlo.

Paso 4: cuando el que tarda es el servidor

Si la red quedó descartada, entrá por SSH y revisá en este orden. Cada comando responde una pregunta concreta:

iostat viene en el paquete sysstat.

Tres trampas que parecen problemas de red

• IPv6 a medias. Si el dominio tiene registro AAAA pero la ruta IPv6 falla, algunos clientes esperan antes de probar por IPv4. Compará curl -4 con curl -6 en el mismo pedido.
• El tamaño de los paquetes. Si las páginas chicas cargan y las pesadas se cuelgan, sobre todo a través de una VPN, puede haber un problema de MTU. En Linux, probá ping -M do -s 1472 contra el servidor: si falla y con un número más chico funciona, ahí está.
• Un resolvedor lento. dig tudominio.com.ar informa la demora en la línea Query time. Si pasa de unos cientos de milisegundos, el que tarda es el DNS de tu red, no el servidor.

Qué pasarle al soporte

En un VPS, el sistema operativo lo administrás vos; el soporte revisa la red y la plataforma. Con estos datos lo hace rápido y sin idas y vueltas, por ticket, correo, chat o teléfono:

1. Fecha y hora exactas en que lo notaste, y si es constante o va y viene.
2. Tu IP pública y el tipo de conexión desde el que medís: fibra, cable, datos móviles, VPN.
3. Tres corridas del curl con los tiempos, pegadas como texto.
4. Los dos informes de mtr, de ida y de vuelta, y el resultado de iperf3 si lo hiciste.
5. Qué cambió antes de que empezara: una actualización, un plugin nuevo, más tráfico, un respaldo que corre a esa hora.