先用netstat -i查看RX-DRP和RX-OVR是否增长：RX-OVR突增说明Ring Buffer溢出，需调大ethtool -G eth0 rx；RX-DRP高则查内核协议栈、tc丢包、iptables过滤及socket缓冲区。
确认本地接口是否存在丢包
先用 netstat -i 查看各网络接口的收发统计，重点关注 RX-DRP（进入 Ring Buffer 后因内存不足等被丢弃）和 RX-OVR（Ring Buffer 溢出导致硬件级丢包）两列数值是否持续增长。若 eth0 的 RX-OVR 从 0 突增至数百或更高，说明丢包发生在最底层，必须立即处理。
注意：lo 回环接口的丢包通常可忽略，但若其 RX-ERR 非零，可能暗示内核内存严重异常，需同步检查 dmesg。
检查网卡 Ring Buffer 是否溢出
运行 ethtool -S eth0 | grep -i "missed\|no_buffer\|fifo"，重点观察：
• rx_missed_errors：非零即表示 Ring Buffer 已满，驱动来不及取包；
• rx_no_buffer_count：说明内核无法分配 skb 内存，常与高并发中断或内存碎片有关；
• rx_fifo_errors：多见于老旧千兆网卡，FIFO 缓冲区物理溢出，无法通过软件调优修复。
查看当前大小：ethtool -g eth0。若 RX 值为默认 256（igb）或 512（ixgbe），在万兆或小包密集场景下必然不足。此时执行 ethtool -G eth0 rx 4096 提升接收缓冲区——【该操作无需重启网卡，但部分老驱动需先 ip link set eth0 down 再 up 才生效】。
排查 tc/qdisc 人为丢包策略
很多“幽灵丢包”其实来自人为配置的流量控制规则，网卡统计里完全不体现。执行：tc qdisc show dev eth0
若输出中含 qdisc netem ... loss X% 或 qdisc tbf ... drop 类似字段，说明丢包是主动注入的。例如看到 loss 30%，意味着每 10 个包强制丢掉 3 个，跟硬件无关。
直接清除整条 root 队列：tc qdisc del dev eth0 root。这一步会立即终止所有 tc 丢包行为，无需重启服务。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
定位内核协议栈接收队列溢出
即使 Ring Buffer 没丢包，数据进入内核后仍可能被静默丢弃。分三步验证：
第一步：检查 UDP 丢包计数cat /proc/net/snmp | grep "UdpInErrors\|UdpNoPorts\|UdpOverflows"
若 UdpOverflows 持续上升，说明套接字接收队列已满，根本原因是 net.core.rmem_max 设置过低或应用读取太慢。
第二步：查看当前限制sysctl net.core.rmem_max
默认值常为 212992（约 208 KB），对高吞吐 UDP 服务远远不够。
第三步：临时扩大上限sysctl -w net.core.rmem_max=26214400（设为 25 MB）
同时确保应用层调用 setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size)) 显式设置足够大的缓冲区——【仅改 sysctl 不生效，应用必须主动设置】。
验证丢包是否来自 iptables/nftables 过滤
运行 iptables -t raw -L -v -n 和 iptables -t filter -L -v -n，检查 INPUT 链中是否有带 packet 计数器突增的 DROP 规则。特别留意含 --sport、--dport 或 -m state --state INVALID 的规则，它们可能在连接建立前就终结了数据包。
若发现可疑规则且无法确认用途，先备份后删除：iptables-save > /tmp/iptables.bakiptables -t filter -D INPUT -p udp --dport 53 -j DROP
注意：nftables 用户需改用 nft list ruleset，语法完全不同，切勿混用命令。
