Diagnóstico y medición de rendimiento en VPS

Recientemente me encontré con un problema recurrente al intentar medir el rendimiento de red en uno de mis servidores VPS con Ubuntu 22, alojado en Contabo. La herramienta `speedtest-cli`, que solía ser mi opción por defecto, fallaba sistemáticamente con un error que me llevó a investigar a fondo las causas y a descubrir alternativas mucho más fiables para entornos de producción.

1. El Problema Inicial: `speedtest-cli` no funciona

Mi primer intento de verificar la velocidad de red en el VPS fue con el comando habitual:

root@web:~/backups/sites# speedtest-cli
Retrieving speedtest.net configuration...
Testing from Level 3 Communications ([IP del servidor VPS])...
Retrieving speedtest.net server list...
Selecting best server based on ping...
ERROR: Unable to connect to servers to test latency.

Este error, Unable to connect to servers to test latency, me indicaba que la herramienta no podía establecer conexión con los servidores de Speedtest para medir el ping, lo cual es el primer paso para seleccionar el mejor servidor y realizar la prueba de velocidad.

2. Primeras Hipótesis y Verificaciones Rápidas

Ante el fallo, consideré varias causas comunes en entornos de VPS:

• Bloqueo por parte del proveedor del VPS o de Speedtest.net a IPs de datacenter.
• Problemas de resolución DNS.
• Firewall local (`ufw`, `iptables`) o reglas de red del proveedor.
• Una versión obsoleta de `speedtest-cli`.
• Restricciones de IPv6/IPv4.

Para descartar problemas básicos de conectividad y DNS, realicé las siguientes pruebas:

2.1. Verificación de Conectividad Básica

Confirmé que el VPS tenía conexión a internet y podía resolver dominios:

root@web:~/backups/sites# ping -c 4 google.com
PING google.com (142.251.208.174) 56(84) bytes of data.
64 bytes from lcfraa-bl-in-f14.1e100.net (142.251.208.174): icmp_seq=1 ttl=116 time=2.91 ms
64 bytes from lcfraa-bl-in-f14.1e100.net (142.251.208.174): icmp_seq=2 ttl=116 time=3.06 ms
64 bytes from lcfraa-bl-in-f14.1e100.net (142.251.208.174): icmp_seq=3 ttl=116 time=3.04 ms
64 bytes from lcfraa-bl-in-f14.1e100.net (142.251.208.174): icmp_seq=4 ttl=116 time=3.21 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.908/3.053/3.205/0.105 ms

root@web:~/backups/sites# curl https://www.google.com

Ambas pruebas fueron exitosas, demostrando que la conectividad de red y la resolución DNS funcionaban correctamente. El ping a Google arrojó una latencia excelente de ~3 ms.

2.2. Intentos con `speedtest-cli` y su versión oficial

Intenté listar servidores con `speedtest-cli --list`, pero tampoco funcionó. Luego, quise instalar la versión oficial de Ookla, pero el paquete no estaba disponible en los repositorios por defecto de Ubuntu 22:

root@web:~/backups/sites# sudo apt install speedtest
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package speedtest

También probé a ejecutar el script `speedtest.py` directamente desde GitHub, obteniendo el mismo error:

root@web:~/backups/sites# curl -s https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py | python3
Retrieving speedtest.net configuration...
Testing from Level 3 Communications ([IP del servidor VPS])...
Retrieving speedtest.net server list...
Selecting best server based on ping...
ERROR: Unable to connect to servers to test latency.

2.3. Revisión de la configuración DNS

Verifiqué el archivo `resolv.conf` para asegurar que los servidores DNS estuvieran configurados correctamente:

root@web:~/backups/sites# cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search invalid

Aunque `127.0.0.53` es el stub resolver de `systemd-resolved`, el hecho de que `ping google.com` funcionara confirmaba que la resolución DNS no era el problema.

3. El Diagnóstico: Contabo y las Restricciones de Speedtest

Con las pruebas anteriores, pude descartar problemas de conectividad básica, DNS o firewall local. La evidencia apuntaba a un problema específico con `speedtest-cli` y su interacción con los servidores de Ookla desde una IP de datacenter como la de Contabo.

