MTR丢包怎么看？网络故障排查方法

网站加载缓慢、SSH 偶尔卡顿，使用 MTR 测试时，发现某个中间节点显示几十个百分点的丢包，甚至出现 100%，是不是说明这一段线路已经出现故障？

不能只凭某一行数据下结论。

MTR 记录的是探测报文的回应情况。中间设备如何回应探测，与它是否正常转发业务流量，并不是完全相同的一件事。正确判断需要结合完整报告、最终目标和实际业务表现。

1. MTR到底在测什么？

MTR 将路由跟踪与持续探测结合起来，逐步发现沿途节点，并统计各跳的回应情况和往返延迟。

默认情况下，它使用 ICMP 探测。中间路由器可能不回应这类报文，也可能限制回应频率。因此，某个中间节点显示丢包，不一定表示经过它转发的业务流量也发生了同等比例的丢失。MTR 官方项目对此有明确说明。

判断时，应重点回答三个问题：

• 最终目标是否能够回应？
• 异常是否持续出现在后续节点和最终目标？
• 同一时段的网页、接口或 SSH 是否也出现异常？

完整报告比单独截取“丢包最高的那一跳”更有参考价值。

2. 先做一次连续采样

以下以 Debian、Ubuntu 为例，在需要发起测试的 Linux 机器上安装工具：

sudo apt-get update
sudo apt-get install -y mtr-tiny curl

mtr-tiny 提供命令行版本，适合没有桌面环境的服务器。使用 root 时，可以省略 sudo。

随后执行：

sudo mtr -4 -n -r -w -c 60 -i 1 example.com

将 example.com 替换为实际业务域名或目标 IP。MTR 的目标参数不要带 https:// 或网页路径。

参数含义：

• -4：使用 IPv4。
• -n：显示 IP，不对沿途地址做反向域名解析。
• -r -w：输出宽格式的最终报告。
• -c 60：采样 60 轮。
• -i 1：设置探测间隔为 1 秒。

命令大约运行一分钟，结束前还可能等待部分探测回应。报告模式不会持续刷新完整表格，等待期间没有新输出是正常情况。

如果问题发生在用户访问服务器的方向，应尽量从出现问题的用户网络发起测试。在另一台云服务器上测试，反映的是那台机器的网络路径。

3. MTR报告里的字段怎么看？

常见字段可以这样理解：

延迟通常以毫秒显示。StDev 较大，表示本次采样中的延迟分布比较分散，但应结合平均值、最大值及正常水平判断。

还要确认报告是否真正探测到了目标地址。最后一个有回应的中间节点，不一定就是最终目标。

例如，报告后面出现多行 ???，只能说明相应探测没有获得可识别的回应，不能把前一个有 IP 的节点直接当成业务服务器。

4. 中间节点丢包，应该怎样判断？

下面是几种假设情况，数值仅用于说明判断方法：

网络设备可能对生成 ICMP 回应的流量进行限制，以保护自身处理资源。AWS 的网络诊断说明也建议，重点观察端到端丢包，以及异常是否持续到最终目标。

这并不意味着“最终目标丢包就一定是线路故障”。目标本身也可能限制探测回应，需要继续结合业务验证。

另外，往返延迟包含回应返回的过程。不同节点的回包路径可能不同，因此不能简单用相邻两跳的平均延迟相减，就认定某段链路增加了多少延迟。

5. 网站异常时，再做TCP 443探测

对于 HTTPS 网站，可以补充测试 TCP 443：

sudo mtr -4 -n -r -w -c 60 -i 1 -T -P 443 example.com

其中，-T 使用 TCP SYN 探测，-P 443 指定目标端口。这里的 P 是大写。测试其他业务时，应使用对应端口。

建议把 ICMP 和 TCP 报告放在一起比较，但不要将 TCP MTR 理解成完整的 HTTPS 测试：它没有验证 TLS 证书、网页内容或应用处理结果。

还应确认测试对象一致：

• 域名存在多个 IP 时，记录实际测试到的地址。
• 网站使用 CDN 时，域名可能指向 CDN 节点，而不是源站。
• IPv4 与 IPv6 是两组不同的测试条件，应分别观察。
• 使用代理的网页请求，可能与直接发出的 MTR 探测经过不同出口。

这些条件没有对齐时，两份报告可能根本不是在比较同一条访问路径。

6. 用实际网页请求交叉验证

在同一台测试机器上，再访问实际出现问题的网页：

curl -4 -sS -o /dev/null \
  --connect-timeout 5 \
  --max-time 15 \
  -w 'remote_ip=%{remote_ip} http=%{http_code} total=%{time_total}s\n' \
  https://example.com/

把网址替换为实际业务地址。这条命令会显示连接的远端 IP、HTTP 状态码和此次传输总耗时，同时保留错误提示。

其中，连接阶段最多等待 5 秒，整次传输最多等待 15 秒。这是本次诊断命令的等待设置，并不是在修改服务器配置。

可以按照下面的思路判断：

• MTR 中间节点显示异常，但实际请求稳定：继续观察探测回应策略和异常是否影响最终目标。
• MTR 最终目标与网页请求同时异常：保存同一时段的数据，进一步检查网络路径。
• MTR 表现稳定，但网页仍然很慢：继续检查应用、数据库、TLS 和服务器资源。
• TCP 连接失败：检查业务端口、监听状态、防火墙与安全组。

收到 HTTP 响应，也不代表业务一定成功。还需要确认状态码和页面内容是否符合预期。

涉及端口拒绝或连接超时，可以结合本站的 云服务器端口不通排查教程继续检查。

7. 保存完整报告，方便核对故障时间

需要向技术人员反馈时，可以将测试时间与报告一起保存：

target_host="example.com"
report_file="mtr-tcp-$(date +%Y%m%d-%H%M%S).txt"

{
  date -Is
  printf 'target=%s protocol=TCP port=443\n' "$target_host"
  sudo mtr -4 -n -r -w -c 60 -i 1 -T -P 443 "$target_host"
} 2>&1 | tee "$report_file"

执行前替换 target_host，并在有写入权限的目录运行。结束后，当前目录会生成一个带时间的文本文件。

反馈问题时，同时提供：

• 测试端所在地区、运营商和测试方向。
• 目标域名、实际 IP、协议及端口。
• 故障时间、持续时长和时区。
• 完整 MTR 报告及网页请求结果。
• 正常时段使用相同方法采集的对照数据。

如果两端都具备测试条件，可以分别从两端发起测试，辅助分析不同方向的表现。反向测试提供的是另一组路径观察，不能简单当作原请求回包路径的完整还原。

需要持续观察网站可用性和响应时间，可以参考本站的 Docker搭建Uptime Kuma网站监控，再将异常时间与 MTR 采样记录进行对照。

8. 结语

判断 MTR 丢包，需要把中间节点、最终目标和实际业务表现联系起来。

中间节点不回应，可能与探测限速有关；异常持续到目标并且业务同步受影响时，才有更充分的理由继续调查网络路径。通过连续采样、TCP 探测和网页请求交叉验证，可以减少误判，也能让后续技术沟通更准确。

如需准备 Linux 云服务器用于网站部署和网络测试，可以通过莱卡云官网查看配置，并结合实际用户所在地区和访问需求选择方案。

查看官网购买链接： https://www.lcayun.com

9折优惠码：bloglcayun