核心是用traceroute或mtr主动探测路径：traceroute -n目标地址看末行跳号与目标ip是否一致以确认真实跳数；mtr -r -c 20 -n目标地址分析loss%、stdev和last识别延迟异常；ipv4/ipv6需分别测试，ip route get仅显示下一跳，无法反映实际跳数。
要测试指定路由的跳数和延迟，核心是用 traceroute 或 mtr 主动探测路径，而不是查路由表——因为 ip route get 只显示出口网关，不反映真实跳数。
看实际跳数：用 traceroute 确认路径终点在哪一跳
运行：traceroute -n 目标地址
观察输出最后一行：如果该行显示的目标 IP 与你输入的目标一致，且有延迟值（不是全 *），那它的跳号就是真实跳数。例如：
- 第 4 行是
4 203.208.60.254 15.6 ms 15.5 ms 15.4 ms，目标也是203.208.60.254→ 实际跳数为 4 - 若末尾连续出现
*且跳号达到上限（如 -m 15 的第 15 行），说明路径未通或中间节点静默丢包，不能当作有效跳数
测每跳延迟：用 mtr 获取稳定统计，不止看平均值
mtr -r -c 20 -n 目标地址 一次性输出 20 轮探测结果，重点关注三列：
- Loss%：非零且集中在某跳（如第 5 跳持续 40%），基本锁定问题在该跳上游
- StDev：标准差 >30ms 就需警惕，>100ms 说明该节点存在严重队列抖动，光看 Avg 容易误判
-
Last：结合
按 d 键切换「延迟差分视图」，能更快识别突发异常（Last − Avg 显著偏高）
排除协议干扰：IPv4 和 IPv6 必须分开测
同一域名，mtr -4 和 mtr -6 结果可能完全不同：
- 先跑
mtr -4 -r -c 10 example.com，再跑mtr -6 -r -c 10 example.com - 对比两份报告：哪一跳开始分叉？哪边 Wrst 更离谱？哪边从第 3 跳起全为
???？后者大概率是本地 ISP 未配好 IPv6 路由 - 注意：
ping6已废弃，统一用ping -6；mtr默认走 v4，必须显式加-6
验证是否真走指定路由：别被 ip route get 欺骗
ip route get 目标地址 只告诉你本机选哪个网关发包，完全不体现中间设备数量。例如：
- 输出
8.8.8.8 via 192.168.1.1 dev eth0→ 仅说明下一跳是192.168.1.1 - 但到
8.8.8.8全程可能经过 12 跳，这个信息只能靠traceroute或mtr获取