La falla ocurría precisamente en el paso de "Selecting best server based on ping...", lo que indicaba que la herramienta no podía ni siquiera obtener una lista de servidores válidos o que ninguno respondía a las pruebas de latencia iniciales.

3.1. Confirmación de Acceso a `speedtest.net`

Para confirmar si había un bloqueo total o parcial, intenté acceder a la página principal de Speedtest.net usando `curl` con la opción `-I` para obtener solo las cabeceras:

root@web:~/backups/sites# curl -I https://www.speedtest.net
HTTP/2 200
date: Thu, 19 Mar 2026 16:32:39 GMT
content-type: text/html; charset=utf-8
server: cloudflare
cf-ray: 9deddfd04c823635-FRA
cf-cache-status: DYNAMIC
cache-control: private
etag: W/"22bc0-+1e/FfS7PQyUj+2GMOEf8iv3MN8"
vary: Origin, Accept-Encoding
access-control-allow-credentials: true
content-security-policy: frame-ancestors 'none'; upgrade-insecure-requests
x-frame-options: DENY
set-cookie: __cf_bm=aVfj822Bg61d6uDCQJuzN.DL4gCx6nFJYueIDIgW2h0-1773937959-1.0.1.1-dEXJdyzDaZBiWHAj.E3W8TiQTqsU_BbYbQlaHcF0HL_9sAyePdCRxjuMRvDMTXxw1q.WZMp9RwKmeqoXpLOwonCulJ1IZnUgmRmIO5HMa2U; path=/; expires=Thu, 19-Mar-26 17:02:39 GMT; domain=.www.speedtest.net; HttpOnly; Secure; SameSite=None

La respuesta `HTTP/2 200` confirmaba que el VPS podía alcanzar la web de Speedtest.net sin problemas. Esto consolidó la idea de que el problema no era de conectividad de red general, sino una incompatibilidad o restricción específica con la API que utiliza el cliente `speedtest-cli` (Python).

Ookla ha actualizado su backend, y el cliente `speedtest-cli` original en Python ya no es compatible de forma fiable. Además, es común que filtren o limiten el tráfico desde IPs de datacenter.

4. Soluciones Alternativas para Medir el Rendimiento

Dado que `speedtest-cli` no era una opción viable, exploré alternativas más robustas y adecuadas para entornos de servidor.

4.1. Instalación Manual del CLI Oficial de Ookla

Intenté instalar el CLI oficial de Ookla, pero el script de instalación automática no funcionó en mi versión de Ubuntu:

root@web:~/backups/sites# curl -s https://install.speedtest.net/app/cli/install.deb.sh | sudo bash
This distribution version is not currently supported via package management, please use the direct download builds per architecture found at https://www.speedtest.net/apps/cli

La solución manual para instalar el binario oficial es descargar el archivo `tgz` y ejecutarlo directamente:

wget https://install.speedtest.net/app/cli/ookla-speedtest-1.2.0-linux-x86_64.tgz
tar -xvf ookla-speedtest-1.2.0-linux-x86_64.tgz
chmod +x speedtest
./speedtest

Aunque esta opción es válida, mi experiencia previa con Contabo me hizo dudar de su fiabilidad, ya que los servidores de Ookla a menudo ignoran el tráfico de datacenter.

4.2. `iperf3`: La Herramienta Definitiva para Ancho de Banda

Para medir el ancho de banda real entre dos puntos (mi VPS y mi PC local), `iperf3` es la herramienta ideal. Ya la tenía instalada en mi VPS.

apt install iperf3 -y

4.2.1. VPS como Servidor, PC Local como Cliente

Para medir la velocidad de subida desde mi PC local al VPS (o descarga desde el VPS a mi PC):

En el VPS (Linux, [IP del servidor VPS]):

iperf3 -s

Esto deja el VPS escuchando en el puerto 5201 (por defecto).

En mi PC local (Windows 10, [IP de mi PC local]):

Tras descargar `iperf3` (por ejemplo, desde iperf.fr), ejecuto en CMD o PowerShell:

