UDP报文接收失败需逐级排查：先看netstat -s -u中packet receive errors（驱动/硬件层）、receive buffer errors（套接字缓冲区满）和no ports（端口未监听）三类计数，再结合dmesg查ring overflow或skb分配失败，最后用tcpdump与ethtool交叉验证丢包位置。
Linux 中 UDP 报文接收失败通常不会像 TCP 那样产生明确的错误反馈，因此需结合内核日志、网络栈统计和应用层日志综合排查。关键不是“有没有丢包”，而是“丢在哪个环节”——是网卡没收进来？内核缓冲区溢出？还是应用没及时读？
查看内核网络统计：定位丢包环节
运行 netstat -s -u 或更推荐的 ss -s，重点关注 UDP 段统计中的三类关键计数：
- packet receive errors：表示网卡或驱动层已无法交付给协议栈（如校验和失败、帧损坏、DMA 错误），此时 dmesg 通常有对应硬件/驱动警告
- receive buffer errors：说明 socket 接收缓冲区满，内核丢弃了到达的 UDP 包（RcvbufErrors），常见于应用读取慢、缓冲区过小或突发流量突增
- no ports（或 no socket）：报文目的端口无监听 socket，内核直接丢弃并可能发 ICMP port unreachable（若未禁用）
检查内核日志与驱动状态
运行 dmesg -T | grep -i -E "(udp|error|drop|eth|igb|ixgbe|ice|rx|overflow)"，重点关注：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 网卡 RX ring buffer 溢出提示（如 "ring full"、"rx queue overflow"），说明网卡驱动来不及处理入向帧，需调大
rx/tx ring size或优化中断聚合 - 校验和卸载异常（"checksum failed"），可临时关闭 offload：
ethtool -K eth0 rx off tx off gso off - 内存分配失败（"skb alloc failure"），指向系统内存紧张或
net.core.rmem_max设置过高导致碎片化
确认 socket 层配置与应用行为
UDP 丢包常源于应用自身，而非网络链路：
- 用 ss -uln 确认目标端口确有进程监听；若无，检查防火墙（
iptables/nftables的 INPUT 链是否 DROP/REJECT）、SELinux 是否拦截 - 检查 socket 接收缓冲区实际大小：
cat /proc/net/udp中 rx_queue 列显示当前排队字节数，持续非零且增长说明应用读取滞后 - 调整缓冲区：应用内调用
setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &size, sizeof(size))，或全局调优：sysctl -w net.core.rmem_default=262144
辅助验证：用 tcpdump + ring buffer 分析
若怀疑丢包发生在抓包之前（即 tcpdump 本身也看不到），说明丢弃早于协议栈处理：
- 先运行
tcpdump -i eth0 -w udp.pcap port XXX，再复现问题；若 pcap 中无报文但netstat -s -u显示 receive errors 上升 → 丢在网卡或驱动层 - 对比
ethtool -S eth0 | grep rx_中 rx_discards、rx_no_buffer 等字段是否增长，确认是否为网卡资源不足 - 启用 NIC PTP 时间戳或使用
perf record -e skb:kfree_skb追踪丢包点（高级场景）
