博客 / 网络基础

traceroute 怎么看：星号、中间跳丢包和延迟突增分别说明什么

2026-10-22cdnping 编辑部约 6 分钟读完

traceroute 怎么看，可以先记住一条：先看最后一跳，再看问题是不是从某一跳开始一直持续到最后。中间某一跳出现星号、丢包或者延迟偏高，只要后面的跳恢复正常，大多数情况下只是那台路由器不愿意回应探测包，不代表你的流量在那里出了问题。

#traceroute 是怎么得到每一跳的？

traceroute 发出一串 TTL（IPv6 里叫 hop limit）依次为 1、2、3……的探测包。每经过一台路由器，TTL 减 1，减到 0 时这台路由器丢掉包，并回一个 ICMP “超时”消息。traceroute 收到这个回复，就知道了第 N 跳的地址和往返时间。

这个原理直接决定了怎么读结果：

• 中间跳的延迟，是“路由器生成 ICMP 回复”的耗时，不是转发你业务流量的耗时。路由器转发数据走硬件，生成 ICMP 回复往往由控制平面的 CPU 处理，并且普遍有限速。
• 去程和回程可能走不同的路径。你看到的是去程上的每一跳，但每一跳的延迟里包含了它的回程。
• 只有最后一跳是目标本身在回应，它的延迟和丢包最接近真实业务的体验。

#一份 traceroute 输出逐行怎么读？

下面是一份示例输出（地址取自私有、运营商共享和文档保留网段，数字为说明用途，不是实测）：

$ traceroute -n api.example.com
traceroute to api.example.com (203.0.113.10), 30 hops max, 60 byte packets
 1  192.168.1.1     1.2 ms   1.1 ms   1.0 ms     ← 家里路由器
 2  100.64.0.1      4.8 ms   5.1 ms   4.9 ms     ← 运营商接入（CGNAT 网段）
 3  * * *                                        ← 不回应 ICMP，常见
 4  198.51.100.5    9.7 ms   9.9 ms  10.2 ms
 5  198.51.100.33  85.4 ms  12.1 ms  11.8 ms     ← 单次偏高，后续正常
 6  198.51.100.70 168.2 ms 167.9 ms 168.5 ms     ← 跨境/跨洋段，延迟台阶
 7  * * *
 8  203.0.113.10  170.3 ms 169.8 ms 170.6 ms     ← 末跳：目标本身

逐行解读：

• 第 1–2 跳是你自己的网络和运营商接入。第 1 跳就有几十毫秒或丢包，优先查 Wi-Fi 和本地设备。
• 第 3、7 跳全是星号，但第 4、8 跳正常回应，说明流量通过了这两跳，只是它们不回 ICMP。
• 第 5 跳三次里一次 85 ms，其余正常，后面也不受影响，属于路由器回复限速或 CPU 繁忙。
• 第 6 跳出现一个 150 ms 左右的“台阶”，并且之后每一跳都保持在这个水平。这是物理距离或跨境链路带来的，是真实延迟的主要来源。
• 第 8 跳是目标，170 ms 左右，三次稳定，这才是要记录的结论。

#mtr 报告里 Loss%、Avg、StDev 各看什么？

traceroute 每跳只发 3 个包，偶发情况很容易误判。mtr 会对每一跳持续发包并统计，适合下结论。推荐用报告模式：

mtr -r -c 100 -n api.example.com

下面是一份示例报告（同样不是实测）：

HOST: laptop                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   100    1.1   1.3   0.9   4.2   0.4
  2.|-- 100.64.0.1                 0.0%   100    5.0   5.2   4.6   9.8   0.7
  3.|-- ???                       100.0%  100    0.0   0.0   0.0   0.0   0.0
  4.|-- 198.51.100.5              60.0%   100   10.1  10.4   9.6  14.0   0.8
  5.|-- 198.51.100.33              0.0%   100   11.9  23.6  11.2 140.3  28.1
  6.|-- 198.51.100.70              0.0%   100  168.1 168.6 167.5 175.2   1.2
  7.|-- 203.0.113.10               0.0%   100  170.2 170.5 169.4 178.9   1.4

示例里第 4 跳 60% 丢包，但第 5–7 跳都是 0%，所以第 4 跳的丢包是“不爱回应”，可以忽略。第 5 跳 Avg 23.6、StDev 28.1，波动大，但第 6 跳又回到稳定，同样只是那台设备回复慢。真正需要记录的是末跳：170.5 ms，0% 丢包，StDev 1.4，这条路径是健康的。

#星号、中间跳丢包、延迟突增：怎么判断？

对照自己的结果时可以用这张表：

判断规则：丢包和延迟只有在持续到末跳时才算数。

#各系统用什么命令？

#Windows

tracert -d api.example.com          # -d 不做反向 DNS，速度快很多
pathping -n api.example.com         # 系统自带，带逐跳丢包统计，但耗时较长

tracert 的星号显示为“请求超时”。需要类似 mtr 的连续统计，可以用开源的 WinMTR 图形工具，或者在 WSL 里装 mtr。

