Traceroute vs ping: qué te dice cada uno, con ejemplos

Tanto ping como traceroute envían paquetes y cronometran las respuestas, pero contestan a preguntas distintas. Ping te dice si un host responde y cuánto tarda una ida y vuelta. Traceroute te dice qué routers hay entre tú y ese host, y en qué punto del camino se va el tiempo. Más abajo, las dos herramientas se lanzan contra el mismo host desde el mismo servidor, con un minuto de diferencia, y después una tabla te ayuda a elegir cuál ejecutar primero.

La diferencia en una tabla

	Ping	Traceroute
Pregunta a la que responde	¿Responde el host y con qué rapidez?	¿Qué routers hay en la ruta y dónde se acumula el retardo?
Qué envía	ICMP Echo Request	Paquetes con un TTL creciente: UDP en Linux y macOS, ICMP en Windows (tracert)
Quién responde	Solo el destino	Cada router del camino (ICMP Time Exceeded) y después el destino
Salida	Un tiempo por paquete y, al final, la pérdida y min/avg/max	Una línea por salto, tres tiempos por línea
Cuánto dura	Hasta que lo detienes en Linux y macOS; 4 paquetes en Windows	De unos segundos a un minuto
Punto ciego	No dice nada de dónde se produce un retardo	Una sola instantánea; los saltos intermedios pueden parecer lentos o con pérdidas sin serlo

Ping: una sola cifra, bien medida

Desde nuestro servidor de Falkenstein, Alemania, hacia un host de prueba de Vultr en Nueva Jersey, el 7 de octubre de 2026 a las 12:27 UTC:

$ ping -c 10 nj-us-ping.vultr.com
PING nj-us-ping.vultr.com (108.61.149.182) 56(84) bytes of data.
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=1 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=2 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=3 ttl=50 time=86.4 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=4 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=5 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=6 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=7 ttl=50 time=86.3 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=8 ttl=50 time=86.2 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=9 ttl=50 time=86.1 ms
64 bytes from 108.61.149.182.vultrusercontent.com (108.61.149.182): icmp_seq=10 ttl=50 time=86.2 ms

--- nj-us-ping.vultr.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9410ms
rtt min/avg/max/mdev = 86.113/86.212/86.360/0.081 ms

• time= es el tiempo de ida y vuelta de cada paquete: unos 86 ms entre ir y volver.
• 0% packet loss y mdev 0,081 ms (la dispersión de los tiempos): la ruta es estable. Una ruta sana dentro de un continente suele mostrar un mdev inferior a 1 ms; valores de decenas de milisegundos apuntan a congestión o al Wi-Fi.
• ttl=50 es lo que quedaba del TTL (time-to-live) de la respuesta cuando llegó. Si el host partió de 64, el valor por defecto habitual en Linux, la respuesta atravesó 14 routers en su camino de vuelta, tres más que los 11 saltos que cuenta traceroute a la ida (más abajo). La vuelta suele seguir una ruta distinta, y ninguna herramienta lanzada desde tu lado puede mostrarla.

Lo que ping no puede decir es por qué tarda 86 ms. Ese es el trabajo de traceroute.

Traceroute: de dónde salen los 86 ms

El mismo host, desde el mismo servidor, un minuto después, con las sondas UDP por defecto:

$ traceroute nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  * * *
 2  ex9k1.dc11.fsn1.hetzner.com (213.133.117.208)  0.517 ms  0.318 ms  0.291 ms
 3  core23.fsn1.hetzner.com (213.133.126.23)  3.999 ms  3.920 ms  3.834 ms
 4  juniper4.dc2.nbg1.hetzner.com (213.239.252.233)  2.806 ms juniper5.dc2.nbg1.hetzner.com (213.239.252.245)  2.854 ms juniper5.dc2.nbg1.hetzner.com (213.239.254.218)  2.959 ms
 5  ae12-498.nbg40.core-backbone.com (5.56.20.253)  2.763 ms  2.687 ms  2.666 ms
 6  ae7-2093.nyk10.core-backbone.com (81.95.9.195)  86.557 ms  86.413 ms  86.437 ms
 7  * * *
 8  * * *
 9  * * *
10  66.55.138.149.vultrusercontent.com (66.55.138.149)  85.763 ms  85.862 ms  85.692 ms
11  * * *
12  * * *
[el mismo * * * en todas las líneas hasta la 30]
30  * * *

