Cuando un servidor deja de responder o la conexión va lenta y a saltos, el equipo de soporte necesita datos concretos para localizar el problema: desde dónde te conectas, hacia qué IP y en qué salto de la ruta se pierden los paquetes. En esta guía aprenderás a hacer unas comprobaciones básicas y a generar informes MTR en ambos sentidos (desde tu equipo hacia el servidor y desde el servidor hacia ti) para adjuntarlos a un ticket de soporte de CubePath.

Requisitos previos

  • Un VPS o servidor dedicado de CubePath y acceso al panel de cliente.
  • La IP pública de tu servidor (your_server_ip), que aparece en la ficha del servidor en el panel.
  • En tu equipo: Linux, macOS o Windows con permisos para instalar software.
  • Para el MTR inverso: acceso SSH al servidor con un usuario con privilegios sudo.

Paso 1: Identificar el tipo de problema

Antes de abrir un ticket conviene saber cuál de estos dos casos tienes, porque los datos que necesita soporte son distintos:

SíntomaCasoQué hacer
No hay respuesta a SSH, web ni pingServidor inaccesiblePaso 2
Conecta, pero con cortes, lentitud o latencia variablePérdida de paquetesPasos 3 a 5

Una prueba rápida desde tu equipo te ayuda a decidir. Envía 20 paquetes ICMP al servidor:

ping -c 20 your_server_ip

En Windows usa ping -n 20 your_server_ip. Fíjate en la línea de resumen:

20 packets transmitted, 20 received, 0% packet loss, time 19027ms
rtt min/avg/max/mdev = 21.104/21.873/23.442/0.512 ms

Un 100% packet loss apunta a un servidor inaccesible. Un porcentaje intermedio o un mdev muy alto apuntan a pérdida de paquetes o congestión.

Paso 2: Si el servidor no es accesible

Muchos bloqueos (kernel colgado, falta de memoria, un servicio de red caído) se resuelven con un reinicio. Puedes hacerlo tú mismo desde el panel:

  1. Entra en el panel de cliente de CubePath y abre la sección de servidores.
  2. Selecciona el servidor afectado.
  3. Abre el menú de energía y elige la opción de reinicio (Reboot). Confirma la acción.

Espera uno o dos minutos y repite el ping del paso 1. Si el servidor sigue sin responder, puede que haya sido bloqueado por nuestra parte, por ejemplo por un aviso de abuso o por un ataque en curso. Revisa tu correo por si has recibido una notificación y abre un ticket de soporte indicando:

  • La IP y el nombre del servidor afectado.
  • Desde cuándo no responde y si has hecho cambios recientes (firewall, red, actualizaciones).
  • Que ya has probado a reiniciarlo desde el panel.

Paso 3: Generar un informe MTR en Linux o macOS

MTR combina ping y traceroute: envía paquetes a cada salto de la ruta y mide la pérdida y la latencia de cada uno. Así se ve si el problema está en tu proveedor, en un tránsito intermedio o cerca del servidor.

Instala MTR en Ubuntu o Debian:

sudo apt update
sudo apt install mtr-tiny

En macOS instálalo con Homebrew:

brew install mtr

Ejecuta el informe con 100 paquetes por salto. MTR necesita privilegios para enviar paquetes, por eso se usa sudo:

sudo mtr -rwzc 100 your_server_ip

Las opciones hacen lo siguiente:

  • -r: modo informe, imprime el resultado al terminar en lugar de la vista interactiva.
  • -w: no recorta los nombres de host.
  • -z: muestra el sistema autónomo (AS) de cada salto.
  • -c 100: envía 100 paquetes, unos 100 segundos de prueba.

En macOS, si el comando no se encuentra, Homebrew lo instala en sbin; ejecútalo como sudo $(brew --prefix)/sbin/mtr -rwzc 100 your_server_ip.

El resultado tiene este aspecto:

