跳数即每行首数字（TTL值），延迟为后三列RTT毫秒值；-n避免DNS查询干扰，-q 5和-w 2可提速排查；全*不等于断连，需结合下跳响应与延迟变化判断真实问题。
traceroute 输出怎么看跳数和延迟
执行 traceroute 后，每行开头的数字就是跳数（TTL 值），从 1 开始递增；后面三列毫秒值是该跳三次探测的往返时间（RTT）。关键不是单看某一次数值，而是观察趋势：
- 同一跳三个值明显不一致（比如
12ms / 48ms / *）→ 说明该节点响应不稳定，可能有队列拥塞或限速 - 从第 N 跳开始，所有后续跳数 RTT 都比前一跳高 50ms+ → 延迟大概率累积在第 N 跳设备或其出向链路
- 某跳全为
*，但下一跳又能响应 → 该节点禁 ICMP/UDP 回复，不代表断连，需结合下跳延迟判断是否真实丢包 - 最后一跳延迟高，但中间跳都正常 → 问题在目标服务器本身（如负载高、iptables DROP 了探测包），不是路由路径问题
为什么 traceroute -n 是必须加的参数
默认情况下 traceroute 会对每个返回的 IP 做反向 DNS 查询，这会带来两个实际问题：一是慢（尤其跨国路径查不到时要等超时），二是干扰判断（DNS 失败可能导致某跳显示异常主机名或卡住）。加 -n 直接输出 IP，让结果干净、可预期、可复现。
- 内网诊断时几乎必加——私有地址段基本没反向 DNS 记录
- 自动化脚本中必须加——避免因 DNS 不稳导致输出格式错乱
- 对比多次运行结果时，IP 比主机名更可靠（同一节点不同时间可能解析出不同别名）
用 -q 和 -w 缩短排查时间
默认每跳发 3 个包、等 5 秒超时，对快速定位问题来说太保守。实际排查中，你往往不需要“完美统计”，而是需要“快速排除”：
-
-q 5：每跳发 5 次，更容易暴露偶发抖动（比如三次都正常，第五次突然 200ms） -
-w 2：单跳等待 2 秒，避免某跳长时间无响应拖慢整体过程（尤其跨运营商链路常见） - 组合使用：
traceroute -n -q 5 -w 2 example.com，5 秒内就能拿到有参考价值的初步路径 - 注意：-w 单位是秒（不是毫秒），别写成
-w 200——那等于等 200 秒
遇到 * 全屏时别急着下结论
连续几跳全是 * 很常见，但原因各异，不能直接认为“断了”：
- 运营商骨干路由器常禁 ICMP/UDP 响应，只放行业务流量 → 实际不影响访问，只是 traceroute 看不见
- 中间某跳开了防火墙策略，但允许 TCP 流量 → 改用
traceroute -T -n example.com可能穿透 - 本地出口 NAT 设备后首跳显示
*→ 检查家用路由器是否关闭了“ICMP 响应”选项 - 真丢包和假沉默的区别在于：下跳能否响应 + 下跳延迟是否突增。如果下跳 RTT 正常，那上面的
*大概率是策略性静默
真正难判断的是那种“间歇性 * + 下跳延迟飘忽”的组合，这时得切到 mtr 持续盯几分钟，而不是靠单次 traceroute 下结论。