#macOS

traceroute -n api.example.com
brew install mtr
sudo mtr -r -c 100 -n api.example.com   # macOS 上 mtr 通常需要 sudo

#Linux

sudo apt install mtr-tiny traceroute     # Debian/Ubuntu
traceroute -n api.example.com
mtr -r -c 100 -n api.example.com
mtr -r -c 100 -n -6 api.example.com      # 单独测 IPv6 路径

如果机器同时有 IPv4 和 IPv6，两条路径可能完全不同，结论要分开记。这部分的排查思路可以参考IPv6 代理不生效：双栈网络下 IPv4 与 IPv6 出口不一致的原因与排查。

#为什么要用 TCP 443 探测？

默认情况下，Linux/macOS 的 traceroute 发 UDP，Windows 的 tracert 发 ICMP。不少云服务和 API 入口会在边界上丢弃这两种探测，于是末尾出现一串星号，看起来像“不通”，但浏览器访问一切正常。

AI API 和网页走的是 TCP 443，用同样的协议和端口探测，结果更接近真实业务：

sudo traceroute -T -p 443 -n api.example.com     # Linux，需 root
sudo mtr -T -P 443 -r -c 100 -n api.example.com  # 注意 mtr 用大写 -P 指定端口
sudo tcptraceroute api.example.com 443           # 部分发行版可用

如果 ICMP 探测末尾全是星号、TCP 443 探测能到达末跳且丢包为 0，说明只是目标不回应 ICMP，路径本身没问题。反过来，TCP 443 也在某一跳之后持续丢包，才值得怀疑链路。

另外要注意：开着代理或 VPN 时，traceroute 看到的通常是你到代理服务器的路径，或者被本地虚拟网卡改写过的结果，并不是业务流量到 API 的真实路径。做路由追踪前先确认流量走的是哪个出口，可以先到 IP 与环境检测 看一下当前的出口 IP 和分流状态。

#路由追踪的结论怎么和应用层耗时对上？

traceroute 和 mtr 只回答“网络层这条路径的延迟和丢包”。用户实际感受到的是 DNS、TCP、TLS 握手加上请求往返的总时间。两边对一下，才能确认问题在哪一层。

#第一步：在 cdnping 首页测应用层时间

打开 cdnping 在线测速，它在浏览器里分别测出每个 API 的“首次连接”（包含 DNS 与 TLS 握手）和“往返”（连接复用后 3 次请求的中位数）。“往返”最接近一次纯粹的网络来回，可以直接和 mtr 末跳的 Avg 比较。

#第二步：按下表对照

“首次连接”比“往返”高出几倍是正常的，因为 TCP 和 TLS 握手本身就要多走几个来回。三段时间各自怎么拆、怎么用 curl -w 单独量，可以看AI API 延迟拆解：连接建立、网关往返与首 token 时间（TTFT）。

#第三步：拿边缘侧数据做基线

如果自己的结果偏高，可以和 API 状态页 对比，区分“服务端这会儿就慢”和“只是我这条路慢”。/status 从 Cloudflare 边缘每 5 分钟探测各官方 API 入口。以 cdnping 2026-10-17 的数据快照为例（探测点为丹佛 DEN 节点；cdnping 当天才开始采集，这份快照的窗口约 85 分钟、242 次探测，只能当作当时的参考，不是长期统计）：

这组数字是边缘节点到 API 入口的耗时，不是你家到 API 的耗时，不能直接相减。它的用处是看趋势：如果边缘侧的 p50 和平时一致，而你那边明显变慢，问题多半在你的接入、出口或跨境段，回去看 mtr 里台阶和丢包出现在哪一跳；如果边缘侧也同时变慢或出现失败，那更可能是服务端的问题，路由追踪查不出什么，先看官方状态页，读法见怎么看 OpenAI 状态页和 Claude 状态页。采集方式和口径写在数据方法里。

#排查时的检查清单

1. 先确认出口：是否开着代理、VPN，IPv4 和 IPv6 是否走同一出口。
2. 用 mtr -r -c 100 -n 跑一次，至少 100 个包。
3. 只看末跳的 Loss%、Avg、StDev；中间跳的星号和孤立丢包先忽略。
4. 末尾全是星号时，换成 -T -P 443 再跑一次。
5. 找出 Avg 的“台阶”在哪一跳，判断是本地、运营商、跨境段还是目标侧。
6. 打开 cdnping 首页测“首次连接”和“往返”，用上面的表对照。
7. 对比 /status 的边缘侧数据，区分服务端问题和自己的路径问题。
8. 需要找运营商或服务方时，附上 mtr 报告原文、测试时间和出口 IP 段。

如果你排查的是某个具体工具连不上，可以接着看Claude Code 连接超时和报错怎么排查：四层网络检查清单和ChatGPT 挂了吗？三步判断是服务故障还是自己的网络问题；想把出口 IP、DNS、测速一起过一遍，可以按开发者网络自检清单（2026 版）走一遍。