Cómo probar el ping y la velocidad de un VPS antes de pagar

Dos proveedores con planes idénticos en la misma ciudad pueden dar un ping distinto a tus usuarios, otra velocidad de descarga y discos cuyo rendimiento difiere varias veces. La ficha del plan no lo cuenta, pero se puede comprobar. La red casi siempre puede medirse antes de pagar: muchos proveedores publican direcciones de prueba y páginas de looking glass. La CPU y el disco se comprueban en los primeros minutos tras el arranque, y si el resultado es malo, el servidor se puede devolver durante el periodo de prueba o eliminar con pago por horas. A continuación, el orden de las comprobaciones y valores de referencia para leer los resultados.

Qué se puede comprobar antes de pagar

Los proveedores que confían en su red publican herramientas para probarla. Búscalas en el pie de la web, en la sección «Centros de datos» o «Red», o en la base de conocimiento.

• Una dirección IP de prueba para cada ubicación. Puedes hacerle ping y lanzar un trazado desde tu propio ordenador para ver la latencia y la ruta reales desde tu red.
• Archivos de prueba de 100 MB, 1 GB o más. Descargar uno muestra a qué velocidad entrega datos a tu operador un servidor en esa ubicación.
• Looking glass: una página web desde la que puedes lanzar ping o traceroute, o consultar la ruta BGP desde el router del proveedor hasta cualquier dirección. Es la vista desde el otro lado: cómo ve la red del proveedor tu oficina o a tus usuarios.

El catálogo de Accsly recopila las direcciones de prueba y los enlaces de looking glass de los proveedores y los muestra cuando se conocen. Si un proveedor no tiene estas herramientas, pide una IP de prueba al soporte; suele tardar unos minutos.

Ping, mtr y traceroute: medir la latencia

Mide la latencia desde donde están los usuarios del servidor: desde la oficina, desde casa y, para un servicio público, desde varias ciudades. Un ping desde un lugar no dice nada sobre otro.

• ping -c 50 dirección muestra la latencia media y el jitter. Fíjate en el máximo y en la pérdida de paquetes, no solo en la media: 40 ms estables son mejores que 25 ms con picos de 200.
• mtr -rwc 100 dirección (WinMTR o pathping en Windows) muestra la latencia y la pérdida en cada salto. Es la herramienta principal cuando hay que localizar dónde se pierde exactamente el tiempo.
• traceroute o tracert muestra el recorrido de los paquetes. Los nombres de los saltos revelan qué redes y países atraviesa el tráfico: a veces a un servidor en un país vecino se llega por una ruta que pasa por el otro extremo del continente.

Cómo leer mtr: una pérdida en un salto intermedio con cero pérdida en el destino no suele ser un problema, porque muchos routers simplemente no responden a las peticiones de diagnóstico. La señal de alarma es una pérdida que empieza en un salto y continúa hasta el final de la ruta, o un salto brusco de latencia en un tramo concreto.

Valores de referencia: dentro de una misma ciudad, 1–5 ms; dentro de España, 5–20 ms; Madrid–Fráncfort, 25–35 ms; Europa occidental–costa este de EE. UU., 80–100 ms; costa este–costa oeste de EE. UU., 60–80 ms; Ciudad de México–Dallas, unos 30–40 ms; Europa–Asia, 150 ms o más. Para una web, 30–40 ms de diferencia apenas se notan; para un servidor de juegos, VoIP o escritorio remoto, sí.

Pruebas desde varias ciudades

Si el público del servidor está repartido por un país o por varios, una sola medición desde la oficina no basta. Servicios gratuitos de pruebas distribuidas como Globalping y RIPE Atlas lanzan ping, traceroute y peticiones HTTP desde cientos de sondas en distintos operadores. Muestran qué usuarios tienen una ruta larga hasta el centro de datos y dónde se pierden paquetes. Es especialmente útil para elegir entre dos ubicaciones: un servidor 5 ms más rápido desde Madrid puede ser bastante más lento para usuarios en Latinoamérica o en el norte de Europa. Para un servicio con usuarios en varias regiones, una ubicación con latencia pareja para todos es mejor que la más rápida para una sola ciudad.

Velocidad de descarga y archivos de prueba

Descarga un archivo de prueba de 100 MB desde cada ubicación que estés valorando: curl -o /dev/null https://…/100mb.test muestra la velocidad media. Ten en cuenta que el resultado lo limita el eslabón más lento: tu conexión doméstica, el wifi y la congestión vespertina de tu operador. Por eso compara proveedores entre sí desde el mismo ordenador y a la misma hora, no con las cifras del plan.

