### [VPS网卡丢包怎么判断？用接口统计、队列、MTR与云监控区分故障层](https://www.jiyueip.com/article/13370)

**Published:** 2026-07-30T04:57:56

**Author:** 斑斓助理

**Excerpt:** VPS出现丢包时，不能只凭一次Ping就判断线路或网卡故障。本文从ip -s link、ethtool、ss、内核队列、MTR和云平台监控入手，区分网卡收发丢包、主机负载、运营商线路和目标端限速，并给出复核与升级证据。

VPS 用户看到 Ping 丢包，第一反应往往是“线路坏了”。但丢包可能发生在虚拟网卡收发、内核队列、宿主机调度、运营商路径、目标服务器限速，甚至只是中间路由器降低 ICMP 优先级。需要同时看接口计数器、TCP 重传、路径测试和云监控，才能判断是否影响真实业务。

## 先保存现场：时间、方向和目标

记录发生时间、VPS 公网地址、测试目标、IPv4/IPv6、协议和测试次数。入站访问异常与 VPS 主动访问异常是两条不同路径；从本机 Ping 自己的网关也不能代表公网用户到站点的质量。

## 第一层：查看虚拟网卡与内核统计

```
ip -s link
ip -s -s link show dev eth0
ethtool -S eth0 2>/dev/null | egrep -i 'drop|error|miss|fifo|timeout'
cat /proc/net/dev
```

重点关注 RX/TX dropped、errors、overruns、FIFO、carrier 和 timeout。计数器是累计值，应在固定间隔采样两次计算增量；重启 VPS 或重置网卡后计数会变化，不能把单次绝对值直接当成当前丢包率。部分云平台不开放完整的 `ethtool -S`，没有输出不等于没有问题。

## 第二层：排查 CPU、软中断和发送队列

网卡收包后还要经过内核软中断和 socket 队列。检查 CPU、软中断、队列长度和 TCP 重传：

```
mpstat -P ALL 1 5
cat /proc/softirqs
ss -s
nstat -az | egrep 'Retrans|InErrors|OutRsts|ListenDrops'
tc -s qdisc show dev eth0
```

如果 CPU 长时间满载、软中断集中在单个核、qdisc backlog 或 TCP RetransSegs 持续增加，丢包可能来自本机处理能力或拥塞。不要在没有基线的情况下直接增大队列；队列过大可能引入 bufferbloat，反而增加延迟。

## 第三层：用 MTR 看丢包是否传递到终点

```
mtr -rwzc 100 -4 example.com
mtr -rwzc 100 -6 example.com
traceroute -T -p 443 example.com
```

中间某一跳显示高丢包，只有当后续各跳和最终目标也持续损失时，才更像真实转发丢包。若中间节点丢包高但末跳接近 0%，通常是该路由器对探测包限速或降低响应优先级。TCP 443 的 traceroute 更接近网站业务路径，不能只看 ICMP MTR。

## 第四层：区分服务器入站、出站和目标端问题

用两类对照：从 VPS 访问多个独立目标；从外部网络访问 VPS 上的测试服务。若 VPS 到多个目标都出现 TCP 重传，而外部到 VPS 正常，重点看出站路径或本机；若只有单个目标异常，可能是对方限速、路由或目标服务负载。测试期间记录 `curl -w` 的连接和首字节时间，避免只依赖 Ping：

```
curl -o /dev/null -sS -w 'connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}
' https://example.com/
```

## 第五层：结合云监控和工单证据

云平台的实例监控可能提供网卡流量、丢包、连接数、CPU steal、宿主机事件或带宽封顶信息。把接口增量、MTR 末跳、TCP 重传和监控时间对齐，再向服务商提交最小证据集：UTC 时间窗、实例 ID、受影响方向、目标地址、测试命令和原始输出。不要只发一句“Ping丢包”。

## 修复与复核

-   确认安全组和系统防火墙没有丢弃所需业务端口。
-   降低不必要的并发和突发发送，观察 qdisc、重传和延迟是否恢复。
-   若怀疑单核软中断或虚拟化争用，记录一段监控后再申请迁移或更换实例。
-   修复后在不同时间、不同目标和 IPv4/IPv6 下重复测试。
-   保留修复前后计数器增量，不用一次成功 Ping 宣称线路已完全恢复。

如果问题表现为网站端口根本无法访问，应先沿监听地址、安全组、防火墙、公网地址和路由逐层确认，可参考[VPS端口不通的分层排查方法](https://www.jiyueip.com/article/13241)；本文讨论的是端口可达但传输中出现丢包或重传。

## 常见问题

**MTR某一跳丢包100%，是不是线路一定坏了？**  
不一定。看后续跳和最终目标是否同时丢包；只在中间一跳出现，常见于ICMP限速。

**Ping没有丢包，网页仍然很慢，为什么？**  
Ping只测ICMP。网页可能受TCP重传、TLS、应用处理、带宽整形或目标站响应时间影响，应结合curl和TCP指标。

**把MTU改小能解决VPS丢包吗？**  
只有在路径存在分片或PMTU发现异常并有证据时才考虑。先用不同大小的TCP/UDP测试定位，不要盲目修改全局MTU。

**需要多少次测试才有意义？**  
没有固定次数。应覆盖多个时间窗、多个目标和两个地址族，并记录原始命令与增量指标，保证结果可复核。

**Tags:** Linux服务器, VPS, 云服务器, 网络故障排查, 网络测速

**Categories:** 行业洞察

---