路由追踪全是星号？traceroute 超时、MPLS 隐藏与 ICMP 限速的正确读法

路由追踪全是星号？traceroute 超时、MPLS 隐藏与 ICMP 限速的正确读法

摘要：traceroute 中间跳出现 * * *，很多人第一反应是"这一跳断了"，于是把责任指向某个运营商。但在真实网络里，星号可能只是路由器对 ICMP 做了限速，可能是 MPLS 没有复制 TTL，也可能是探测包被策略过滤。本文从 TTL 与 ICMP 差错报文讲起，解释三类探测方式的差异、MPLS 隐藏跳的机制、延迟突增的误读，并给出一套从"星号"到"真实故障"的判定流程。

一、星号是最容易被误读的信号

路由追踪的输出通常长这样：

 1  192.168.1.1      1.2 ms
 2  * * *
 3  10.10.0.1        4.8 ms
 4  * * *
 5  203.0.113.1     12.4 ms
 6  198.51.100.9    35.7 ms
 7  * * *
 8  192.0.2.20      38.1 ms

看到第 2、4、7 跳是星号，直觉会认为"这些节点不通"。但第 8 跳已经到达目标，说明数据包实际上穿过了前面所有节点。星号只代表"这一跳没有把差错报文送回给你"，不代表"这一跳没有转发你的包"。

理解这一点，是读懂路由追踪的第一步。转发平面（data plane）与控制平面（control plane）是两件事：路由器可以正常转发数据，同时选择不回复或限速回复 ICMP。

二、traceroute 到底在做什么

2.1 TTL 与 ICMP Time Exceeded

IP 头里有一个 TTL（IPv6 叫 Hop Limit）字段。每经过一台路由器，TTL 减 1；减到 0 时，路由器丢弃该报文，并向源地址回送 ICMP Time Exceeded（Type 11）。

traceroute 正是利用这个机制：

1. 发送 TTL=1 的探测包，第一台路由器减到 0，回送差错，于是知道了第一跳地址；
2. 发送 TTL=2 的探测包，第二台路由器回送差错；
3. 依次递增，直到包到达目标，目标返回端口不可达（UDP）或 Echo Reply（ICMP）等。

所以 traceroute 拿到的每一跳，都是"某台路由器愿意回送 ICMP 差错"的结果。愿意转发不等于愿意回复。

2.2 三种探测方式，结果可能完全不同

常见的探测方式有三类：

方式	典型工具	探测包	常见问题
UDP	Linux traceroute 默认	高端口 UDP	防火墙常封高端口
ICMP	Windows tracert、traceroute -I	ICMP Echo	部分网络禁 Ping
TCP	traceroute -T、tcptraceroute	TCP SYN	需要选对端口

同一条路径，用 UDP 探测可能从第 5 跳开始全是星号，换成 TCP 443 就完整了。这不是网络变了，而是过滤策略不同。排查时如果一种方式不通，换一种再试，是最省时间的动作。

选择探测方式时，还要考虑"探测包长什么样"。TCP SYN 到 443 与真实用户请求最接近，经过 NAT、防火墙、负载均衡时的行为也更接近业务；ICMP Echo 最容易被策略特殊对待；UDP 高端口则常常被当作扫描流量。理解这一点，就不会把"工具被过滤"误认为"路径断了"。

2.3 去程与回程是两条路

traceroute 只能看到去程。回程的 ICMP 差错或响应可能走完全不同的路径，尤其在有 BGP 多宿主、Anycast、策略路由的网络里。

这意味着：

• 去程第 6 跳延迟高，不代表回程也慢；
• 去程看起来绕路，不代表用户下载慢；
• 目标看到的源地址，可能与你本地的出口不一致。

要完整判断，需要双向探测，或者在两端同时抓包看五元组。

2.4 TTL 初始值暴露的细节

不同操作系统的初始 TTL 不同，常见值有 64、128、255。收到一个包的 TTL 是 52，大致可以推断它经过了 12 跳（初始 64）。这也是为什么有些工具能粗略判断"对面是什么系统"。

但对 traceroute 来说，初始 TTL 不重要，重要的是每一跳的递减行为。如果某段路径 TTL 突然不按预期递减，可能说明中间存在隧道、MPLS 或 NAT 转换。

