traceroute有时无响应或卡住是因默认UDP探测被防火墙丢弃，改用ICMP（-I）、TCP（-T）或tracepath可绕过；*表示超时或静默丢包，!H/!N为ICMP错误码；容器/云环境建议用tracepath或-traceroute -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 永远看不到全貌
事情说清了就结束。真正难的不是跑出那串跳数，而是判断哪一跳的 * 是策略屏蔽、哪一跳的延迟突增是真实瓶颈、以及什么时候该换工具而不是硬等。
