不能只凭中间某一跳的丢包率判断。先看目标这一跳，再看后续节点是否也出现类似现象。中间设备没有回复测试报文，并不一定表示它没有继续转发流量。
打开网络工具，切换到 MTR 诊断 →每一行是在测哪一段？
“跳”是沿途经过的一个路由节点。MTR 把逐跳探测和重复统计放在一起：通过改变报文的跳数限制，让不同位置的节点返回响应，再统计相应探测的回复情况与往返时间。[1]
表格各行对应不同的探测，不是同一个包经过所有节点后留下的完整记录。各行的丢包率不能相加。先核对结果中的目标 IP；如果没有到达目标，表格最后一行也不能当作目标这一跳。
| 页面字段 | 怎样理解 |
|---|---|
| # | 返回路径列表中的跳序号。 |
| IP / Host / ASN | 节点地址、主机名和自治系统编号（用于识别网络）。上游没有返回的内容不会补造；地址缺失时显示“*”。 |
| Min / Avg / Max (ms) | 最低、平均、最高往返时间，单位为毫秒；缺少统计值时显示“—”。 |
| 丢包 | 相应探测未收到回复的比例，不直接等于该设备丢弃业务流量的比例。 |
当前工具按每跳 3 个 ICMP 包发起测试。ICMP 是互联网控制报文协议，此处用于诊断探测。页面没有单独的实际发包数或收包数列；测试未完成时，不能假定每跳已经完成 3 包统计。
为什么这一跳丢包，后面却有回复？
转发流量与回复探测，分开看
AI 原理示意
- 绿线 · 继续转发
- 设备可能仍在转发经过它的流量。
- 蓝线 · 诊断回复
- 回复可能被限制，或未收到回复。
可能原因示意，不是故障诊断；没有回复不能直接换算成业务流量丢失。
转发经过设备的流量，与设备为诊断报文生成回复，是不同的处理过程。路由器可能降低诊断响应的优先级、限制回复频率，或不回复某些探测，同时继续转发其他流量。MTR 手册和路由器标准都提醒过这类差异。[1][2]
因此，中间某跳显示 100% 丢包、后续节点仍有回复，不能解释为它把所有业务流量都丢掉了。“可能存在响应限制”是待核实的解释，不等于已经查明原因；仍要检查目标、后续节点和实际服务。
三种常见结果
下面是读表示意，不是真实测量记录，也不代表任何商品线路。
中间某跳丢包高，后续和目标未观察到丢包
这种结果不足以证明该跳存在转发故障。保留完整结果，在不同时间复查；同时看网页或应用是否真的异常。目标在这次短测试中正常，也不能保证其他时段或其他业务流量都正常。
从某跳开始，后续多跳和目标反复丢包
这种模式值得继续排查，尤其是同时发生连接中断或下载不稳定时。但表格不能直接判定某台路由器、某个运营商或服务器负责。回复走的返回路径可能不同，测试期间也可能换路；设备响应方式同样会影响统计。[3]
目标没有回复，网页或应用仍能使用
实际应用：仍能使用
目标可能不响应当前 ICMP 探测。检查实际服务的连接和功能，并保存异常发生的时间。不能仅凭没有诊断回复就宣布服务器宕机。
3 个包，百分比能说明多少？
1 ÷ 3 ≈ 33.3% 丢包
仅为样本计算示意：3 个包少收到 1 个回复，百分比就会很高，不能据此估计长期丢包。
“本次 0% 丢包”只表示这次样本没有观察到丢失。无回复、缺失字段和测试未完成要分开看：100% 是返回的丢包统计；“—”表示缺少该统计值；地址位置的“*”表示未返回地址，不能单独当作丢包率。
探针状态显示“测试中”时，结果可能继续更新；“未获得完整结果”不等于完整测量。达到等待上限时，页面会提示测试暂未全部完成并保留已返回数据；请求失败也可能提前结束等待。页面等待超时，不等于目标每个包都超时。
需要复查时，在不同时间做几次有限测试，保存每次的完整结果。不要通过无限测试或频繁刷新来追一个更好看的数字。
中间一跳的延迟突然升高
若某跳延迟高，后续又恢复，不能据此认定该处让所有后续流量都变慢。它对诊断报文的响应处理本身就可能增加等待。若后续和目标也持续升高，再比较其他时间的测试，并核对当时的应用表现。
各跳显示的是从探针到相应节点再返回的往返时间。不同节点的回复可能走不同的返回路径，不能简单用相邻两行相减，得出两台设备之间的准确延迟。[3]
这张结果表来自哪里？
Fast-BGP 的 MTR 由 Globalping 公共探针执行。[4] 当前可选亚洲、北美、欧洲，每次最多 3 个探针，每跳配置 3 个 ICMP 包。不能指定城市、运营商或固定探针，也不能在页面调整每跳包数。
测试从公共探针出发，不是从你的设备出发，也不能自动代表某款 Fast-BGP 商品的线路。记录结果中的探针城市、国家、网络组织、目标 IP 和测试时间，并注明当前的样本配置；仅写“亚洲探针”不足以复现条件。
本地网络与公共探针的对比方法，见下文链接，不必把两类结果强行解释成同一条路径。
提交问题时，把这些资料一起保存
- 完整结果，包含后续节点和目标，不只截异常的一行。
- 测试时间与时区、实际目标 IP。
- 本次探针城市、国家和网络组织，以及每跳 3 包的配置；若结果未完成，一并注明。
- 实际异常：网页打不开、连接中断，还是下载不稳定；发生在什么时间。
- 是否在不同时间重复观察到，其他网络访问时是否也出现。
页面可以复制报告或下载报告图片；当前这两种导出中的 MTR 逐跳数据保留平均延迟和丢包率。若问题涉及最低、最高延迟，也请补充展开后的完整表格截图。
涉及已购服务时，通过现有客户中心工单等支持渠道提供对应商品和线路信息。不要公开账户密码、密钥或其他访问凭据。购买前应使用供应商提供的对应商品测试目标，官网域名的结果不能直接代表商品线路。