Linux追踪网络路由路径方法

在Linux下使用traceroute追踪网络路径时，常遇到无响应、卡顿或满屏星号（*）的困惑，这往往并非命令故障，而是默认UDP探测被防火墙或中间设备静默丢弃所致；通过切换ICMP（-I）、TCP（-T）模式或改用无需root权限且更轻量的tracepath，可有效绕过限制，尤其适用于容器和云环境；理解“*”（超时/静默丢包）、“!H”（主机不可达）、“!N”（网络不可达）等返回码的真实含义，并关注延迟突增而非仅盯星号，才能精准定位真实瓶颈——真正关键的不是跑出跳数，而是读懂路径背后的网络策略与性能真相。

traceroute 命令为什么有时没反应或直接卡住

因为默认用 UDP 探测，目标主机或中间防火墙可能丢弃 UDP 包，导致超时、无响应或显示 *。这不是命令坏了，是网络策略在拦截。

• 改用 ICMP 模式更可靠：traceroute -I example.com（-I 表示 ICMP）
• 某些系统（如 CentOS/RHEL 8+）默认不带 traceroute，需先装：yum install traceroute 或 apt install inetutils-traceroute
• 普通用户无法发 ICMP 包？加 sudo，但注意：部分系统限制非 root 用户用 -I

Linux 下 traceroute 和 tracepath 有什么区别

tracepath 是更轻量的替代方案，无需 root 权限，且自动探测 MTU，但不支持自定义端口或协议；traceroute 功能全、可调参数多，但依赖权限和安装包。

• tracepath example.com：开箱即用，适合快速看跳数和延迟，尤其在容器或最小化系统里
• traceroute -T -p 443 example.com：用 TCP 发包（-T），指定端口（-p），绕过 UDP 封锁，适合诊断 HTTPS 服务连通性
• traceroute 的 -q（每跳探测次数）、-w（超时秒数）会影响输出速度和准确性，内网调试建议设小点，比如 -q 1 -w 2

看到 * * * 或 “!H” “!N” 这些返回码代表什么

不是故障，是中间设备返回的 ICMP 错误类型：!H = 主机不可达（Host unreachable），!N = 网络不可达（Network unreachable），* = 超时或静默丢包（最常见）。

• 连续几跳都是 *，大概率是某段路径禁用了 ICMP/UDP 回复，不代表断连，只是“看不见”
• 某跳突然从 * 变成 !X，说明探测包至少抵达了那台设备，它主动拒绝了——这是有用信息
• 别只盯着星号，关注延迟突增的位置：从 5ms 跳到 200ms，比一串 * 更值得查

traceroute 在容器或云主机里结果不准怎么办

容器共享宿主机网络栈，但常被 iptables/nftables 规则截断探测包；云厂商（如 AWS、阿里云）的虚拟网络设备也普遍不响应 traceroute，导致路径“断在半路”。

• 容器内优先用 tracepath，它走的是内核路径发现机制，不依赖外部响应
• 云主机上，traceroute -n（禁用 DNS 解析）能避免因反向解析慢而误判超时
• 若需真实路径，得在跳数变化点两端分别 traceroute：比如从客户端到 LB 是 5 跳，从 LB 后端 ECS 到目标又是 3 跳——单次 traceroute 永远看不到全貌

事情说清了就结束。真正难的不是跑出那串跳数，而是判断哪一跳的 * 是策略屏蔽、哪一跳的延迟突增是真实瓶颈、以及什么时候该换工具而不是硬等。

到这里，我们也就讲完了《Linux追踪网络路由路径方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！