theme: default themeName: "默认主题" title: "网速慢成PPT？三行命令找出网卡丢包真凶，老旧服务器瞬间复活"
前言
业务系统响应慢，SSH连接卡成狗，运维排查了一圈发现CPU、内存、磁盘IO都正常——八成是网卡在搞鬼。丢包这事儿不像内存溢出那样显眼，它更像钝刀割肉，一点点把系统性能磨垮。今天就教你用三行命令把丢包真凶揪出来，文末附赠一个真实案例，看完你绝对会回来谢我。
丢包从哪来
Linux网络栈处理数据包大致经过：网卡驱动→内核网络协议栈→应用层。任何一环出问题都可能导致丢包，常见原因包括：
硬件层面：网线质量差、光模块衰减、交换机端口协商失败、网卡本身损坏 驱动层面：驱动版本过旧、与内核不兼容、MSI中断分配失败 系统层面：网卡缓冲区满、Ring Buffer设置过小、软中断CPU瓶颈 网络层面：广播风暴、ARP攻击、交换机端口安全第一步：先看网卡状态
# 查看所有网卡状态和统计信息
ip -s link
或者
netstat -i
重点关注这几列：
- RX-OK/RX-ERR：接收成功/错误包数
- TX-OK/TX-ERR：发送成功/错误包数
- RX-DRP：接收丢包数 ← 这个最关键
- TX-DRP：发送丢包数
如果发现某张网卡的RX-DRP或TX-DRP数值持续增长，说明丢包就在这儿。
第二步：深入分析丢包原因
# 查看网卡详细信息，包括驱动、端口状态
ethtool eth0
查看网卡中断亲和性（判断是否绑核）
cat /proc/interrupts grep eth0
查看网络队列统计
ss -s
- `Speed`: 协商速率是否达标（千兆网卡显示1000Mb/s）
- `Duplex`: 全双工还是半双工
- `Link detected`: 物理连接是否正常
- `RX errors`: 接收错误细分（CRC错误、帧对齐错误、fifo overruns等）
一个典型的问题网卡输出：
Speed: 100Mb/sDuplex: Half
Link detected: yes RX errors: 0 RX dropped: 1234
注意Speed只有100Mb/s——这说明物理链路协商失败了，正常应该是1000Mb/s。问题大概率在网线或交换机端口。
第三步：定位到具体进程
有些丢包是因为系统本身处理不过来，特别是高并发场景：
# 查看各进程网络IO
nethogs
查看软中断CPU消耗
mpstat -I SUM 1
查看网络队列长度
cat /proc/net/softnet_stat
`softnet_stat`第三列表示每CPU队列溢出次数，如果数值持续增长，说明网络收包速度超过了内核处理能力，需要调优`net.core.netdev_max_backlog`。
实战案例：某游戏服务器TCP连接异常
去年处理过一个Case：玩家频繁掉线，SSH操作也卡顿。各项监控指标正常，唯独延迟异常偏高。
排查过程：1. `ip -s link` 发现eth0网卡的RX-DRP在持续增长 2. `ethtool eth0` 显示Speed协商为100Mb/s（应该是1000Mb/s） 3. 更换网线后，问题依旧
| 4. `dmesg | grep eth0` 发现大量`eth0: link up`/`link down`日志 |
5. 最终定位是交换机端口老化，协商成功率低
解决方案：更换交换机端口后，协商速率恢复正常，丢包消失。常用调优参数
确认是系统层面问题后，可以尝试调整这些参数：
# 增大网卡接收队列（应对高并发）
sysctl -w net.core.netdev_max_backlog=50000
增大Socket接收缓冲区
sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.rmem_default=8388608
增大Socket发送缓冲区
sysctl -w net.core.wmem_max=16777216 sysctl -w net.core.wmem_default=8388608
启用TCP窗口缩放（提升大文件传输）
sysctl -w net.ipv4.tcp_window_scaling=1
永久生效写入/etc/sysctl.conf
echo "net.core.netdev_max_backlog=50000" >> /etc/sysctl.conf
硬件问题的预兆信号
如果排查一圈发现所有软件参数都正常，丢包依然存在，那就是硬件问题了。以下是常见硬件故障的典型特征：
| 现象 | 可能原因 |
| 协商速率只有100Mb/s | 网线质量差/光模块衰减/交换机端口故障 |
| 频繁link down/up | 物理连接不稳定，可能是网线接头、光模块或交换机端口 |
| RX CRC错误持续增长 | 网线质量问题或电磁干扰 |
| 单向丢包严重 | 可能是网卡发射端故障 |
预防胜于治疗
丢包问题往往在业务高峰期才暴露出来，提前预防很重要：
1. 监控：将网卡丢包数纳入Zabbix/Prometheus监控，超过阈值立即告警 2. 巡检：每周执行`ip -s link`，记录丢包数趋势 3. 日志：开启`ethtool -S eth0`详细统计，定期分析 4. 备件：关键服务器准备备用网卡，出问题可以快速热替换
结语
网卡丢包是典型的"隐形杀手"，它不会让系统直接崩溃，但会让所有操作都慢半拍。好消息是Linux提供了完善的网络统计工具，只要掌握了正确的排查思路，三五分钟就能定位问题。遇到网络异常时，别忘了先跑一遍`ip -s link`——真凶往往就藏在那几行统计数字里。
看完还有什么疑问吗？
如果文章没有覆盖到你的情况，欢迎联系我们咨询——免费解答，说清楚再决定要不要服务。
📞 服务热线：13708730161 💬 微信：eyc1689 📧 邮箱：service@eycit.com 🌐 https://www.eycit.com
易云城IT服务，您身边的IT专家。