traceroute默认最大跳数为30，但实际路径长度由探测包抵达目标时的跳号决定；一旦收到目标响应（如icmp echo reply或udp port unreachable），即自动终止，末行主机ip等于目标地址即为真实跳数，而非必须满30跳。
traceroute 默认跳数是 30，但实际路径可能更短
Linux 的 traceroute 命令默认最多尝试 30 跳，但它不会硬性走满——一旦探测包到达目标主机（收到 ICMP Echo Reply 或 UDP “Port Unreachable”），就会自动终止并显示真实跳数。所以你看到的最后一条有效响应的跳号，就是当前路径的实际跳数。
常见误区是以为输出到第 30 行才算完，其实只要某行出现目标 IP + 延迟值（非全 *），后面就不再发包了。例如：
1 192.168.1.1 1.234 ms 1.102 ms 1.055 ms 2 10.0.0.1 8.412 ms 7.983 ms 8.001 ms 3 203.208.60.1 12.333 ms 12.211 ms 12.199 ms 4 203.208.60.254 15.678 ms 15.542 ms 15.491 ms
如果目标是 203.208.60.254，那实际跳数就是 4 —— 不用数到底几行，看最后一行的 Host 是否等于目标地址即可。
如何确认路径是否被截断或未达目标
当输出末尾出现一串 *（星号），且跳号达到你设定的上限（比如 -m 15），说明路径没走完，要么目标不可达，要么中间某节点静默丢包（不返回 ICMP Time Exceeded）。这时不能直接认定“跳数就是 15”。
- 先检查是否真连不上：
ping -c 3 目标地址看基础连通性 - 换协议重试：
traceroute -I 目标地址（ICMP 模式）比默认 UDP 更容易穿透某些防火墙 - 对比
mtr -r -c 10 目标地址输出：如果某跳之后持续Loss% = 100，大概率是路径在此中断，而非跳数真有那么长
用 ip route get 查目标出口路径，跳数不在此列
ip route get 只告诉你本机路由表选哪条路径发包（比如走哪个网关、哪个接口），它不探测中间设备，也不递增 TTL，因此**完全不反映实际网络跳数**。例如：
$ ip route get 8.8.8.8 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.100 uid 1000
这里只显示下一跳是 192.168.1.1，但到 8.8.8.8 全程可能经过 12 跳 —— 这个信息得靠 traceroute 或 mtr 才能拿到。
跳数不准的典型场景和应对
有些网络环境会让 traceroute 显示的跳数“失真”，不是命令错了，而是路径本身被策略干扰：
- 运营商做了 MPLS 隧道或 SRv6 封装：中间 P 节点不响应 TTL 超时，导致跳数看起来少（比如直连感），实际物理跳数更多
- 云厂商安全组屏蔽 ICMP/UDP 响应：某跳始终
*，但后续跳又能通，造成跳数“空缺”，建议加-q 5多发几次提高捕获概率 - 目标主机禁 ping 且 UDP 端口全封闭：
traceroute到最后跳收不到任何响应，会卡在倒数第二跳显示三次*，此时可试traceroute -T -p 443 目标地址（TCP SYN 模式）
跳数本身只是路径长度的粗略指标，真正关键的是哪一跳开始延迟突增或丢包——那才是问题定位的起点。
