mtr vs Traceroute: Cuándo usar cada herramienta
8 min de lectura - 13 de mayo de 2026

Cómo funcionan traceroute y mtr, cómo leer sus resultados correctamente y cuándo utilizar cada uno de ellos para el diagnóstico de redes
mtr vs traceroute
Traceroute y mtr son herramientas de línea de comandos para diagnosticar problemas en las rutas de red. Traceroute te da una instantánea de la ruta que siguen tus paquetes. mtr hace lo mismo pero sigue sondeando, acumulando estadísticas sobre pérdida de paquetes, latencia y fluctuación de fase a lo largo del tiempo. Este artículo explica cómo funciona cada herramienta, cómo leer los resultados y cuándo utilizar cada una.
Cómo funciona traceroute
Traceroute utiliza el campo Time-to-Live (TTL) de las cabeceras de los paquetes IP. Envía un paquete con TTL establecido en 1. El primer router disminuye el TTL a cero, descarta el paquete y devuelve un mensaje ICMP "Time Exceeded". Traceroute registra la IP del enrutador y el tiempo de ida y vuelta, luego envía otro paquete con TTL establecido en 2, y así sucesivamente hasta que el paquete llega al destino o alcanza el límite máximo de saltos (30 por defecto, ajustable con -m).
Por defecto, traceroute envía tres sondas por salto, dándole tres lecturas de latencia. Los protocolos difieren según el sistema operativo:
- Windows: El comando
tracertenvía ICMP Echo Requests. - Linux/macOS: El comando
tracerouteenvía datagramas UDP (puertos 33434-33534). Utilice-Ipara ICMP o-Tpara TCP si UDP está bloqueado.
Si se añade el indicador -n, se omiten las búsquedas DNS inversas, lo que acelera notablemente las cosas en rutas con muchos saltos.
Cómo funciona mtr
mtr (My Traceroute) utiliza el mismo descubrimiento de rutas basado en TTL que traceroute, pero sigue enviando sondas, normalmente una por segundo. En lugar de tres puntos de datos por salto, se obtienen estadísticas de ejecución: porcentaje de pérdida de paquetes, latencia media, mejores y peores tiempos de respuesta y desviación estándar (fluctuación).
mtr admite sondas ICMP (por defecto), UDP y TCP SYN. El modo TCP es útil cuando los cortafuegos bloquean ICMP, o cuando se quiere probar un puerto de aplicación específico:
mtr --tcp --port 443 example.comPara un informe no interactivo que pueda compartir con un equipo de soporte, utilice el modo informe:
mtr --report --report-cycles 100 example.comEste modo ejecuta 100 sondas e imprime un resumen. También puede configurar tamaños de paquetes personalizados con --psize para comprobar problemas de MTU o fragmentación.
mtr funciona de forma nativa en Linux y macOS. Los usuarios de Windows pueden utilizar WinMTR para una GUI equivalente.
Principales diferencias
| Función | Traceroute | mtr |
|---|---|---|
| Recogida de datos | Una sola vez, 3 sondas por salto | Ciclos continuos configurables |
| Pérdida de paquetes | No se rastrea por salto | Medida por salto |
| Métricas de latencia | Tres valores RTT por salto | Última, media, mejor, peor, desviación estándar |
| Fluctuación (StDev) | No se mide | Medido por salto |
| Protocolos | ICMP, UDP | ICMP, UDP, TCP SYN |
| Salida | Texto estático | Modo de actualización en directo o de informe |
La diferencia práctica se reduce a los problemas intermitentes. Un simple traceroute puede fácilmente pasar por alto un router que pierde el 2% de los paquetes o un salto con 15ms de jitter. mtr los detecta porque sigue midiendo.
Lectura de los resultados
El error más común al leer la salida de traceroute o mtr es asumir que un salto intermedio de aspecto problemático significa que hay un problema real. Normalmente no es así.
Los asteriscos (*) en traceroute significan que el router no respondió a la sonda. Muchos routers están configurados para ignorar o limitar la tasa de ICMP. Si los siguientes saltos responden normalmente, la ruta está bien.
Lapérdida de paquetes en un solo salto en mtr sigue la misma lógica. Si el salto 5 muestra un 20% de pérdida pero el destino final muestra un 0%, ese router está simplemente despriorizando las respuestas de la sonda. La pérdida real de paquetes se muestra como un patrón: la pérdida aparece en un salto y persiste en todos los saltos siguientes hasta el destino.
Los saltos de latencia entre saltos son normales y esperados. Un salto de 10 ms a 80 ms suele significar que el paquete cruzó un océano o una larga ruta terrestre. Preocúpate de la latencia sólo si es inusualmente alta para la distancia (menos de 5 ms dentro de un área metropolitana, decenas de milisegundos campo a través, 80-150 ms transoceánica) o si la latencia del destino final es inaceptable.
Merece la pena prestar atenciónal StDev (jitter) en mtr. Valores superiores a 10 ms en cualquier salto pueden causar problemas en VoIP, videollamadas y juegos. Si observas un jitter elevado, ejecuta al menos 100 ciclos para confirmar que se trata de un patrón sostenido y no de un breve pico.
Cuándo utilizar cada herramienta
Utiliza traceroute cuando necesites una respuesta rápida: ¿se puede llegar al destino y, si no, dónde se interrumpe la ruta? Es el punto de partida adecuado para las interrupciones y para verificar el enrutamiento básico.
Utilice mtr cuando el problema sea intermitente o esté relacionado con el rendimiento. Los usuarios que informan de desconexiones ocasionales, problemas de calidad de VoIP o picos de latencia necesitan los datos continuos de mtr. Ejecute al menos 50-100 ciclos para obtener estadísticas fiables.
Para un diagnóstico completo, ejecute mtr en ambas direcciones: desde su máquina al servidor, y desde el servidor de vuelta a su IP. El enrutamiento en Internet es asimétrico, por lo que la ruta de retorno puede tener características completamente diferentes. Si sólo pruebas una dirección, puede que no veas dónde está realmente el problema.
Si tiene problemas con su servidor dedicado o VPS, los equipos de soporte de FDC Servers aceptan informes mtr como prueba de diagnóstico estándar para escaladas de red.

¿Cansado de despliegues lentos o límites de ancho de banda? FDC Servers ofrece potencia dedicada instantánea, alcance global y planes flexibles diseñados para cualquier escala. ¿Listo para actualizar?
Libere el rendimiento ahora
Lista de comprobación para el refuerzo de servidores Linux
Lista de comprobación paso a paso para reforzar un servidor Linux. Cubre SSH, cortafuegos, parches, permisos de archivos, SELinux/AppArmor y registro de auditorías
15 min de lectura - 8 de mayo de 2026
tutorial de iperf3: Prueba de velocidad de red en Linux y Windows
10 min de lectura - 7 de mayo de 2026