Test de velocidad VPS: cómo medir el ancho de banda y la latencia del servidor con iperf3, Speedtest CLI y curl

Un buen test de velocidad VPS responde a dos preguntas: cuánto ancho de banda puede enviar y recibir el servidor, y con qué rapidez viajan los paquetes entre el servidor y tus usuarios. Esta guía explica cómo medir el ancho de banda y la latencia de un servidor cloud o dedicado de JUSTG con Debian/Ubuntu o CentOS/Rocky/AlmaLinux usando iperf3 en ambos sentidos, Speedtest CLI y una descarga sencilla con curl, y cómo interpretar las cifras frente al puerto de 500 Mbps habitual en los servidores cloud de JUSTG en Johannesburgo, Moscú, Tokio y Seúl.

Paso 1: Instala iperf3 para una prueba entre dos máquinas

iperf3 mide el rendimiento TCP puro entre dos equipos que controlas, sin webs ni CDN de por medio. Lo necesitas en el servidor de JUSTG y en la máquina desde la que pruebas (otro servidor o tu PC; también hay versiones de iperf3 para Windows).

# Debian / Ubuntu
apt update && apt install -y iperf3

# CentOS / Rocky Linux / AlmaLinux
dnf install -y iperf3

Paso 2: Inicia el servidor iperf3 y prueba ambos sentidos con -R

En el servidor de JUSTG, permite el puerto TCP 5201 y arranca iperf3 en modo servidor:

# Debian / Ubuntu with UFW
ufw allow 5201/tcp

# CentOS / Rocky / AlmaLinux with firewalld (until next reload)
firewall-cmd --add-port=5201/tcp

# start the iperf3 server (Ctrl+C to stop)
iperf3 -s

En la otra máquina, ejecuta el cliente. Por defecto, el cliente envía datos al servidor (subida desde el punto de vista del cliente). Con -R se invierte el sentido y el servidor te envía a ti, que es lo que viven tus visitantes al descargar páginas y archivos. -P 4 abre cuatro flujos en paralelo y -t 30 dura 30 segundos.

# upload test: your machine -> JUSTG server
iperf3 -c 203.0.113.10 -P 4 -t 30

# download test: JUSTG server -> your machine (reverse mode)
iperf3 -c 203.0.113.10 -P 4 -t 30 -R

Fíjate en las líneas [SUM] del final. El valor de receiver es el rendimiento real; la columna Retr muestra las retransmisiones TCP.

[SUM]   0.00-30.00  sec  1.64 GBytes   470 Mbits/sec   15   sender
[SUM]   0.00-30.03  sec  1.64 GBytes   469 Mbits/sec        receiver

Paso 3: Usa Speedtest CLI (Ookla) o speedtest-cli

Si no tienes una segunda máquina, un servidor Speedtest público es la comprobación más rápida. El Speedtest CLI oficial de Ookla se instala desde su repositorio:

# Debian / Ubuntu
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install -y speedtest

# CentOS / Rocky Linux / AlmaLinux
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.rpm.sh | bash
dnf install -y speedtest

# run a test (nearest server), list servers, or pick one by ID
speedtest --accept-license --accept-gdpr
speedtest -L
speedtest -s 12345

La antigua herramienta en Python speedtest-cli es una alternativa. En Debian/Ubuntu elimina una antes de instalar la otra, porque sus comandos tienen nombres parecidos.

# Debian / Ubuntu
apt install -y speedtest-cli
# any distribution with Python 3
pip3 install speedtest-cli

speedtest-cli --simple
speedtest-cli --list | head -n 20
speedtest-cli --server 12345 --simple

El resultado depende mucho del servidor de prueba elegido: un nodo saturado o lejano puede dar cifras bajas aunque tu puerto esté bien. Prueba dos o tres servidores, incluido uno cercano a tus usuarios.

Paso 4: Haz una prueba de descarga con curl

Una descarga real muestra lo que consigue una sola conexión HTTP. Baja un archivo grande de un mirror bien conectado y descarta los datos:

curl -o /dev/null -w "avg speed: %{speed_download} bytes/s, total: %{time_total}s\n" \
  https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

# wget prints the speed in MB/s at the end
wget -O /dev/null https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.6.tar.xz

curl muestra bytes por segundo. Divide entre 1.000.000 para obtener MB/s y multiplica los MB/s por 8 para obtener Mbps.

Paso 5: Interpreta los resultados frente a un puerto de 500 Mbps

• Unidades: 500 Mbps (megabits) equivalen en teoría a 62,5 MB/s (megabytes). Con la sobrecarga de TCP/IP, unos 470 a 480 Mbps en iperf3, o unos 55 a 59 MB/s en una descarga, indican que el puerto está al máximo.
• Un flujo o varios: en rutas largas, una sola conexión TCP queda limitada por la latencia. Si con -P 4 va mucho más rápido, el puerto está bien y el límite es el tiempo de ida y vuelta.
• Sentido: la subida y la bajada pueden diferir porque la ruta en cada sentido es distinta. Prueba siempre con y sin -R.
• Latencia: iperf3 no la mide; usa ping -c 50 hacia la región de tus usuarios y observa la media y el jitter, no solo el mejor valor.
• El otro extremo: tu conexión doméstica, el Wi-Fi o un servidor de prueba público saturado suelen ser el verdadero cuello de botella.

Paso 6: Prueba en horas punta

Los enlaces internacionales están más cargados por la noche, en la hora local de los usuarios. Repite las pruebas en esa franja y compáralas con un periodo tranquilo. Un bucle sencillo registra varias mediciones:

# three tests, 10 minutes apart, saved to a log file
for i in 1 2 3; do date; speedtest-cli --simple; sleep 600; done | tee -a speedtest.log

Preguntas frecuentes

Speedtest marca 200 Mbps en mi VPS de 500 Mbps. ¿Hay algún problema?

No necesariamente. Prueba otros servidores, usa iperf3 con -P 4 hacia una máquina tuya y comprueba el sentido inverso. Si varios métodos se quedan muy por debajo de la velocidad del puerto, contacta con soporte adjuntando las salidas.

¿Por qué la descarga desde China es más lenta que desde Europa?

La mayor latencia y los enlaces transfronterizos más cargados limitan la velocidad de una sola conexión. Compara horas punta y valle y revisa la ruta con una prueba MTR.

¿Puedo dejar iperf3 funcionando siempre?

Mejor no. Arráncalo solo mientras pruebas y cierra el puerto después.

Si aún no consigues resolverlo, abre un ticket con el soporte técnico de JUSTG e incluye las salidas y la hora de las pruebas.