还要注意：TTL 是 8 位字段，最大 255。跨越大规模网络时，跳数接近上限的情况极少，但在某些隧道叠加的场景里值得留意。

三、星号的五种常见来源

3.1 ICMP 限速

路由器的主控 CPU 负责生成 ICMP 差错报文。为了防止被扫描拖垮，厂商普遍对 ICMP 做限速，常见策略是每秒只回应少量报文，超出的直接丢弃。traceroute 默认每跳发三个包，很容易触发限速，于是出现"隔一跳一个星号"或"连续几跳全星"。

这类星号的典型特征：

• 后面的跳数正常；
• 目标可达；
• 多次运行，星号位置会变化；
• 用 TCP 探测时星号减少。

3.2 防火墙或 ACL 不回应

有些网络在边界上直接丢弃 TTL 过期的报文，或者只允许特定类型的 ICMP。这样即使路由器转发了数据，也不会产生可见的跳。

还有一种情况是只过滤发往探测源的 ICMP。路由器的差错报文可能被回程路径上的防火墙拦截，导致你看到星号，但路由器其实已经回应了。

3.3 MPLS 不复制 TTL

MPLS 网络里，入口 PE 会给报文压入标签，中间 P 路由器按标签转发。如果关闭了 TTL 复制（TTL propagation），IP 的 TTL 不会递减到标签 TTL 中，中间 P 路由器就不会产生 Time Exceeded。结果是一段路径"消失"了，直接从事先的 PE 跳到另一端的 PE。

这类隐藏很常见，尤其在运营商骨干网。你看到的 3 跳，实际可能经过了 10 台设备。

3.4 ECMP 与负载均衡

等价多路径（ECMP）会让不同的探测包走不同路径。traceroute 每一跳发多个包，可能分别落到不同链路上，于是同一跳出现多个地址，或者某些包超时。

传统 traceroute 不保证五元组一致，遇到 ECMP 时结果会"跳来跳去"。Paris traceroute 通过固定流标识来减少这种偏差，是更严谨的做法。

3.5 目标侧不回应

如果目标主机或云安全组禁止 ICMP，最后一跳也会是星号，即使端口服务完全正常。这时用 Tcping 或 TCP 探测就能区分"主机不可达"和"只是不回 ICMP"。

3.6 反向路径与 CGNAT

在运营商 NAT（CGNAT）环境下，你的公网出口由运营商共享。traceroute 从第一跳开始就可能看不到家里的路由器，而是直接进入运营商网络。反向的 ICMP 差错还要经过 NAT 映射，如果映射表项老化或设备不处理相关 ICMP，也会出现星号。

判断方法：对比本机 traceroute 与外部观测到的源 IP。如果第一跳就是运营商的地址，说明中间经过了 NAT，路径的前几跳本来就不该可见。

四、判断"真断"还是"假断"

4.1 先看后续跳是否继续

最直接的判据：如果星号之后还有正常跳，说明路径是通的。真正断掉的链路，后续跳不会出现。

例如：

 5  * * *
 6  * * *
 7  203.0.113.9  28.1 ms

第 5、6 跳不回应，但第 7 跳回应，说明包已经穿过前两跳。星号只是"没回 ICMP"。

4.2 换一种探测协议

traceroute -T -p 443 target.example.com
traceroute -I target.example.com
traceroute -U -p 53 target.example.com

TCP 443 最接近真实业务，也最容易穿过只放行 Web 流量的防火墙。ICMP 适合判断基础可达性。UDP 高端口在严格网络里最容易被封。

如果 TCP 能走通、UDP 全星，问题在过滤策略，不在路由。

4.3 用 MTR 做多次采样

单次 traceroute 的偶然性很大。MTR 结合了 ping 与 traceroute，持续采样并统计每跳的丢包率：

mtr -rwzc 100 target.example.com

• -r 输出报告；
• -w 宽屏；
• -z 显示 AS 号；
• -c 100 采样 100 次。

看 MTR 结果时，重点看最后一跳的丢包率。如果中间某跳丢包 30%，但后续跳和最后一跳都是 0%，那 30% 大概率是 ICMP 限速，不是真实丢包。

4.4 用端口连通性交叉验证

