Linux服务器丢包怎么排查？

服务器出现SSH卡顿、网站偶尔超时或游戏连接不稳定时，可以先检查网络是否存在持续丢包。

但Ping和MTR显示的丢包比例，需要结合探测方式、目标响应策略及实际业务判断，不能仅凭一张截图确定故障原因。

本文中的203.0.113.10为示例IP，请替换为实际测试目标；网卡名称和业务端口也应按实际环境调整。

1. 使用Ping检查终点响应

先记录测试时间，再进行一组固定次数的探测：

date -Is
ping -n -c 50 -i 1 -W 2 203.0.113.10

该命令发送50次探测，发送间隔为1秒，结束后显示统计结果。

例如：

50 packets transmitted, 49 received, 2% packet loss

表示本次发送50个探测包，收到49个回复，统计丢包率为2%。

需要同时观察：

丢包是否持续出现。
延迟是否明显升高或波动。
丢包时间是否与业务异常一致。
更换测试目标后是否仍然出现。

50次探测丢失1次，只能说明本次采样缺少一个回复，不能直接代表全天网络质量。

Ping使用ICMP。目标限制回复、请求或回复路径异常，以及目标自身处理不及时，都可能影响结果。

Linux使用Ping检查服务器终点丢包率

2. 使用MTR观察路径

MTR可以持续探测沿途节点，帮助观察异常是否延续到目标。

Debian、Ubuntu没有安装MTR时，可以执行：

sudo apt update
sudo apt install -y mtr-tiny

随后生成报告：

sudo mtr -n -r -w -c 50 -i 1 203.0.113.10

常见字段含义如下：

字段	含义
`Loss%`	该节点探测未获得回复的比例
`Snt`	已发送的探测数量
`Last`	最近一次响应延迟
`Avg`	平均响应延迟
`Best`、`Wrst`	最低、最高响应延迟
`StDev`	响应延迟的波动程度

不要只看中间某一跳的Loss%。

如果某个中间节点显示60%丢包，但后续节点和目标均未显示丢包，可能是该节点限制或降低了探测回复的优先级，不能据此认定它丢弃了同等比例的转发流量。

如果异常延续到目标，并与业务故障同时出现，就更值得继续排查。但去程、回程和多路径转发都可能影响结果，不能直接把“第一处显示丢包的节点”当作故障位置。

Linux使用MTR判断中间节点丢包与终点响应

3. 对比TCP端口和实际业务

如果Ping存在丢包，可以对实际业务端口进行TCP探测。

以HTTPS的443端口为例：

sudo mtr -n -r -w -c 30 -i 1 -T -P 443 203.0.113.10

这里的443应替换为实际业务端口。

TCP模式使用SYN探测，不能完整验证TLS握手、页面响应或数据库查询是否正常，因此还需要测试实际业务。

例如，直接测试指定IP上的HTTPS网站：

curl --noproxy '*' \
  --resolve example.com:443:203.0.113.10 \
  --connect-timeout 5 --max-time 15 \
  -sS -D - -o /dev/null https://example.com/

请同时替换域名和IP。--resolve在指定连接地址的同时保留域名，用于正确发送Host和TLS SNI。

如果业务必须经过代理、CDN或其他入口，还应按原访问方式另外测试。

判断时可以参考：

现象	下一步
Ping偶尔丢包，业务访问正常	对比不同探测方式，检查ICMP响应策略
Ping、TCP探测和业务同时异常	检查网络路径、访问规则和服务器状态
探测正常，网站仍然超时	检查应用、反向代理及后端服务
只有某个业务端口异常	检查该端口的监听、访问规则及服务负载

4. 检查网卡错误与丢弃计数

先确认访问目标所使用的网卡：

ip route get 203.0.113.10

查看输出中的dev字段，再检查对应网卡。假设网卡为ens18：

ip -s link show dev ens18

需要更详细的错误分类时：

ip -s -s link show dev ens18

