速查在线工具箱MTR 里中间跳丢包，是不是线路坏了？
多数中间跳丢包只是路由器懒得回你的探测包，转发照做不误。判据只有一条：丢包有没有延续到最后一跳。
直接答案
MTR 靠发送带递增生存时间的探测包，逐跳收集回包来画路径。某一跳显示的丢包率，统计的是这一跳有没有按时回包，而不是它有没有转发你的业务流量。
很多路由器为了保护自身处理能力，会对 ICMP 回包做限速，于是单跳出现两三成甚至更高的丢包，而后面每一跳与目标都正常。这种形态不构成故障。
判据只有一条：丢包是否从某一跳开始并一直延续到末跳。延续到末跳才说明真的有链路在丢包；只出现在中间一跳、之后恢复为零，就是限速噪声。
看到 MTR 报表上中间某跳标着百分之几十的丢包，第一反应往往是「问题找到了」。但这个数字的统计对象是探测回包，不是你的业务流量。
这一篇讲清每一列在数什么、怎么区分限速与真丢包，以及样本量和抖动这两个容易被忽略的信号。
1每一列到底在数什么
先把列名与实际含义对上，读表才不会读在表面上。
| 列 | 含义 | 读的时候注意什么 |
|---|---|---|
| 丢包率 | 发往该跳的探测包没收到回复的比例 | 统计对象是回包，不是转发 |
| 已发包数 | 该跳累计收到多少探测包 | 少于上百个时百分比没有统计意义 |
| 平均延迟 | 该跳回包的平均往返时间 | 单跳尖峰若后继正常，只是该路由器回包慢 |
| 标准差 | 延迟的波动程度 | 标准差高而平均正常，说明时快时慢 |
平均延迟看着正常但标准差很大时，用户体验到的通常是断续而不是整体慢。
2两种形态，两种结论
把丢包出现的位置与延续性组合起来，结论几乎不会看错。
| 形态 | 末跳丢包 | 结论 |
|---|---|---|
| 只有中间某跳丢包，后继与末跳正常 | 零 | 该路由器限速回包，链路可用 |
| 从某跳开始丢包并延续到末跳 | 与中间同量级或更高 | 该跳之后的链路确实在丢包 |
| 每一跳都有相近的丢包 | 相近 | 问题多半在本地出口或第一跳 |
| 只有末跳丢包 | 全部 | 目标主机或其所在网络在丢包，也可能只是它不答探测 |
报修时把整份报表发出去，而不是只截标红最多的那一行。
3把探测包换一种协议再确认
默认模式走 ICMP，遇到过滤或限速时会失真，换协议可以对照。
- 换协议探测
- 改用 TCP 模式探目标真实服务端口，绕过只限制 ICMP 的设备
- 换端口
- 探网站用加密端口、探主机用远程登录端口，选目标真正在听的那个
- 双向都测
- 去程与回程可能走不同链路，只测一个方向会漏掉一半信息
- 控制样本量
- 至少累积上百个探测包，并在故障正在发生时采集
换协议之后丢包消失但最大延迟变得很大，说明包其实丢了、只是被重传掩盖成了延迟。
相关疑问
中间跳显示百分百丢包，是不是这一跳瘫痪了？
不是。很多路由器干脆不回探测包，但转发完全正常。只要后继与末跳正常，这一跳的丢包就与你无关。
为什么每次运行结果都不一样？
探测次数少时百分比跳动很大，不同节点与不同时刻的限速策略也不同。把样本量提到上百再比。
丢包率多少算严重？
看它有没有延续到末跳，而不是看数字大小。中间单跳几十个百分点但末跳为零，通常无需处理。
报修时需要准备什么？
整份报表、采集时间与故障现象。只给一行数字，对方无法定位到具体链路。
继续看：相关问题与资料
全部问题解答 →
内容标识：本页内容由人工智能辅助生成，并经人工核对与编辑。详见 人工智能生成内容标识说明。
内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-12。若发现错误，欢迎通过页脚反馈入口告知。
内容说明：本页针对具体使用问题作答，方法步骤与数值由本站自行整理与复算，事实性内容以对应官方规范与文档为准。内容最后核对日期：2026-10-12。若发现错误，欢迎通过页脚反馈入口告知。