traceroute 并非网络路径的准确快照，其结果受ttl、防火墙、负载均衡等影响显著；常见*号源于中间设备丢弃icmp/udp响应，并非断网，应通过-n、-i、-t等选项适配网络策略并结合curl等工具综合诊断。
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
注意：减少探测数会削弱丢包判断依据，仅适用于“通/不通”粗略定位，不适用于分析抖动或间歇性丢包
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
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
