Linux服务器丢包需分层排查:先用ethtool查网卡Ring Buffer溢出(rx_dropped等),再用netstat -s和ss -s分析协议栈socket缓冲区与队列溢出,接着检查tc规则是否主动丢包(如netem loss),最后排查iptables、conntrack及应用socket配置。

Linux 服务器网络丢包不能只看 ping 结果或带宽利用率。35% 的带宽占用下出现 3% 丢包,很可能是内核协议栈、网卡 Ring Buffer 或 QoS 规则在“悄悄”丢包,而不是链路饱和。关键是要按数据流向分层查,从物理层一路往上,每一层的丢包痕迹都藏在对应统计里。
看网卡硬件层:Ring Buffer 溢出是高频原因
网卡收到包后先存进 Ring Buffer,如果内核处理不及时,新包就会被直接丢弃——这属于硬件驱动级丢包,不经过协议栈,也查不到 socket 错误。
- 用 ethtool -S eth0 | grep -E "(rx_dropped|rx_missed|rx_fifo|rx_over)" 查驱动计数器:
• rx_dropped > 0 → Ring Buffer 满,需调大缓冲区(ethtool -G eth0 rx 4096)或启用 RPS 分流;
• rx_missed_errors 持续增长 → 可能是驱动版本旧、中断风暴或网卡硬件老化;
• rx_fifo_errors 高 → FIFO 层溢出,多见于高吞吐低延迟场景,需检查网卡型号与驱动兼容性。 - 同时运行 ethtool -g eth0 确认当前 Ring Buffer 大小,很多默认值(如 256)在千兆以上网卡上明显偏小。
查内核协议栈:socket 缓冲区和队列才是“沉默杀手”
即使网卡没丢包,内核也可能在后续环节丢弃:TCP SYN 队列满、接收缓冲区溢出、netfilter 规则拦截、甚至内存不足触发 OOM killer 杀掉网络相关进程。
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- 执行 netstat -s | grep -A 5 "packet receive errors" 和 ss -s,重点关注:
• Recv-Q overflow(ss 输出中)→ 应用读取太慢,socket 接收队列堆积溢出;
• TCPSynRetrans 或 TCPAbortOnMemory(netstat -s)→ SYN 队列满或内存紧张导致连接失败;
• UdpInCsumErrors 或 UdpNoPorts → UDP 层丢包,常因端口未监听或校验失败。 - 检查 /proc/net/snmp 中 IP、ICMP、TCP 各项计数,对比历史基线,突增项往往指向根因。
盯住流量控制层:tc 规则可能“主动丢包”
很多人忽略 tc(traffic control)配置——它能在内核发包前就按策略丢弃,且不会体现在网卡统计里,但会真实影响业务。
- 运行 tc -s qdisc show dev eth0,重点看是否有 netem、fq_codel 或 tbf 类 qdisc 并带 loss、limit、drop 字样;
• 如输出含 loss 30% 或 dropped: 1234 → 就是它在模拟或限流丢包;
• 常见于测试环境误保留、灰度发布配置残留、或运维脚本未清理。 - 临时清空规则验证:tc qdisc del dev eth0 root(注意备份原配置),丢包消失即可确认。
别漏掉防火墙和应用层:iptables/nftables 和 socket 设置
iptables 或 nftables 的 DROP/REJECT 规则、conntrack 表满、应用自身 recv buffer 太小,都会造成“不可见丢包”——ping 通但业务不通。
- 查防火墙日志:iptables -L -v -n 或 nft list ruleset,观察 DROP 计数是否随丢包同步增长;
• 特别关注 INPUT 链中的 state INVALID、ctstate INVALID 规则,易误杀合法连接;
• conntrack 表满时,conntrack -S 会显示 insert_failed 非零。 - 检查应用 socket 设置:
• cat /proc/sys/net/core/rmem_max 和 wmem_max 是否过小(建议至少 4M);
• 应用是否调用setsockopt(SO_RCVBUF)手动设了极小值;
• 对于高并发服务,net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 必须匹配负载。

