iperf3 -c [IP del servidor VPS]

iperf3 -c [IP del servidor VPS] -t 30 -P 4

4.2.2. PC Local como Servidor, VPS como Cliente (con modo inverso)

Medir la velocidad de descarga desde el VPS a mi PC local es más complejo debido a NAT en mi red doméstica. La forma más sencilla es usar el modo inverso (`-R`) de `iperf3`:

En el VPS (servidor):

iperf3 -s

En mi PC local (cliente con reverse):

iperf3 -c [IP del servidor VPS] -P 4 -t 30 -R

Este comando mide la descarga desde el VPS hacia mi PC sin necesidad de abrir puertos en mi router local.

4.3. `fast.com` (Netflix)

Otra alternativa rápida es usar el servicio `fast.com` de Netflix, que puede ser accedido vía `curl` o con su propio CLI:

curl -s https://fast.com

O instalando su CLI (requiere Node.js y npm):

apt install npm -y
npm install -g fast-cli
fast

5. Midiendo el Rendimiento Real de Sitios Web

Con 10 sitios web alojados en el VPS, la velocidad de red bruta no era el único factor. Necesitaba medir el rendimiento real de carga de mis aplicaciones web, incluyendo el tiempo de respuesta del servidor, el tiempo total de carga y la latencia del backend.

5.1. `curl` para Métricas Detalladas de Carga Web

curl es una herramienta extremadamente potente para obtener métricas detalladas de una URL. Desde mi terminal de Windows, puedo usar el siguiente comando:

curl -o NUL -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nSize: %{size_download} bytes\nSpeed: %{speed_download} B/s\n" https://mi-sitio-web.com

Este comando me proporciona métricas clave:

• DNS (`time_namelookup`): Tiempo de resolución del nombre de dominio.
• Connect (`time_connect`): Tiempo para establecer la conexión TCP.
• TTFB (`time_starttransfer`): Time To First Byte, crucial para medir el rendimiento del backend (PHP, base de datos).
• Total (`time_total`): Tiempo total de la transacción.
• Size (`size_download`): Tamaño total de los datos descargados.
• Speed (`speed_download`): Velocidad de descarga.

Para probar múltiples sitios, puedo usar un bucle en PowerShell o CMD:

for %i in (mi-sitio-web-1.com mi-sitio-web-2.com mi-sitio-web-3.com) do curl -o NUL -s -w "%{url_effective} | %{time_total}s\n" https://%i

5.2. Medición Específica del Backend (TTFB)

Si sospecho que el problema es el servidor (CPU, PHP, base de datos) y no la red o el frontend, me enfoco en el TTFB:

curl -o NUL -s -w "TTFB: %{time_starttransfer}s\n" https://mi-sitio-web.com

Un TTFB superior a 1 segundo suele indicar un cuello de botella en el backend.

5.3. Comparación Local vs. Remota para Diagnóstico

Un truco muy útil es comparar el rendimiento de un sitio web desde mi PC local y desde el propio VPS (usando `localhost` o la IP interna). Si el sitio es rápido desde `localhost` en el VPS pero lento desde mi PC, el problema es de red o CDN. Si es lento en ambos, el problema es del servidor (CPU, PHP-FPM, MySQL).

En el VPS:

curl -o /dev/null -s -w "%{time_total}\n" http://localhost

6. Conclusiones y Recomendaciones Finales

Mi experiencia me ha enseñado que `speedtest-cli` ya no es una herramienta fiable para diagnosticar el rendimiento de red en muchos VPS, especialmente en proveedores como Contabo, debido a la obsolescencia del script y a las restricciones de Ookla.

Para servidores en producción, las herramientas más útiles son:

• `iperf3`: Para mediciones precisas de ancho de banda entre puntos específicos.
• `curl` con formato `write-out`: Para obtener métricas detalladas del rendimiento de carga de sitios web, especialmente el TTFB.
• Monitoreo continuo: Herramientas como Prometheus o Netdata para identificar cuellos de botella en CPU, RAM, PHP-FPM o MySQL, que suelen ser los verdaderos problemas en VPS con múltiples sitios.