--- title: "Cómo reportar problemas de red con MTR a soporte técnico" description: "Aprende a diagnosticar un servidor inaccesible o con pérdida de paquetes y a generar informes MTR directos e inversos en Linux, macOS y Windows para soporte." category: "Networking" language: es source: https://cubepath.com/es/docs/networking/instrucciones-para-enviar-reporte-de-error-con-problemas-de-red updated: 2026-09-25 --- # Cómo reportar problemas de red con MTR a soporte técnico 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íntoma | Caso | Qué hacer | |---|---|---| | No hay respuesta a SSH, web ni ping | Servidor inaccesible | Paso 2 | | Conecta, pero con cortes, lentitud o latencia variable | Pérdida de paquetes | Pasos 3 a 5 | Una prueba rápida desde tu equipo te ayuda a decidir. Envía 20 paquetes ICMP al servidor: ```bash ping -c 20 your_server_ip ``` En Windows usa `ping -n 20 your_server_ip`. Fíjate en la línea de resumen: ```output 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. > Nota: si has creado una regla en el firewall perimetral que descarta ICMP, el ping fallará aunque el servidor funcione. En ese caso prueba también el puerto de tu servicio, por ejemplo con `nc -vz your_server_ip 22`. ## 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: ```bash sudo apt update sudo apt install mtr-tiny ``` En macOS instálalo con Homebrew: ```bash brew install mtr ``` Ejecuta el informe con 100 paquetes por salto. MTR necesita privilegios para enviar paquetes, por eso se usa `sudo`: ```bash 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: ```output 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: ```bash 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: ```bash 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: ```bash curl -4 https://ifconfig.me ``` ```output 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: ```bash 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.