上周帮一个朋友排查他家里 NAS 远程访问慢的问题。他一口咬定是网络运营商搞鬼，我让他打开终端敲了条命令，网络三秒后真相大白——问题出在他自己路由器上，网络第三跳开始延迟直接飙到 200ms 以上。网络那条命令就是网络 tracert，Linux 和 macOS 下叫 traceroute。网络
网络这东西，网络平时不觉得，网络一出问题就抓瞎。网络ping 只能告诉你“通不通”，网络但 traceroute 能告诉你“怎么通的网络”。它把数据包从你机器到目标主机之间经过的网络每一跳路由器都列出来，附带每一跳的网络往返延迟。哪个节点开始变慢，网络哪个节点直接丢包，一目了然。
原理其实不复杂。IP 包头里有个 TTL 字段，每经过一个路由器就减一，减到零路由器就把包扔掉，同时回一个 ICMP 超时消息。traceroute 就利用这点：先发 TTL=1 的包，拿到第一个路由器的地址；再发 TTL=2 的，拿到第二个；以此类推，直到抵达目标。默认每个 TTL 发三个包，所以你会看到三列延迟数据。
Windows 下直接敲：
tracert example.com
Linux/macOS：
traceroute example.com
输出长这样（我随便跑一个）：
traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.234 ms 1.567 ms 1.890 ms 2 10.10.0.1 (10.10.0.1) 8.901 ms 9.123 ms 9.456 ms 3 * * * 4 202.97.12.1 (202.97.12.1) 35.678 ms 36.789 ms 37.012 ms 5 * * * 6 93.184.216.34 (93.184.216.34) 142.345 ms 143.567 ms 144.789 ms
第三跳和第五跳显示 * * *，意思是路由器没回 ICMP 超时消息，可能被防火墙拦了，也可能管理员故意禁了。这不代表断网，只是那台设备不配合。真正要关注的是延迟突然跳升的位置，或者某一跳之后所有包都丢了——那基本就是故障点。
我见过最离谱的一次，公司内网访问测试服务器延迟 800ms。traceroute 一跑，发现数据包先绕到广州，再转上海，最后才到北京机房。后来查出来是某台核心交换机的路由表配错了，把内网流量当公网流量走。改完配置延迟直接掉到 3ms。这种问题 ping 根本查不出来，因为 ping 只看通不通。
有个细节得注意：traceroute 默认用 UDP 包，有些网络设备对 UDP 不友好，结果可能不准。Linux 下可以加 -I 改用 ICMP，或者 -T 用 TCP。Windows 的 tracert 默认就是 ICMP，省心一些。另外，路径可能不对称——你去程走 A 线路，回程走 B 线路，traceroute 只测去程。真要全面排查，得两头都跑。
还有个小技巧：如果目标服务器禁 ping 也禁 traceroute，可以试试 traceroute -T -p 80 example.com，用 TCP 80 端口探测，很多防火墙对 80 端口放行。这招在排查网站访问问题时特别好使。
别指望 traceroute 能解决所有问题。它给的是路径和延迟快照，不是实时监控。网络抖动、间歇性丢包，单次 traceroute 可能看不出来。得配合 mtr（My Traceroute）这种持续探测工具，它把 traceroute 和 ping 揉在一起，实时刷新每一跳的丢包率和延迟波动。Linux 下 mtr example.com 就能跑，Windows 得装个 WinMTR。
说到底，traceroute 就是个网络手电筒。平时用不上，但半夜被告警吵醒说服务不可达的时候，它可能是你最快找到问题边界的工具。别一上来就重启路由器，先跑条命令看看包到底卡在哪儿。
```