• Los 86 ms aparecen de golpe, en el salto 6. El salto 5 es nbg40, en Núremberg, a 2,7 ms; el salto 6 es nyk10, en Nueva York, a 86,4 ms. Todo lo anterior es el trayecto por Alemania y todo lo posterior se mantiene en el mismo nivel: ese tiempo es el Atlántico. Ping no te lo habría podido decir.
• Los tiempos no se suman de un salto a otro. El salto 3 responde en 3,9 ms y el salto 4, más lejos, en 2,8 ms. Cada línea es una ida y vuelta independiente a la que responde un router distinto, que se toma su propio tiempo para contestar.
• Las líneas silenciosas no son cortes. El salto 1 y los saltos 7 a 9 nunca responden y, sin embargo, el salto 10 sí: esos routers simplemente no contestan a las sondas.
• La última línea no llega nunca. Después del salto 10, solo asteriscos hasta el salto 30, aunque ping mostraba que el host respondía perfectamente. Este host no contesta a las sondas UDP. Enviada en ICMP, como ping, la misma traza sí lo alcanza:

$ traceroute -I -n -q 1 nj-us-ping.vultr.com
traceroute to nj-us-ping.vultr.com (108.61.149.182), 30 hops max, 60 byte packets
 1  *
 2  213.133.117.208  0.372 ms
 3  213.133.126.22  0.357 ms
 4  213.239.254.238  2.813 ms
 5  81.95.15.5  2.710 ms
 6  81.95.9.195  86.418 ms
 7  *
 8  *
 9  *
10  66.55.138.149  85.749 ms
11  108.61.149.182  85.975 ms

Es la lectura errónea más habitual de un traceroute: una traza que termina en asteriscos no significa que el host esté caído. Compruébalo con ping y vuelve a trazar con otro protocolo (-I para ICMP, o -T -p 443 para TCP en Linux, como root).

Cuál ejecutar primero

Síntoma	Empieza por	Después
«La web está caída»	Ping al host y a otro que sepas que funciona (1.1.1.1)	Si ping falla, traceroute para ver dónde se detiene. Muchos hosts bloquean ping: prueba el propio servicio (una comprobación HTTP o de puerto) antes de sacar conclusiones
«Va lento»	Ping durante 30 a 60 segundos: la media y la dispersión	Traceroute o mtr para encontrar el salto en el que el tiempo sube de golpe y se mantiene
«A veces se corta»	Un ping largo (ping -c 300) para la tasa de pérdida	mtr -c 100 para ver a partir de qué salto empieza la pérdida
«¿Es mi red o la suya?»	Traceroute desde tu equipo	La misma traza desde otra ubicación, y compara
Las transferencias grandes o la VPN se cuelgan, las pequeñas funcionan	Ping con un paquete de tamaño completo que no se pueda fragmentar	Reduce el tamaño hasta que pase: esa es la MTU de la ruta

La prueba de tamaño completo envía 1.472 bytes de datos, que con 28 bytes de cabeceras forman un paquete de 1.500 bytes: ping -M do -s 1472 host en Linux, ping -D -s 1472 host en macOS, ping -f -l 1472 host en Windows.

Opciones que cambian la respuesta

• ping -c 20: se detiene tras 20 paquetes (en Windows, -n 20). -i 0.2 envía un paquete cada 0,2 segundos en lugar de uno por segundo.
• ping -W: la espera de cada respuesta se expresa en segundos en Linux y en milisegundos en macOS, una trampa clásica cuando un script pasa de un sistema a otro.
• -4 o -6 en Linux y Windows: fuerzan IPv4 o IPv6 (macOS tiene comandos aparte, ping6 y traceroute6). Un host puede ser rápido en uno y lento en el otro.
• traceroute -n: omite las consultas de DNS inverso, mucho más rápido, pero pierdes los nombres de los routers, que a menudo son la mejor pista de dónde está un salto.

Dónde se quedan cortas las dos

• Una sola dirección. Las dos muestran la ruta desde donde las ejecutas. La ruta de vuelta, que según la pista del TTL de más arriba es distinta, sigue siendo invisible.
• Los routers atienden las sondas en último lugar. Un salto que parece lento o con pérdidas solo importa si todos los saltos posteriores, hasta el destino, muestran lo mismo. Lo explicamos con ejemplos reales en cómo identificar cuellos de botella en la red.
• Un único momento. Una sola ejecución puede pasar por alto un problema intermitente. mtr combina las dos herramientas y repite la medición en cada salto.

Para ver la misma comparación sin terminal, el ping de TraceMapper y su traceroute se ejecutan desde nuestros servidores y desde más de 30 ubicaciones, con cada salto situado en un mapa. Para los comandos de cada sistema, consulta el comando traceroute en Windows, Mac y Linux.