tracert不能精准定位丢包点，因其每跳仅发3个icmp包且不统计丢包率；需结合多次执行、ping测试异常跳ip或使用winmtr等工具获取真实丢包率与延迟分布。
用 traceroute + time 测路径探测总耗时
traceroute 本身不直接输出“总耗时”，它只显示每一跳的延迟。想看整条路径探测花了多久，得靠 time 包裹它——但要注意 shell 内建 time 会低估，尤其在 DNS 解析慢或中间节点无响应时。
- 用
/usr/bin/time -p traceroute example.com获取真实 wall-clock 时间（real） - 如果目标域名解析慢，
traceroute会在第一跳前卡住，此时real时间包含 DNS 查询，不是纯路径探测时间 - 想排除 DNS 影响，先用
getent hosts example.com或dig +short example.com解出 IP，再跑/usr/bin/time -p traceroute -n IP地址 -
traceroute默认发 3 个 probe 每跳，-q 可调数量；-w 控制每 probe 超时，默认 5s，超时多会导致 real 时间暴涨，不是网络真慢，是重试机制拖长
看每跳延迟分布，别只信平均值
默认 traceroute 对每跳打 3 次包，输出类似 1 192.168.1.1 1.234 ms 1.302 ms 1.187 ms。这三值差异大，说明该跳不稳定——比如丢包后重传、QoS 限速、中间设备 CPU 过载。
- 用
-N并发发送（加速探测，但可能被中间设备限速或丢弃） - 用
-f 2 -m 10跳过前两跳、最多探 10 跳，避免在局域网内浪费时间 - 若某跳显示
* * *，不代表断了，可能是 ICMP 被防火墙屏蔽，或设备不响应 TTL-exceeded；这时real时间仍会计入，但你看到的只是“不可见延迟” - 想导出数据做分析，加
-n（禁用 DNS）、-w 1（缩短超时），再用 awk 提取数字：/usr/bin/time -o /tmp/t.out -a traceroute -n -w 1 example.com 2>/dev/null; tail -1 /tmp/t.out | awk '{print $2}'
替代方案：mtr 实时叠加统计
mtr 是 traceroute + ping 的组合，更适合观察路径稳定性。它默认持续发包，按秒刷新，能暴露抖动、间歇性丢包——这些单次 traceroute 完全看不到。
- 安装后直接运行
mtr -r -c 50 example.com：-r 表示报告模式，-c 50 发 50 个包，输出每跳的 Loss%、Avg、Best、Worst、StDev - StDev（标准差）高，说明延迟抖动大；Loss% > 0 且集中在某跳，基本锁定故障点
-
mtr不提供单次“总耗时”，但它输出的 “Started: …” 和 “Ended: …” 时间戳可手动相减，比time更贴近探测行为本身 - 注意：mtr 默认用 UDP，某些网络策略会阻 UDP traceroute；加
-T改用 TCP（如mtr -T -r -c 50 example.com），更接近 HTTP/HTTPS 流量路径
为什么 ping 不等于路径探测耗时
ping 只测终点延迟，完全不反映中间路径。一个 ping 延迟 20ms 的域名，traceroute 可能显示第 5 跳就卡在 300ms——说明问题不在目标服务器，而在 ISP 骨干网某段。
- 别用
time ping -c 1 example.com代替路径探测：它只告诉你“能不能通”和“终点延迟”，对路由异常毫无诊断价值 - 如果
ping通但服务不可用（如 HTTPS 504），必须用traceroute或mtr看是不是某跳后开始丢包或延迟飙升 - 某些 CDN 或 Anycast 地址，
ping和traceroute目标 IP 可能不同（ICMP vs TCP 走不同策略），所以一定要用-n看真实 IP，别依赖域名
真正耗时的从来不是最后一跳，而是某个中间运营商设备临时拥塞、ACL 限速或策略路由绕路。盯着 traceroute 输出里突然跳升的毫秒数，比记总耗时有用得多。
