网络卡，你得知道它坏在哪一环，而不是只知道「它坏了」。Traceroute 给你看路径，MTR 给你看路径，还能告诉你每一跳的健康程度。这篇文章把两个工具都讲一遍，怎么读、怎么用，以及 IPIPAI 的 trace_route 工具怎么把同样的洞察搬到浏览器里，不用开终端。
Traceroute 到底干了什么
Traceroute（Windows 上叫 tracert）的原理是发一批 TTL 递增的数据包。第一个包死在第一个路由器，第二个死在第二个，依次往下。每个杀死数据包的路由器会回一个「ICMP 超时报文」，traceroute 记下这个报文来自哪个路由器。跑够多轮，你就拿到一条从你自己到目的地的编号路径。
这有用，但只是一次快照。你能看到路径，却不知道第 7 跳这周是不是丢 40% 的包，也不知道第 3 跳是不是因为一条坏网线多出了 80 毫秒。
MTR 多给了什么
MTR（My Traceroute）是 Linux 上的工具，它持续跑 traceroute，对每一跳维护一张滚动统计表。除了每跳一行，还有一列小指标：发送包数、接收数、丢包率，以及延迟的几个分位（LAST、BEST、AVG、WORST，外加 STDDEV）。因为它一直在跑，那种「每隔几个包才丢一次」的抖动线路就不会藏在单次探测里了。
读 MTR 是个技术活。最关键的三列是：
- Loss %（丢包率）——如果某跳显示 30–100% 丢包，但下一跳是好的，多半是这跳在限 ICMP（运营商路由器很常见），不是真坏了。真正的问题在于丢包率到目的地之前什么时候才恢复正常。
- AVG（平均延迟）——这一跳的平均 RTT。相邻两跳从 2ms 跳到 120ms，说明慢的那条链就是它们之间。
- WORST（最差值）——尾延迟。平时一片绿、偶尔冒 900ms 的尖刺，通常是包乱序或者某个对等点拥塞。
MTR 还是 Traceroute？什么时候用哪个
| Traceroute | MTR | |
|---|---|---|
| 目的 | 找路径 | 找坏链路 + 有多坏 |
| 运行方式 | 单次 | 持续滚动窗口 |
| 延迟数据 | 每跳一个值 | 最小 / 平均 / 最大 / 标准差 |
| 丢包 | 不测 | 每跳丢包率 |
| 适合 | "这条路走哪？" | "到底哪段伤得最重？" |
实操里我一般先 traceroute 看路径的地理走向，再用 MTR 去压测那几个可疑的跳。
不开终端也能跑
要是你手边不是台 Linux，IPIPAI 的 Traceroute 工具能在浏览器里给你同样的逐跳视图。输入目的地，它会一路走下来，能解析的时候把每一跳标上名字和归属国家，「这是哪个路由器」的答案立刻就有了，不用 SSH。
要在每一跳做延迟压测，IPIPAI 的 Ping 工具和 ping_host 接口可以让你朝某个 IP 发包，读回 RTT、抖动、丢包。两个配合着用：用 traceroute 找到那一跳，再 ping 它把数字量化出来。
几种常见现象，分别说明什么
路径中间一片问号
某跳显示 ??? 或 * * *，是那个路由器不回应 ICMP。这不是故障——很多中转商故意把 ICMP 静音省 CPU。只要它后面的跳还正常，路径就是好的。
某一跳丢包很大，下一跳却干净
几乎总是 ICMP 限速，不是真断。网络多半是好的，只是诊断被限速了。看目的地的统计就行。
丢包到目的地附近才降下来
这是真正伤人的那种。靠近最后几跳持续丢包，说明路径末端或者目的地本身在丢包。用户感知到的卡顿就出在这。
收尾
Traceroute 回答「走哪边」，MTR 回答「哪段坏、坏多严重」。两个一起用，就不用瞎猜了。IPIPAI Traceroute 工具在浏览器里给你路径，Ping 工具给你数字，而目的地本身是个域名的时候，DNS 查询就是自然的下一站。更多工具都在 IPIPAI 文章页。