关键是要交叉验证协议、分段聚焦异常跳数并用mtr看丢包趋势：先用traceroute -n定位首现“*”的跳数，再分别以icmp（-i）、tcp（-t）重试，结合dig确认真实ip，最后用mtr -r -c 50 -n持续统计丢包率与延迟变化。
排查路由跟踪中不通的中间节点，关键不是盯着“*”发呆，而是判断它到底是真故障、策略屏蔽，还是探测方式不匹配。核心思路是交叉验证、协议切换、分段聚焦。
先确认是哪一跳开始异常
运行 traceroute -n www.baidu.com，观察输出：如果第3跳正常（有IP和延迟），第4跳起全为*，那问题大概率在第4跳设备或其上游出口。不要直接认定第4跳“坏了”——更可能是它不响应UDP/ICMP探测包。
- 前3跳都通 → 本地局域网和第一级运营商接入没问题
- 从第5跳开始丢星 → 故障点在第4跳之后，比如城域网核心或省际骨干节点
- 第1跳就全星 → 检查本机防火墙是否拦截了outbound ICMP/UDP，或网关关闭了ICMP转发
换协议重试，避开策略限制
很多路由器、云防火墙、企业出口设备默认丢弃UDP探测包，或限速ICMP响应。用不同协议再测，能快速区分是真断连还是被“静音”：
- 加 -I 用 ICMP：
traceroute -I -n www.baidu.com（无需 root） - 加 -T 用 TCP SYN：
sudo traceroute -T -p 443 -n www.baidu.com（模拟 HTTPS 流量） - 对比三次结果：若 UDP 全星、ICMP 部分响应、TCP 全通 → 基本确认是中间设备主动过滤 UDP/ICMP
用 MTR 动态看丢包趋势
traceroute 是单次快照，MTR 能持续发包，看出丢包是偶发还是持续、延迟是否突增：
- 运行
sudo mtr -r -c 50 -n www.baidu.com（一次性50次统计） - 重点看 Loss% 列：如果第6跳 Loss% 是 80%，而第7跳升到 100%，说明第6跳本身转发失败或严重拥塞
- 如果第6跳 Loss% 为 0%，但第7跳突然飙到 95% → 故障在第6跳→第7跳之间的链路（如光纤中断、端口错配）
排除 DNS 和目标解析干扰
域名解析错误会导致 traceroute 去了错误 IP，路径自然不对：
- 先查真实 IP：
dig +short www.baidu.com A - 再对返回的 IP 执行 traceroute：
traceroute -n 110.242.68.66 - 若 IP 直连 traceroute 正常，但域名 traceroute 卡住 → 可能是 DNS 返回了 CDN 节点或被劫持，需检查 /etc/resolv.conf 或换 DNS（如 114.114.114.114）
