Ping vs Traceroute: Which One Answers Your Question?
2026-09-02 · 6 min
Every network complaint eventually starts the same way: something is unreachable, or it feels slow, and nobody can say yet whether the problem is yours, your provider's, or the destination's. Ping and traceroute are the two quickest ways to narrow that down - and they are so often confused that it is worth being precise about what each one can and cannot tell you.
The short version: ping answers 'how bad is it', traceroute answers 'where does it go wrong'. Used in that order, they resolve most connectivity complaints in under a minute.
1983
Ping is written
Mike Muuss writes the first ping at the US Army Ballistic Research Laboratory, wrapping the ICMP Echo Request/Reply pair - already defined in the ICMP specification - into a one-command measurement tool.
1987
Traceroute follows
Van Jacobson releases traceroute at Lawrence Berkeley Laboratory, exploiting the IP TTL field and ICMP Time Exceeded messages to reveal the routers on a path - something ping deliberately hides.
1998
The two combine
mtr (My Traceroute) merges both ideas into a continuously refreshing view that shows per-hop loss and latency statistics live, cementing the two-tool mental model.
Today
Same questions, new scale
The mechanics are unchanged; what changed is that web-based tools like NetChecks run them from a neutral third-party vantage point instead of your own machine.
What ping actually measures
Ping sends a small ICMP Echo Request to a destination and waits for the Echo Reply. The round-trip time (RTT) it reports covers the whole journey out and back, and running it several times in a row separates a one-off latency spike from a stable figure - which is why a good ping tool sends a burst, not a single packet.
Three numbers matter: the RTT itself (is the target near or far), the jitter between packets (is the path stable), and packet loss (are replies coming back at all). A missing reply is only meaningful evidence of downtime when loss is consistent - many networks deliberately deprioritize ICMP under load, so a single lost packet is noise, not an outage.
What traceroute adds: the path itself
Traceroute works by exploiting the IP time-to-live field. It sends packets with TTL=1, so the first router drops the packet and reports back an ICMP Time Exceeded message - revealing its address. It then repeats with TTL=2 to reveal the second router, and so on until the destination answers for real.
The result is the actual chain of routers between you and the target, each with its own latency. This is the part ping cannot give you: when 'the site is unreachable', traceroute is what tells you whether the break happens at your own router, at your ISP, at an exchange point, or at the destination's edge.
Ping measures one round trip to the destination; traceroute walks the path hop by hop by forcing every router to reveal itself.
Reading the strange results
A line of asterisks in traceroute is the most misread output in networking. Asterisks on an intermediate hop often mean that router simply does not answer ICMP probes, while traffic still flows through it fine - you can usually confirm this by seeing later hops respond normally. Only when the stars start at a hop and never recover is the path genuinely broken there.
Also expect asymmetry: the return path may be a completely different route than the outbound one, and each hop's latency is measured on the return leg. One hop showing a sudden 40 ms jump does not mean that router is slow - it can mean the slow link is anywhere up to and including that hop.
Which one, when
Start with ping: if RTT and loss look healthy toward a target, traceroute will not change the story, and you should look elsewhere (DNS, the server itself, the application). If ping shows loss or absurd latency, run traceroute immediately and look for the first hop where latency jumps or responses stop - that hop is your leading suspect.
One caveat traceroute users should know: filtering networks. Many firewalls rate-limit or drop ICMP, so a destination can be perfectly reachable over HTTPS while its traceroute ends in stars. If ping to the host works but traceroute does not complete, trust ping and move on.
要点总结
Ping tells you how bad the problem is; traceroute tells you where it lives. Run them in that order, read the asterisks with skepticism, and most 'the network is down' tickets resolve themselves before anyone has to guess.
为防止滥用，请求会受到频率限制。此实例的运营者可以选择性地启用请求活动日志记录——如果启用，每次工具请求（您的 IP 地址、时间戳、使用的工具及输入的目标/查询内容）可能会被记录到数据库中，用于安全、防滥用和使用情况分析。此功能默认关闭。使用本网站即表示您同意上述条款；如果您不同意，请不要使用本网站。