路由追踪回答"路径怎么走"，不回答"业务端口通不通"。当末跳是星号时，用 Tcping 测 443、22 或业务端口：

• 端口通、末跳星号：目标不回 ICMP，服务正常；
• 端口不通、末跳星号：可能目标不可达或端口被拦；
• 端口通、中间跳高延迟：路径质量或 ICMP 优先级问题。

这一步能把"网络层"和"应用层"迅速分开。

4.5 从多个地区同时看

单点 traceroute 只能代表一条路径。同一目标在不同地区可能走完全不同的出口。如果只有某个地区出现星号或高延迟，更可能是该地区的互联或策略问题；如果所有地区都在同一跳异常，才需要怀疑骨干或目标侧。

dnspup.com 的路由追踪支持从多个国内外节点发起探测，适合把"局部路径异常"和"全局路径异常"区分开。配合 Ping 与 Tcping 的结果，可以先确认影响范围，再决定是否需要联系运营商。

4.6 抓包确认谁没有回应

当结果反复矛盾时，抓包是最可靠的裁判。在探测端抓 ICMP 与目标端口：

tcpdump -ni any 'icmp or tcp port 443'

你可以看到：

• 探测包是否真的发出去了；
• 有没有收到 Time Exceeded；
• 目标是否回了 SYN-ACK；
• 回包的源地址是否与预期一致。

如果抓包显示包已经发出、目标也回了 SYN-ACK，但 traceroute 仍显示星号，那问题一定在 ICMP 回复路径上，而不是业务链路。

4.7 如何向运营商有效报障

当你确认问题在运营商侧，报障信息的质量决定了处理速度。建议附上：

• 源 IP 与目标 IP（或域名）；
• 故障开始时间与持续时间；
• 使用的探测方式与参数；
• 完整的 traceroute 与 MTR 输出；
• 多个时间点的采样结果；
• 受影响的业务端口与现象。

只说"我这边访问很慢"几乎无法定位。把"哪一段、哪个方向、什么时间、什么协议"说清楚，才可能被转到正确的处理队列。

五、延迟突增不等于拥塞

5.1 路由器对 ICMP 的处理优先级低

很多路由器把"生成 ICMP 差错"放在低优先级队列。测量到的 RTT 包含的是"路由器处理探测包并生成回复"的时间，而不是"转发用户数据"的时间。因此某一跳 RTT 突然到 200ms，下一跳又回到 30ms，通常说明这一跳的 ICMP 回复被降级处理，而不是链路真的拥塞。

判断方法：看后续跳是否恢复正常。如果只有单跳高、后续正常，基本可以忽略。

5.2 控制平面 CPU 忙

路由器在跑 BGP 收敛、大量 ACL 或遭受扫描时，主控 CPU 负载升高，ICMP 回复会变慢。这种情况下，转发平面可能完全正常。把"管理面延迟"当作"业务延迟"是常见误判。

5.3 跨运营商互联点

如果延迟在某个互联点持续升高，且后续跳也保持高位，才更像真实的路径拥塞或互联带宽不足。这时可以结合时间段观察：晚高峰升高、凌晨恢复，通常与流量有关。

5.4 去程与回程不对称

你看到的 RTT 是往返时间。去程 10ms、回程 100ms，与去程 100ms、回程 10ms，在 traceroute 上可能表现相似。要定位方向，需要在两端抓包或使用双向探测。

5.5 抖动与平均值的陷阱

MTR 默认显示平均值，但平均值会掩盖抖动。一条平均 30ms、偶尔飙到 300ms 的链路，对实时语音的影响远大于稳定 60ms 的链路。

观察时应同时看：

• 最好值与最差值；
• 标准差或分位数；
• 高延迟是否集中在某些采样点；
• 是否与丢包同时出现。

如果延迟尖峰与丢包同时出现，更像真实的拥塞或链路错误；如果只有延迟尖峰、没有丢包，可能是队列调度或 ICMP 处理抖动。

六、MPLS 为什么让跳数"消失"

6.1 标签转发的基本过程

MPLS 网络里，入口 PE 根据目的前缀分配标签，中间 P 路由器只查标签表转发，不查 IP 路由表。出口 PE 弹出标签，恢复 IP 转发。

对 traceroute 来说，关键在 TTL：