Start: 2026-09-25T10:12:03+0200
HOST: laptop                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.1.1              0.0%   100    1.2   1.4   0.9   4.1   0.4
  2. AS3352   10.34.0.1                0.0%   100    6.8   7.3   5.9  15.2   1.3
  3. AS3352   81.46.1.25               0.0%   100    7.9   8.4   7.1  12.8   0.9
  4. AS174    149.14.200.1             0.0%   100   15.3  15.9  14.8  22.4   1.1
  5. AS???    your_server_ip           4.0%   100   21.6  22.1  21.0  30.2   1.5

Para interpretarlo:

  • Solo importa la pérdida que continúa hasta el último salto. Un salto intermedio con pérdida y los siguientes al 0% suele ser un router que limita sus respuestas ICMP, no un problema real.
  • Si la pérdida empieza en los primeros saltos (tu router o tu proveedor), el problema está en tu lado de la conexión.

Si el servicio afectado usa TCP (por ejemplo una web en el 443), repite la prueba con paquetes TCP, que siguen la misma ruta que tu tráfico real y no se ven afectados por filtros de ICMP:

sudo mtr -rwzc 100 -T -P 443 your_server_ip

Copia la salida completa en texto (no una captura de pantalla) para el ticket.

Paso 4: Generar un informe MTR en Windows

Windows no incluye MTR, pero WinMTR ofrece la misma prueba con interfaz gráfica:

  1. Descarga WinMTR desde su página oficial y extrae el archivo ZIP.
  2. Ejecuta WinMTR.exe.
  3. En el campo Host, escribe la IP de tu servidor.
  4. Pulsa Start y deja que la prueba corra al menos 10 minutos, sobre todo si la pérdida es intermitente.
  5. Pulsa Stop y después Export TEXT para guardar el resultado en un archivo .txt.

Si no puedes instalar software, Windows trae pathping, que hace un análisis parecido. Abre PowerShell o el símbolo del sistema y ejecuta:

pathping -n your_server_ip

La prueba tarda varios minutos. Copia la salida completa, incluida la tabla final de estadísticas por salto.

Paso 5: Generar un MTR inverso desde el servidor

El tráfico de ida y el de vuelta no siempre siguen la misma ruta, así que un MTR desde el servidor hacia tu conexión muestra la otra mitad del problema.

Primero averigua la IP pública de tu conexión. Desde tu equipo (no desde el servidor) ejecuta:

curl -4 https://ifconfig.me

203.0.113.45

Esta es tu your_home_ip. Después conéctate al servidor por SSH, instala MTR si hace falta y lanza el informe hacia esa IP:

sudo apt install mtr-tiny
sudo mtr -rwzc 100 your_home_ip

Si tu router no responde a ICMP, el último salto aparecerá con un 100% de pérdida aunque la conexión funcione; en ese caso fíjate en los saltos anteriores. Si no puedes acceder al servidor, indica tu IP pública en el ticket y el equipo de soporte hará el trace inverso por ti.

Paso 6: Enviar el ticket de soporte

Abre un ticket desde el panel de cliente e incluye toda la información de una vez para evitar idas y vueltas:

  • La IP y el nombre del servidor afectado.
  • Tu IP pública y tu proveedor de Internet.
  • Fecha, hora y zona horaria en que ocurre el problema, y si es continuo o intermitente.
  • El informe MTR (o WinMTR) desde tu equipo hacia el servidor, en texto.
  • El MTR inverso desde el servidor hacia tu IP.
  • Qué servicio notas afectado (SSH, web, juego) y en qué puerto escucha.

Conclusión

Con un ping, un MTR en cada dirección y los datos del servidor, el equipo de soporte puede ver en qué salto se pierde el tráfico y si el problema está en tu proveedor, en un tránsito intermedio o en la red de CubePath. Como siguientes pasos, revisa las reglas de tu firewall perimetral y de UFW si el problema afecta solo a ciertos puertos, y guarda los informes de hoy como referencia para comparar si la incidencia se repite.