traceroute输出中每行开头的数字代表跳数（hop），其后三个毫秒值（如“1.234 ms 1.456 ms 1.678 ms”）才是该跳的往返延迟（rtt）；出现“*”表示该节点未响应icmp超时包，可能因防火墙策略丢包而非断连。

traceroute 输出里哪一列代表跳数延迟

每行开头的数字就是跳数（Hop），后面三个毫秒值才是该跳的往返延迟。别被中间的 IP 或主机名带偏——真正要盯的是那三组 xx.xxx ms，它们是三次独立探测的 RTT（Round-Trip Time）。如果某跳出现 *，说明该节点没回 ICMP 超时包，不等于断连，可能是策略丢包。

• 第一跳延迟异常高（比如 >50ms），大概率是本地网关或家用路由器负载高，重启常能缓解
• 连续几跳延迟缓慢爬升，但增幅平缓（如 1ms → 3ms → 6ms → 12ms），属于正常 TTL 递增累积，不用紧张
• 某跳突然从 10ms 跳到 180ms，且后续跳数维持高位，问题就卡在这台设备或它的出向链路
• 最后一跳延迟高，但前面都正常，基本可排除路径问题，目标服务器本身可能响应慢或禁 ping

为什么 traceroute -n 是必须加的参数

默认 traceroute 会对每个返回的 IP 做反向 DNS 查询，这会拖慢整个过程，尤其在跨国路径或 DNS 不稳时，某跳可能卡住好几秒才继续，甚至因解析失败把整行显示成 ??? 或空字段。加 -n 后输出全是 IP，执行快、结果干净、时间戳可靠。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 云主机、Kubernetes Pod、内网环境基本都没配反向 DNS，不加 -n 纯属浪费时间
• 某些防火墙会故意让 DNS 查询超时，导致 traceroute 误判某跳“无响应”，实际只是解析卡住
• -n 和 -I、-q 5、-w 2 组合使用最稳妥：traceroute -n -I -q 5 -w 2 example.com

ICMP 模式（-I）比默认 UDP 更容易穿透防火墙

很多企业出口、云平台安全组、运营商设备会默认放行 ICMP Echo Reply（ping 回包），但拦截 UDP 端口（尤其是 traceroute 默认用的 33434+ 高端口）。用 -I 切换到 ICMP 模式后，普通用户权限就能运行，不需要 sudo，而且响应率明显提升。

• 遇到某跳全 * 但下跳又能通，优先试 -I；如果还是 *，再考虑 -T（TCP 模式）
• -I 发的是 ICMP Echo Request，和 ping 协议一致，更容易被中间设备识别为管理流量而非攻击
• 注意：部分老旧设备或严格策略环境可能禁 ICMP，此时 -T 才是兜底方案，但需 root 权限

mtr 比 traceroute 更适合定位抖动和间歇性丢包

traceroute 是单次快照，mtr 是持续观测——它每秒发包、实时刷新，能暴露 traceroute 容易漏掉的波动问题。关键看三列：Loss%（非 0 就可疑）、Avg（连续 ≥100ms 要查）、StDev（标准差 >30ms 说明抖动大）。

• 某跳 Avg 看着正常（20ms），但 Wrst 突然飙到 450ms，说明存在队列拥塞或 QoS 限速
• mtr -r -c 20 -n example.com > report.txt 可生成静态报告，方便发给 ISP 或协作排查
• 交互模式下按 d 切延迟视图、按 l 看丢包图表，比盯着 traceroute 的静态文本直观得多

真实网络里没有“标准路径”，同一命令多次执行结果可能不同。重点不是记住所有参数，而是理解每跳延迟变化背后意味着什么——是设备过载？策略限速？还是单纯 ICMP 被丢？别只抄命令，得看懂数字背后的链路状态。