---
title: "traceroute 怎么看：星号、中间跳丢包和延迟突增分别说明什么"
description: "traceroute 怎么看？用带标注的 traceroute 与 mtr 示例解释 Loss%、Avg、StDev，给出“只看末跳和持续丢包”的判断表，附三大系统命令、TCP 443 探测和与应用层测速的对照方法。"
url: https://cdnping.org/blog/traceroute-mtr-how-to-read
language: zh-CN
published: 2026-10-22
category: "网络基础"
tags: ["traceroute","mtr","丢包","网络排查","路由追踪"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# traceroute 怎么看：星号、中间跳丢包和延迟突增分别说明什么

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

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

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

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

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

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

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

```text
$ 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 会对每一跳持续发包并统计，适合下结论。推荐用报告模式：

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

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

```text
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
```

| 列 | 含义 | 怎么用 |
|---|---|---|
| Loss% | 这一跳没有回应的比例 | 只有“从这一跳开始，后面所有跳包括末跳都丢”才有意义 |
| Snt | 已发送的探测数 | 少于 100 时结论不稳，宁可多跑一会儿 |
| Last / Avg | 最近一次 / 平均往返 | 看 Avg 在哪一跳出现台阶，并且之后保持 |
| Best / Wrst | 最小 / 最大往返 | Best 接近物理下限；Wrst 远大于 Avg 说明有抖动 |
| StDev | 标准差 | 末跳 StDev 大，说明业务会感到忽快忽慢 |

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

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

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

| 你看到的现象 | 后续跳的情况 | 结论 | 下一步 |
|---|---|---|---|
| 某跳全是 `* * *` | 后面的跳和末跳正常 | 该路由器不回 ICMP 或限速，忽略 | 无需处理 |
| 末尾连续多跳 `* * *`，到不了目标 | — | 目标或其前面的防火墙丢弃了 ICMP/UDP 探测 | 换成 TCP 443 探测再看（见下文） |
| 中间某跳 Loss% 高 | 后续跳 Loss% 回到 0 | 控制平面限速，忽略 | 无需处理 |
| 从第 N 跳开始丢包 | 后续所有跳包括末跳都在丢，比例相近 | 第 N 跳附近链路真实丢包 | 记录第 N 跳的地址和时间段，换时段复测 |
| 某跳 Avg 突增 | 后续跳回到之前的水平 | 该设备回复慢，忽略 | 无需处理 |
| 某跳 Avg 出现台阶 | 后续跳都保持在高位 | 物理距离或跨境段，属正常延迟 | 若台阶异常大，对比不同时段 |
| 末跳 StDev 很大 | — | 路径拥塞或排队，业务会抖动 | 高峰、低峰各跑一次对比 |
| 末跳少量丢包（如 1–2%） | — | 可能是目标限速，也可能是真实丢包 | 用 TCP 探测复核，再结合应用层测速 |

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

## 各系统用什么命令？

### Windows

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

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

### macOS

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

### Linux

```bash
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 出口不一致的原因与排查](/blog/ipv6-dual-stack-proxy-mismatch)。

## 为什么要用 TCP 443 探测？

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

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

```bash
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) 看一下当前的出口 IP 和分流状态。

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

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

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

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

### 第二步：按下表对照

| mtr 末跳 | 首页“往返” | 首页“首次连接” | 结论 |
|---|---|---|---|
| 延迟正常、0% 丢包 | 与末跳 Avg 接近 | 约为往返的数倍 | 网络正常，握手开销属预期 |
| 延迟正常、0% 丢包 | 明显高于末跳 Avg | — | 慢在服务端或中间的网关/代理，不在路由 |
| 延迟正常 | 正常 | 远高于往返的数倍 | 重点查 DNS 解析或 TLS 握手 |
| 末跳持续丢包 | 波动大或时有失败 | 偶发超时 | 链路问题，记录出问题的跳和时段 |

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

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

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

| API 入口 | p50（ms） | p95（ms） |
|---|---|---|
| api.anthropic.com | 73 | 84 |
| api.openai.com | 96 | 194 |
| api.deepseek.com | 353 | 414 |
| api.moonshot.cn | 375 | 1125 |

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

## 排查时的检查清单

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 连接超时和报错怎么排查：四层网络检查清单](/blog/claude-code-connection-troubleshooting)和[ChatGPT 挂了吗？三步判断是服务故障还是自己的网络问题](/blog/is-chatgpt-down-or-my-network)；想把出口 IP、DNS、测速一起过一遍，可以按[开发者网络自检清单（2026 版）](/blog/developer-network-self-check-2026)走一遍。