Linux traceroute追踪路由教程

traceroute 并非网络路径的“真实快照”，而是一次受TTL机制、防火墙策略、负载均衡及协议限制影响的探测尝试；面对满屏*号或卡顿，问题往往不是断网，而是中间设备静默丢弃ICMP/UDP响应——掌握-n跳过DNS、-I切换ICMP、-T结合端口发TCP SYN等关键技巧，才能绕过策略干扰，获得贴近业务流量的有效路径信息；更重要的是，它不能替代curl等工具诊断应用层延迟，真正的问题定位需分层比对：先看业务请求各阶段耗时，再用适配协议的traceroute验证网络基础，最后警惕MTU、CDN和Anycast带来的路径不一致性。

traceroute 不是万能的路径“快照”，它反映的是某次探测时 UDP 包（默认）走的路径，受 TTL、防火墙策略、负载均衡影响很大。直接运行 traceroute example.com 往往得不到稳定或可解释的结果——得先明确你真正想查什么。

为什么 traceroute 显示一堆 * 或卡在某跳不动

最常见原因是中间设备（尤其是企业防火墙、云厂商网关、ISP 路由器）默认丢弃 ICMP Time Exceeded 或 UDP 不可达响应。这不是网络断了，而是“不回声”。
解决思路不是反复重试，而是换协议或绕过解析：
• 用 -n 立刻排除 DNS 反向解析延迟干扰
• 用 -I 切换 ICMP 模式（部分网络对 ICMP 更宽松）
• 若目标服务明确（如 HTTPS），用 sudo traceroute -T -p 443 example.com 发 TCP SYN 包，更贴近真实流量行为
• 避免在出口被限 UDP 的环境（如某些校园网、办公网）硬刚默认 UDP 模式

如何让 traceroute 结果更快、更干净

默认每跳发 3 个包、最多 30 跳、带 DNS 反查，对快速诊断是冗余负担：
• 加 -n：跳过反向 DNS 查询，输出全是 IP，秒出结果
• 加 -q 1：每跳只发 1 个探测包，减少等待时间
• 加 -m 16：多数公网路径 16 跳内能到，没必要等满 30 跳超时
• 组合示例：traceroute -n -q 1 -m 16 github.com
注意：减少探测数会削弱丢包判断依据，仅适用于“通/不通”粗略定位，不适用于分析抖动或间歇性丢包

traceroute -I 和 traceroute -T 的权限与适用边界

-I（ICMP 模式）通常无需 root，但部分系统需 cap_net_raw 权限；-T（TCP 模式）强制要求 root（因为要构造原始 TCP 包）。
关键区别不在“谁更准”，而在“谁被放行”：
• 如果 traceroute example.com 卡在第 3 跳全是 *，但 traceroute -I example.com 能继续往下，说明中间链路封 UDP 但放 ICMP
• 如果连 -I 也卡住，再试 sudo traceroute -T -p 80 example.com；若此时能通，基本确认问题出在 UDP 过滤策略上
• 不要滥用 -T 扫描非标准端口——目标主机若无监听，SYN 包可能被静默丢弃，结果仍是 *，容易误判

别把 traceroute 当 ping 用，也别指望它还原真实业务路径

它测的是探测包路径，不是你的 HTTP 请求路径。CDN、Anycast、ECMP 负载均衡会让不同探测包走不同物理线路，同一命令多次执行结果可能跳数不一致、IP 不同。
真正要定位业务慢：
• 先用 curl -w "@format.txt" -o /dev/null -s http://example.com 看 DNS、TCP、TLS、HTTP 各阶段耗时
• 再用 traceroute -n -I example.com 对比“基础网络层是否异常”
• 若 traceroute 路径正常但 curl 超时，问题大概率在应用层（证书、后端响应、WAF 规则）而非路由本身
• 最容易被忽略的一点：traceroute 默认包长 40 字节，而实际业务包往往更大；某些链路存在 PMTU 问题，小包通、大包丢——这时得配合 tracepath 或手动 ping -s 测试 MTU

终于介绍完啦！小伙伴们，这篇关于《Linux traceroute追踪路由教程》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！