> La lista completa de artículos está en [llms.txt](https://docs.f3cloud.com/llms.txt). Cada página tiene versión en Markdown, basta con añadir .md a su dirección. Esta página en Markdown: [https://docs.f3cloud.com/es/vps/network-troubleshooting-traceroute.md](https://docs.f3cloud.com/es/vps/network-troubleshooting-traceroute.md). # Diagnóstico de red – traceroute y calidad de la conexión (WinMTR, MTR, Speedtest) Cómo comprobar la calidad de la conexión con tu servidor. Speedtest en el VPS, traceroute con WinMTR desde tu PC, MTR inverso, cómo leer los resultados y qué enviar al soporte. Esta guía te ayudará a entender rápidamente dónde exactamente se «pierden» los milisegundos y los paquetes – en el lado del proveedor del usuario, en la red troncal, en el centro de datos o ya en el propio servidor. > **Importante.** > > **Antes de empezar**, desactiva la VPN o el proxy y cualquier «acelerador» de red en el ordenador y en el servidor. \ > Haz las pruebas con una carga estable – sin descargas ni streams en marcha. *** ### Paso 1. Prueba de velocidad en el servidor (Speedtest) Conéctate al servidor por SSH y ejecuta: ```bash wget -qO- bench.sh | bash ``` Cuando termine, haz una captura de pantalla del resultado y adjúntala al ticket. \ **No hace falta enviar la salida en texto.** > **Importante.** > > Esto es importante porque el comando lanza una prueba automática que mide la velocidad de la conexión de red y muestra las características básicas del servidor – con los resultados se puede valorar la calidad del canal y detectar posibles limitaciones. *** ### Paso 2. Traceroute desde tu PC hasta el servidor (WinMTR) #### Windows (WinMTR) 1. **Desactiva la VPN.** 2. Descarga **WinMTR** desde su web oficial `https://winmtr.net/`. 3. Abre WinMTR y en el campo **Host** indica **la IP de tu servidor**. 4. Pulsa **Start** y espera a que pasen 100–200 paquetes (1–3 minutos). 5. Pulsa **Stop**. 6. **Envía una captura del resultado en el ticket.** > **Atención.** > > Si necesitas «cazar» picos de latencia poco frecuentes, te recomendamos aumentar la duración a 5–10 minutos. > > Algunos routers o nodos pueden no responder a las sondas ICMP – una sola «pérdida» en un salto intermedio **no siempre** significa un problema. Importan más los últimos saltos y la «herencia» de las pérdidas a lo largo de la ruta (consulta la sección «Cómo leer los resultados»). #### macOS / Linux (alternativa) Si no tienes Windows a mano, puedes hacer un traceroute equivalente con la utilidad **mtr**: **macOS (Homebrew)** ```bash brew install mtr sudo mtr -rw ``` **Linux (escritorio)** ```bash sudo apt update && sudo apt install -y mtr sudo mtr -rw ``` Espera a que pasen 100–200 paquetes y guarda la salida en un archivo: ```bash sudo mtr -rw | tee mtr-to-server.txt ``` Adjunta una captura al ticket. > **Atención.** > > Algunos routers o nodos pueden no responder a las sondas ICMP – una sola «pérdida» en un salto intermedio **no siempre** significa un problema. Importan más los últimos saltos y la «herencia» de las pérdidas a lo largo de la ruta (consulta la sección «Cómo leer los resultados»). *** ### Paso 3. Traceroute inverso desde el servidor hasta tu PC (MTR) En el servidor, ejecuta: ```bash sudo apt update && sudo apt install -y mtr && mtr -rw ``` En lugar de ``, indica **la IP real de tu ordenador** (no la de la VPN). Es fácil averiguarla, basta con entrar en `https://2ip.ru/`. Haz una captura de los resultados y adjúntala a tu solicitud: ```bash mtr -rw | tee mtr-to-client.txt ``` > **Atención.** > > La pareja «WinMTR directo» + «MTR inverso» permite ver el problema desde los dos extremos de la ruta y localizar antes el tramo con pérdidas o jitter. *** ### Cómo leer los resultados en pocas palabras * **Loss% (pérdidas)** – lo importante no es fijarse en un solo **salto**, sino en la «herencia» de las pérdidas. Si aparecen pérdidas en el salto n.º n y se mantienen en todos los siguientes, el problema, por regla general, empieza en el n.º n o después. Si se ven pérdidas en un salto pero en el siguiente ya no las hay, lo más habitual es que el nodo intermedio limite las respuestas **ICMP (rate limit)**, y eso no significa una pérdida real de tráfico. * **Latency (Best/Avg/Wrst/Last)** – fíjate en los valores de los últimos saltos y en la tendencia general. Un aumento constante de la latencia y los picos cerca del final de la ruta suelen indicar congestión en la ruta, más cerca del segmento de destino o en la «última milla». * **Jitter (variación)** – una gran diferencia entre Best y Wrst en los últimos saltos es señal de una conexión inestable. > **Explicación de los términos:** > > **salto** – un nodo intermedio en el camino desde tu dispositivo hasta el servidor; > > **ICMP** – respuestas de servicio de la red, «de diagnóstico» (se usan en ping/traceroute); > > **rate limit** – límite de frecuencia de las respuestas (el nodo puede no responder a todas las peticiones); > > **tendencia** – cómo cambian en general los valores (suben, bajan o van a saltos); > > **picos** – aumentos bruscos y breves de la latencia; > > **última milla** – el tramo de la red más cercano al usuario final (aquí suelen influir el proveedor o la red local). > **Atención.** > > Si no tienes claro cómo interpretarlos, simplemente adjunta los resultados de Speedtest, WinMTR y MTR – los analizaremos y te responderemos con conclusiones y recomendaciones. *** ### Qué enviar al soporte de F3 Cloud Reúne todo en una sola solicitud (ticket o correo) y adjunta: 1. La dirección IP de tu servidor, además de tu ubicación y tu proveedor (del lado del cliente). 2. La fecha y la hora aproximada en que se observó el problema (con la zona horaria). 3. El resultado de Speedtest desde el servidor – una captura. 4. El resultado de WinMTR (PC → servidor) – una captura. 5. El resultado de MTR (servidor → PC) – una captura. 6. Otras observaciones, si las hay, como «bajones en los juegos», «cortes del stream o de la videollamada», si depende de la hora del día, etc. *** ### Preguntas frecuentes (FAQ)
WinMTR muestra un 100% de pérdidas en uno de los saltos intermedios – ¿es grave? No necesariamente. Muchos routers intermedios limitan o ignoran las respuestas a las peticiones de diagnóstico (ICMP), y por eso WinMTR puede mostrar «pérdidas» justo en ese salto. Fíjate en dos señales: 1. Si en los saltos siguientes (y sobre todo en el último, el de destino) no hay pérdidas – por regla general es una particularidad de cómo responde el router y no es un problema. 2. Si las pérdidas o el aumento de la latencia se mantienen en los saltos siguientes y llegan hasta el final de la ruta – eso ya es señal de un problema real en la ruta.
El comando mtr no aparece en el servidor Instala mtr con un solo comando para tu sistema operativo. Debian/Ubuntu: ```bash sudo apt update && sudo apt install -y mtr ``` CentOS Stream/Rocky Linux/AlmaLinux: ```bash sudo dnf install -y mtr ```
¿Cuánto tiempo hay que dejar el traceroute? Normalmente bastan 1–3 minutos para ver una imagen estable (unos 100–200 paquetes). Si el problema es «intermitente» (es decir, no aparece siempre), aumenta la duración de la prueba a 5–10 minutos y adjunta una captura del resultado.
*** ### Buenas prácticas * **Haz las pruebas siempre en las mismas condiciones**, con la misma red, el mismo dispositivo y, si es posible, conexión por cable. Es importante porque el Wi-Fi, los distintos dispositivos y los distintos puntos de acceso pueden dar ping, pérdidas y velocidad diferentes – y los resultados dejan de ser comparables. * No lances Speedtest y el traceroute (WinMTR/MTR) a la vez – hazlos uno detrás de otro. Las pruebas en paralelo cargan más el canal y pueden empeorar los valores de forma artificial (la velocidad «se recorta», la latencia sube), y el diagnóstico sale mal. * Haz las pruebas en el momento en que el problema se está dando de verdad (por ejemplo, «por la tarde hay bajones», «en el juego el ping va a saltos»). Las pruebas «cuando todo va bien» a menudo no captan la causa y no ayudan en la investigación. * Haz las capturas de forma que se vean los datos clave, como la IP o la dirección del servidor (si aparece), la tabla de resultados y los valores finales. Mejor no captar nada más (pestañas personales, notificaciones, chats) – selecciona solo la zona con el resultado. * Si tienes varias redes o dispositivos (casa, oficina, LTE, distintos proveedores, distintos routers), envía un juego de pruebas de cada red por separado e indica claramente dónde se hizo cada prueba (por ejemplo, «Wi-Fi de casa, Rostelecom», «oficina, cable», «LTE de MTS»). Así se ve si el problema está ligado a una red o un proveedor concretos o se reproduce en todas partes. * Si usas VPN o proxy en tu lado, desactívalos mientras dura el diagnóstico o indica claramente en el ticket que las pruebas se hicieron a través de VPN o proxy. Es importante porque la VPN cambia la ruta y puede añadir latencia, lo que distorsiona los resultados.