• 如果开启 TTL 复制，IP TTL 会写入标签 TTL，每经过 P 路由器递减，从而产生 Time Exceeded；
• 如果关闭 TTL 复制，标签 TTL 独立递减，P 路由器不会因 IP TTL 到期而回应，路径就被"压缩"了。

运营商常关闭 TTL 复制，目的是隐藏内部拓扑、减少控制面压力。这不是故障，而是设计选择。

6.2 隐藏跳的识别

典型表现：

• 两跳之间 RTT 突然增加很多，但中间没有可见节点；
• 跳数明显少于地理距离；
• 同一段路径在不同时间显示不同数量的隐藏跳；
• 使用 ICMP 扩展（RFC 4950）时能看到 MPLS 标签栈信息。

遇到这种情况，不要试图"补全"隐藏跳。只要端到端延迟与丢包正常，隐藏本身不影响业务。

6.3 对排障的影响

MPLS 隐藏会让"哪一跳出问题"变得难以回答。这时应转向端到端指标：

• 不同地区的 RTT 分布；
• 丢包是否集中在特定时间段；
• TCP 吞吐与重传率；
• 业务端到端成功率。

路径内部的细节由运营商掌握，用户侧能做的是把现象描述清楚，提供源、目的、时间、方向与采样数据。

6.4 隧道与 Overlay 的"隐形跳"

除了 MPLS，GRE、IPsec、VXLAN、WireGuard 等隧道也会隐藏中间节点。隧道两端的设备对 traceroute 来说只是"一跳"，但底层可能经过多个运营商网络。

这类场景下，traceroute 的结果只能反映隧道外层的一部分信息。要定位底层路径，需要在隧道端点分别抓包，或者使用支持外层探测的工具。对业务侧来说，更有意义的是隧道两端的 RTT、丢包与吞吐，而不是中间跳的具体位置。

6.5 两个典型案例

案例一：跨境访问"第 4 跳开始全星"。

某团队访问海外服务，traceroute 从第 4 跳起连续星号，但 TCP 443 能建立连接，只是速度慢。换用 -T -p 443 后，路径完整显示，且第 6 跳 RTT 明显升高。结论是中间网络对 UDP 高端口做了过滤，同时国际出口在晚高峰拥塞。处理方式不是"修路由"，而是调整传输策略、错峰同步，并评估专线。

案例二：国内访问"某一跳 300ms，后面恢复正常"。

监控报警显示某条链路第 7 跳延迟 300ms，但末跳与业务指标正常。多次采样发现该跳的 ICMP 回复极不稳定，而 TCP 握手延迟正常。最终确认是路由器对 ICMP 做了限速与低优先级处理。团队把监控规则从"任一跳延迟"改为"末跳延迟 + 端口成功率"，误报大幅下降。

这两个案例的共同点是：不要用中间跳的 ICMP 行为推断业务质量。末跳与端口才是更接近用户的指标。

七、一套可执行的排查流程

第一步：确认目标是否真的不可达。

先用 Ping 与 Tcping 分别测试。如果端口通，说明主机可达，路由追踪里的星号只是控制面现象。

这里要区分"目标不可达"与"服务不可用"。Ping 不通但端口通，说明 ICMP 被过滤；Ping 通但端口不通，说明服务或防火墙有问题；两者都不通，才更像路径中断。

第二步：换探测协议重跑。

依次尝试 TCP 443、ICMP、UDP。对比哪种方式能走通，判断是否存在过滤。

第三步：多次采样。

用 MTR 跑 100 次以上，观察星号位置是否稳定。稳定的星号更可能是策略；随机变化的星号更可能是限速或 ECMP。

第四步：看最后一跳。

末跳丢包率才是端到端丢包的可靠指标。中间跳丢包但末跳正常，不要据此判断链路故障。

第五步：多地区对照。

确认是个别地区还是全局。局部问题优先查本地出口与互联；全局问题再查目标侧。

第六步：记录并复盘。

保存原始输出、时间、源地址、目标地址与探测参数。没有这些信息，运营商也很难定位。

复盘时把"现象、证据、结论、动作"分开写。现象是用户看到什么，证据是 traceroute、抓包与监控数据，结论是你判断的原因，动作是已经做了什么。这样即使问题再次出现，也能快速复用。

