Diagnosticar una conexión lenta: red, servidor o sitio

Tres problemas distintos que se sienten igual

La medición que ordena todo lo demás

1. Corré esto desde tu computadora: curl -o /dev/null -s -w "dns %{time_namelookup} tcp %{time_connect} tls %{time_appconnect} primer-byte %{time_starttransfer} total %{time_total}\n" https://tudominio.com.ar/
2. Leé los números en orden, porque son acumulativos. El primero es lo que tardó en resolver el dominio: si es alto, el problema es de DNS y no del servidor.
3. La diferencia entre el primero y el segundo es abrir la conexión, o sea una vuelta completa por la red: equivale al ping. Si ahí ya hay un cuarto de segundo, el camino es largo o está congestionado.
4. Lo que va del tercero al cuarto número es lo que tardó el servidor en armar la respuesta. Ese es el tiempo hasta el primer byte: conexión en 20 milisegundos y primer byte al segundo significa que el que tarda es el sitio.
5. Repetilo tres o cuatro veces, porque una medición sola no distingue un problema de un hipo. Y corré lo mismo dentro del servidor contra sí mismo, agregando -H "Host: tudominio.com.ar" http://127.0.0.1/: si ahí también tarda, la red quedó descartada.

Ping: qué mide y qué no

ping -c 20 tudominio.com.ar manda veinte paquetes y resume cuatro números: mínimo, promedio, máximo y desviación. El promedio es la latencia; la desviación es lo que se siente como entrecortado, porque mide cuánto varía una respuesta respecto de las otras. Una latencia de 60 milisegundos estable molesta menos que una de 30 que salta a 300 cada tanto. Los valores de referencia dependen de la distancia: dentro del país, decenas de milisegundos; contra los Estados Unidos, entre 110 y 180; contra Europa, arriba de 200.

Lo que ping no mide es el ancho de banda: 8 milisegundos de latencia no dicen nada sobre cuántos megabits pasan. Tampoco es infalible, porque muchos routers atienden el ICMP con la prioridad más baja y la pérdida que reporta puede ser peor que la real. Y si el destino no contesta nada, puede estar bloqueado a propósito en lugar de caído.

mtr, que es el traceroute que sirve

1. Instalalo si no está: sudo apt install mtr-tiny.
2. Pedile un informe de cien ciclos, ancho y con las IP a la vista: mtr -rwzbc 100 tudominio.com.ar. Tarda un par de minutos y termina en un texto que se pega tal cual en un ticket.
3. Si el camino filtra el ICMP y la salida se llena de asteriscos, probá con TCP contra el puerto que usás de verdad: mtr -T -P 443 tudominio.com.ar.
4. Corré el mismo informe al revés, desde el servidor hacia tu IP pública: la ida y la vuelta no siempre viajan por el mismo camino, así que uno solo cuenta la mitad de la historia. Y si el dominio está detrás de un CDN, medí también contra la IP del servidor.

Cómo se lee un salto con pérdida

• Pérdida en un salto del medio que no continúa en los siguientes: no es pérdida real. Ese router limita las respuestas que genera él, pero reenvía el tráfico sin tocarlo. Es el error de lectura más común.
• Pérdida que empieza en un salto y se mantiene hasta el último: ahí sí hay algo, en ese salto o en el enlace anterior.
• Pérdida solo en el último salto: descarta el destino, o sea un firewall o un servidor saturado, no el camino.
• Un salto con 200 milisegundos seguido de saltos con 20: no es lento, es un router que contesta tarde. Solo cuenta cuando la latencia sube y ya no vuelve a bajar.
• Asteriscos: ese equipo no responde a las sondas, que es una configuración habitual y no significa que el paquete se perdió. En cambio, anotaciones como !H o !X en lugar de un tiempo no son lentitud sino un bloqueo: el destino quedó inalcanzable o algo prohíbe el paso.

Medir desde más de un lugar

• Desde tu conexión y desde el teléfono con datos móviles: es la prueba más rápida para descartar tu propia red. Desde otra oficina o ciudad, si tenés a quién pedirle el favor.
• Si lo ves solo vos, está entre tu computadora y los primeros saltos: tu wifi, tu router, tu proveedor o tu DNS.
• Si lo ven todos y el tiempo hasta el primer byte es alto en todas las mediciones, el que tarda es el servidor.
• Si lo ven los de un proveedor y nadie más, es la ruta entre ese proveedor y el servidor. Ese dato es el que hace avanzar un reclamo.

Cuando el problema no es la red

1. uptime muestra la carga promedio. Comparala con los núcleos que da nproc: una carga sostenida por encima de ese número significa procesos esperando turno.
2. vmstat 1 5 separa en qué se va el tiempo. Si la columna de espera por disco es alta, el cuello de botella es el almacenamiento y no el procesador.
3. free -h muestra la memoria disponible y el uso de intercambio. Un servidor que está usando swap se siente lento en todo por igual.
4. df -h y df -i, las dos. Un disco lleno frena la base de golpe, y los inodos agotados dan el mismo síntoma con el disco a media capacidad. iostat -x 1, del paquete sysstat, confirma después cuánto está ocupado ese disco.
5. En la base, mirá las consultas lentas y la lista de procesos activos. Una consulta sin índice sobre una tabla que creció es la causa más común de un sitio que andaba bien y un día dejó de andar.
6. journalctl -p err -b --no-pager lista los errores desde el último arranque. Un servicio que se reinicia en loop aparece ahí y explica el resto.

Qué mandar por ticket para que el diagnóstico sirva

• La fecha y la hora exactas de cuando pasó, con la zona horaria, y si se repite o fue una vez.
• Tu IP pública y desde qué tipo de conexión medís: fibra de casa, oficina, datos móviles.
• El informe de mtr en las dos direcciones y la salida del curl con los tiempos, pegados como texto.
• La dirección exacta que probaste, y si pasa con todo el sitio o con una sola página.
• Desde cuándo, y si coincide con algo: un despliegue, una actualización, el horario de los respaldos. Y qué pasó al probar desde otra red, que aunque no cambie nada descarta la mitad de las hipótesis.