跳数即每行首数字（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 秒超时，对快速定位问题来说太保守。实际排查中，你往往不需要“完美统计”，而是需要“快速排除”：

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• -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 下结论。