八、工具与参数速查

8.1 Linux

traceroute -n -T -p 443 target.example.com
traceroute -n -I target.example.com
mtr -rwzc 100 target.example.com
tracepath -n target.example.com

-n 关闭反向解析，避免 DNS 查询拖慢输出。-T 使用 TCP，-p 指定端口。tracepath 还能顺带探测路径 MTU。

8.2 Windows

tracert -d target.example.com
pathping target.example.com

tracert 使用 ICMP Echo，-d 不解析域名。pathping 会分段统计丢包，比单次 tracert 更有参考价值。

8.3 macOS

traceroute -n -P tcp -p 443 target.example.com

不同版本的参数略有差异，可以用 man traceroute 确认。macOS 默认也是 UDP 探测。

8.4 结果的辅助解读

• whois 或 BGP 查询可以确认每一跳的 AS 归属；
• dig -x 可以看 PTR 记录，但 PTR 不一定准确；
• 地理位置数据库只能作为参考，Anycast 与广播地址经常"位置漂移"。

8.5 把结果存档成可比对的数据

故障排查最怕"当时没留证据"。建议把每次探测的原始输出按"日期-目标-源节点"命名保存，至少保留一周。MTR 可以用报告模式输出为文本：

mtr -rwzc 100 target.example.com > "mtr-$(date +%Y%m%d-%H%M)-target.txt"

如果要长期观察，可以把关键指标（末跳延迟、丢包率、路径跳数）写入时序数据库，做成趋势图。路径变化往往不是瞬间发生的，有趋势数据才能看出"从哪天开始绕路"。

存档时同时记录探测源的位置与网络类型。同样是"电信家宽"，不同城市、不同接入方式的结果可能完全不同，缺少这些上下文，数据很难复用。

如果团队有多条线路，可以把同一时刻的结果并排放在一张表里，比较末跳延迟与丢包。这种"横向对照"比单条路径的细节更能说明问题。

表格不需要复杂，几列就够：源节点、目标、末跳 RTT、丢包率、跳数、时间。

坚持记录几次之后，你会对"正常长什么样"有直觉。

这份直觉能让你少走很多弯路。

九、常见误区

误区一：星号就是丢包。

星号只表示"没有收到该跳的差错报文"。转发可能完全正常，末跳可达就是最好的反证。

误区二：某一跳延迟高就是这一跳有问题。

单跳高、后续正常，通常是 ICMP 处理优先级低。只有持续到末跳的高延迟才值得关注。

误区三：跳数少说明路径短。

MPLS、隧道、TTL 不复制都会让跳数"变少"。跳数是观测结果，不是物理拓扑。

误区四：traceroute 能看到完整路径。

它只能看到愿意回应的节点，而且只覆盖去程。回程、隐藏节点、ECMP 分支都不在结果里。

误区五：换一个工具结果不同，说明工具有问题。

不同工具使用不同探测包，遇到不同过滤策略，结果本来就可能不同。这恰恰是有价值的信息。

误区六：末跳星号就是目标宕机。

很多服务器默认不回应 ICMP，云安全组也常禁用 Ping。末跳星号但 443 端口正常，是完全健康的状态。判断服务是否可用，要看端口与应用层。

误区七：traceroute 跳数越多，网络越差。

跳数受 MPLS、隧道、TTL 策略影响，与质量没有直接关系。两条路径一条 8 跳、一条 20 跳，后者的延迟完全可能更低。

十、结论

路由追踪是一张"不完整的草图"，不是网络拓扑的真相。星号可能来自 ICMP 限速、防火墙策略、MPLS 隐藏或 ECMP；延迟突增可能只是控制面处理慢。判断故障时，先看末跳是否可达、端口是否连通、多地区是否一致，再决定要不要沿着某一跳深挖。

把 traceroute 当成"线索"而不是"结论"，配合 Ping、Tcping、MTR 与业务指标一起看，才能避免把运营商的 ICMP 限速误判成一次严重的链路故障。

最后记住一条实用原则：先证明用户受影响，再解释路径为什么长这样。路径图再漂亮，如果业务指标正常，它就不是故障；反过来，路径看起来再正常，如果用户持续超时，也一定还有没看到的东西。