Los sitios populares de test de velocidad miden el enlace hasta el servidor más cercano a ti, no hasta el proveedor, así que sirven de poco para elegir un VPS. Si un proveedor no tiene archivo de prueba, esta comprobación espera a que el servidor esté en marcha.

Periodos de prueba, reembolsos y pago por horas

La CPU y el disco no se pueden medir antes del arranque, así que importa lo barato que resulte probar un servidor.

• Una prueba gratuita de un día a una semana sobre el plan o una versión reducida. Algunos proveedores exigen verificar el teléfono o la identidad. Consulta VPS con prueba gratuita.
• Un periodo de devolución en los primeros días. Lee las condiciones: el reembolso a menudo cubre solo el primer pedido, excluye licencias e IP adicionales y se devuelve únicamente al método de pago original.
• Pago por horas. La forma más fácil de comparar varios proveedores: arranca un servidor, haz las pruebas en una hora y elimínalo, pagando solo el tiempo usado. Consulta VPS con pago por horas.

Con facturación mensual y sin prueba ni reembolso, empieza por el plazo más corto aunque el pago anual salga más barato: un descuento anual no compensa un servidor que no encaja.

Qué medir en la primera hora tras el arranque

Primero comprueba que has recibido lo prometido: lscpu muestra el modelo de CPU y el número de núcleos, free -h la memoria, lsblk y df -h el disco. Después, tres pruebas.

Disco: fio. Para bases de datos y webs importa la E/S aleatoria, no la escritura secuencial. Una prueba típica: fio --name=rand --rw=randrw --bs=4k --size=1G --iodepth=32 --direct=1 --runtime=60 --time_based. Valores de referencia: un buen NVMe da decenas de miles de IOPS con bloques de 4 KB, un SSD SATA de unos pocos miles a unas pocas decenas de miles, un HDD cientos. Si un plan «NVMe» entrega un par de miles de IOPS, el disco está muy limitado o saturado por los vecinos.

CPU: sysbench o Geekbench. sysbench cpu --threads=1 run y la misma prueba en todos los núcleos muestran el rendimiento en un hilo y el del servidor completo. Geekbench es práctico porque el resultado se puede comparar con su base de datos pública. Repite la prueba varias veces a distintas horas: si los resultados bailan, los núcleos son compartidos y están ocupados por los vecinos.

Red: iperf3. Una prueba entre dos servidores tuyos o contra un servidor iperf3 público muestra la capacidad real del puerto: iperf3 -c dirección -P 4 -t 30, más -R para el sentido inverso. En un puerto gigabit espera 800–940 Mbps; si obtienes 100–200, el puerto está limitado o compartido.

Si el servidor va a enviar correo, comprueba también que la IP asignada no esté en listas negras de spam y que la latencia desde el servidor hasta tus usuarios coincida con la que mediste antes de pagar.

Errores habituales al probar

• Probar por wifi. Una red inalámbrica añade latencia y pérdidas que el proveedor no tiene. Usa cable para las mediciones.
• Una sola medición al mediodía. Las redes y los vecinos del host se comportan distinto por la mañana y por la noche, así que una única ejecución puede engañar.
• Prueba de disco con caché. Sin --direct=1, fio mide la memoria y no el disco, y el resultado se infla varias veces.
• Una prueba demasiado corta. Algunos planes van rápidos los primeros minutos y luego limitan el disco o la CPU. Haz pruebas de al menos un minuto.

Cómo comparar los resultados

• Compara proveedores con el mismo conjunto de pruebas, desde los mismos puntos y a la misma hora del día.
• Repite las mediciones por la tarde-noche: los hosts y enlaces saturados se delatan en horas punta.
• Fíjate en la regularidad, no en el mejor resultado: la dispersión dice más sobre la sobreventa que la media.
• Anota los resultados en una tabla; un mes después te ayudarán si el servidor empieza a ir lento.
• Juzga según tu tarea: para una web importan sobre todo el disco y la latencia hasta el público; para compilar código, la CPU; para almacenar archivos, el puerto.

Qué parámetros del plan revisar antes de las pruebas se explica en cómo elegir un VPS. Puedes filtrar planes con prueba gratuita, pago por horas y la ubicación adecuada en el buscador de VPS.