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 杀掉网络相关进程。
- 执行 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 必须匹配负载。