重点关注接收和发送方向的errors、dropped等计数。

这些通常是累计值，应比较故障期间的增量。

可以记录一次结果，间隔30至60秒后再次执行，观察异常计数是否增长。

例如，dropped一直保持128，与故障期间从128快速增加到数千，含义并不相同。

不同驱动和接口类型的统计范围也可能不同。虚拟机内看到的网卡统计，不能完整反映宿主机物理网卡和上游设备的情况。

Linux使用ip命令查看网卡错误与丢弃计数

5. 检查带宽、系统负载和访问规则

在丢包时间段，对照服务器监控检查：

入站或出站带宽是否接近套餐限制。
是否正在进行备份、下载或大文件传输。
CPU、软中断或内存压力是否明显升高。
是否存在异常流量或频繁连接。
防火墙、云端访问规则或防护策略是否发生变化。

可以先查看系统负载和套接字概况：

top
ss -s

连接数量需要结合业务规模和服务器处理能力判断，不能仅凭几十或几百个连接认定异常。

如果丢包与带宽高峰同步，可以在业务允许时暂停非必要传输，再使用相同目标和参数对比测试。

怀疑访问规则影响时，应检查相关规则及命中记录，不要直接清空防火墙。

6. 从不同方向和网络复测

单一位置的测试，往往不足以区分本地网络、运营商路径和服务器侧问题。

可以安排以下对比：

测试方式	观察重点
原客户端访问服务器	是否能够稳定复现故障
客户端更换其他网络	问题是否与本地接入网络相关
其他地区或运营商访问服务器	是否只影响部分访问路径
服务器访问多个外部目标	是否存在较普遍的出站异常
条件允许时进行双向MTR	对比不同方向的路径和响应情况

双向路径可能不同，报告不能简单按节点逐行对应。

对比时尽量使用相同时间段、相同协议和相近的探测次数。对于间歇性问题，应在故障发生时采样，并保留正常时段的结果作为参考。

7. 注意事项

固定目标、协议和参数后再比较结果。
初步排查使用适度频率，避免高频探测影响结果。
区分IPv4和IPv6，不要把两条路径的结果混在一起。
保留完整报告，避免只截取丢包最高的一行。
不要仅凭一次Ping或MTR结果修改内核参数、关闭防护或重启服务器。
记录实际业务表现，包括超时、断线时间及应用错误。

如果需要持续采样，可以保存报告：

date -Is > mtr-report.txt
sudo mtr -n -r -w -c 100 -i 1 203.0.113.10 >> mtr-report.txt

该命令会覆盖同名文件后写入本次结果，需要保留历史报告时请使用不同文件名。

8. 常见问题

自己Ping自己的公网IP不丢包，能证明外网正常吗？

不能。如果该公网IP直接配置在本机，访问自身地址通常由本地路由处理，没有经过完整外部链路。公网IP通过NAT映射时，也应结合实际路由判断。

MTR中间节点显示100%丢包，是线路断了吗？

不一定。如果后续节点和目标仍能回复，说明该节点可能不响应探测。需要结合终点结果和业务状态判断。

终点显示0%丢包，业务就一定正常吗？

不一定。它只代表这组探测没有观察到丢包，无法排除采样之外的间歇性故障，也不能代替业务测试。

能直接判断是云平台QoS导致的吗？

不能。需要结合套餐限制、带宽及包速率监控、平台策略和同时间段的测试结果。单凭连接数或Ping丢包，无法确定QoS是原因。

提交工单时需要提供什么？

联系莱卡云技术支持时，建议提供：

实例信息、源IP和目标IP。
故障发生时间及所在时区。
客户端所在地区和运营商。
完整Ping、MTR及业务端口测试结果。
同时间段的带宽、负载和网卡计数变化。
更换网络或测试方向后的对比结果。

先确认终点和业务是否受到影响，再结合路径、网卡与负载信息排查，能够更有效地缩小故障范围。