Traceroute vs Ping: What Each One Tells You, With Examples

Ping and traceroute both send packets and time the answers, but they answer different questions. Ping tells you whether a host responds and how long a round trip takes. Traceroute tells you which routers sit between you and that host, and where along the way the time is spent. Below, both tools run against the same host from the same server, a minute apart, followed by a table for choosing which one to run first.

The difference in one table

	Ping	Traceroute
Question it answers	Does the host answer, and how fast?	Which routers are on the path, and where does the delay build up?
What it sends	ICMP Echo Request	Packets with a growing TTL: UDP on Linux and macOS, ICMP on Windows (tracert)
Who answers	The destination only	Each router on the way (ICMP Time Exceeded), then the destination
Output	One time per packet, then loss and min/avg/max	One line per hop, three times per line
How long it runs	Until you stop it on Linux and macOS, 4 packets on Windows	A few seconds to a minute
Blind spot	Says nothing about where a delay comes from	One snapshot; middle hops can look slow or lossy without being so

Ping: one number, measured well

From our server in Falkenstein, Germany, to a Vultr test host in New Jersey, on 7 October 2026 at 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= is the round trip of each packet: about 86 ms, there and back.
• 0% packet loss and mdev 0.081 ms (the spread of the times): the path is stable. A healthy path within a continent often shows an mdev under 1 ms; values of tens of milliseconds point to congestion or Wi-Fi.
• ttl=50 is what remained of the reply's time-to-live when it arrived. If the host started at 64, the usual default on Linux, the reply crossed 14 routers on its way back, three more than the 11 hops traceroute counts on the way out (below). The way back is often a different route, and no tool run from your side can show it.

What ping cannot say is why it takes 86 ms. That is traceroute's job.

Traceroute: where the 86 ms come from

The same host, from the same server, a minute later, with the default UDP probes:

$ 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  * * *
[the same * * * on every line up to 30]
30  * * *

• The 86 ms appear at once, at hop 6. Hop 5 is nbg40, in Nuremberg, at 2.7 ms; hop 6 is nyk10, in New York, at 86.4 ms. Everything before is the trip across Germany, everything after stays at the same level: the time is the Atlantic. Ping could not have told you that.
• The times do not add up from hop to hop. Hop 3 answers in 3.9 ms and hop 4, further away, in 2.8 ms. Each line is a separate round trip answered by a different router, which takes its own time to reply.
• Silent lines are not breaks. Hop 1 and hops 7 to 9 never answer, yet hop 10 does: those routers just do not reply to probes.
• The last line never comes. After hop 10, only asterisks up to hop 30, although ping showed the host answering perfectly. This host does not reply to UDP probes. Sent as ICMP, like ping, the same trace reaches it:

$ 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

This is the most common misreading of a traceroute: a trace that ends in asterisks does not mean the host is down. Check with ping, then trace again with another protocol (-I for ICMP, or -T -p 443 for TCP on Linux, as root).

Which one to run first

Symptom	Start with	Then
"The site is down"	Ping the host, and a host known to work (1.1.1.1)	If ping fails, traceroute to see where it stops. Many hosts block ping: test the service itself (an HTTP or port check) before concluding
"It is slow"	Ping for 30 to 60 seconds: the average and the spread	Traceroute or mtr to find the hop where the time jumps and stays
"It drops sometimes"	A long ping (ping -c 300) for the loss rate	mtr -c 100 to see from which hop the loss starts
"Is it my network or theirs?"	Traceroute from your machine	The same trace from another location, and compare
Large transfers or VPN stall, small ones work	Ping with a full-size packet that must not be fragmented	Lower the size until it passes: that is the path MTU

The full-size test sends 1,472 bytes of data, which with 28 bytes of headers makes a 1,500-byte packet: ping -M do -s 1472 host on Linux, ping -D -s 1472 host on macOS, ping -f -l 1472 host on Windows.

Options that change the answer

• ping -c 20: stop after 20 packets (Windows: -n 20). -i 0.2 sends one packet every 0.2 seconds instead of every second.
• ping -W: the wait for each reply is in seconds on Linux and in milliseconds on macOS, a classic trap when a script moves between the two.
• -4 or -6 on Linux and Windows: force IPv4 or IPv6 (macOS has separate ping6 and traceroute6 commands). A host can be fast on one and slow on the other.
• traceroute -n: skip the reverse DNS lookups, much faster, but you lose the router names, which are often the best clue to where a hop is.

Where both fall short

• Only one direction. Both show the path from where you run them. The return path, which the TTL clue above shows to be different, stays invisible.
• Routers answer probes last. A hop that looks slow or lossy only matters if every hop after it, up to the destination, looks the same. This is explained with real examples in how to identify network bottlenecks.
• One point in time. A single run can miss an intermittent problem. mtr combines both tools and repeats the measurement on every hop.

To see the same comparison without a terminal, TraceMapper's ping and traceroute run from our servers and from more than 30 locations, with every hop placed on a map. For the commands on each system, see the traceroute command on Windows, Mac and Linux.