Prueba MTR en Mac OS
MTR combina ping y traceroute en una sola herramienta. Envía paquetes de prueba a un host de destino y muestra la latencia y la pérdida de paquetes en cada router (salto, o hop) a lo largo de la ruta. Esto ayuda a ver dónde empieza un problema de red: en su red local, en su proveedor, en un operador de tránsito o cerca del servidor.
El soporte de INTROSERV suele pedir un informe de MTR cuando un cliente notifica baja velocidad, latencia o pérdida de paquetes. Esta guía muestra cómo instalar MTR en macOS, ejecutar una prueba y guardar el informe. En Windows, utilice WinMTR en su lugar; consulte Comprobación del canal con WinMTR.
Instalar Homebrew
macOS no incluye MTR, por lo que debe instalarlo con el gestor de paquetes Homebrew. Si Homebrew ya está instalado, omita este paso.
Abra la aplicación Terminal y ejecute el comando de instalación del sitio web oficial de Homebrew:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
El instalador solicita la contraseña de su usuario de macOS y puede ofrecer instalar las Command Line Tools for Xcode. Confírmelo. Al final, siga las instrucciones de la sección «Next steps» de la salida: añaden Homebrew a su PATH.
Compruebe la instalación:
brew --version
Instalar MTR
Instale MTR:
brew install mtr
Homebrew instala MTR en la carpeta sbin dentro de su propio directorio: /opt/homebrew/sbin en los Mac con Apple silicon y /usr/local/sbin en los Mac con procesador Intel. MTR necesita derechos de administrador para enviar paquetes de prueba, así que ejecútelo con sudo y la ruta completa. El siguiente comando obtiene la ruta automáticamente:
sudo "$(brew --prefix)/sbin/mtr" --version
La salida muestra la versión instalada de MTR.
Ejecutar la prueba
Antes de la prueba, desactive cualquier VPN en su ordenador y, si es posible, conéctelo por cable en lugar de por Wi-Fi. Así evitará factores adicionales que puedan afectar al resultado. Ejecute MTR hacia su servidor y sustituya YOUR_SERVER_IP por su dirección IP o nombre de dominio:
sudo "$(brew --prefix)/sbin/mtr" -c 1000 YOUR_SERVER_IP
La opción -c 1000 ejecuta 1000 ciclos de prueba, uno por segundo, y recopila estadísticas de cada salto. Una prueba más larga ofrece una imagen más representativa de la pérdida de paquetes, pero tarda unos 17 minutos. Para una comprobación rápida puede usar -c 100, pero envíe al soporte el resultado de la prueba completa.

Mientras la prueba está en curso, MTR actualiza la tabla en pantalla. Para detener la prueba antes de que se completen los 1000 ciclos, pulse q.
Guardar el informe
Para enviar los resultados al soporte, ejecute MTR en modo informe y guarde la salida en un archivo:
sudo "$(brew --prefix)/sbin/mtr" -r -c 1000 -w YOUR_SERVER_IP > mtr-report.txt
La opción -r activa el modo informe y la opción -w muestra en el informe los nombres de host completos, sin recortarlos. En modo informe, la pantalla permanece vacía hasta que termina la prueba. Cuando el comando finaliza, el archivo mtr-report.txt se guarda en la carpeta actual. Si acaba de abrir Terminal, normalmente es su carpeta personal. Adjunte el archivo a su solicitud de soporte.
Para comprobar ambos sentidos de la ruta, ejecute también MTR desde el servidor hacia su ordenador.
Consulte Identificar un problema de red.
Interpretar los resultados
Cada fila de la tabla es un salto de la ruta y la última fila es el host de destino. Las columnas principales son:
- Loss% muestra el porcentaje de paquetes que no recibieron respuesta;
- Snt muestra el número de paquetes enviados;
- Last, Avg, Best y Wrst muestran la latencia del último paquete, la media, la mejor y la peor latencia en milisegundos;
- StDev muestra cuánto varía la latencia.
La pérdida en un salto intermedio que no continúa en los saltos siguientes normalmente no es un problema: muchos routers dan baja prioridad a los paquetes de prueba o limitan la frecuencia con que responden. Si la pérdida comienza en un salto y continúa en los siguientes hasta el host de destino, puede indicar pérdida de paquetes a partir de ese punto de la ruta. Un aumento brusco de la latencia que se mantiene alto en los saltos siguientes, incluido el host de destino, puede indicar un retraso o una congestión a partir de ese punto de la ruta.