netstat -s -u可查UDP丢包，receive buffer errors持续增长说明应用读取慢或rmem_max过小，packet receive errors高需检查端口监听状态，两者均为协议栈软件层丢包，与网卡硬件层dropped无关。
netstat -s 能直接暴露内核协议栈各层的丢包计数，但必须结合字段含义和上下文交叉判断，否则容易把“统计值非零”误读为“当前正在丢包”。
怎么看 UDP 层丢包：重点关注 receive buffer errors 和 packet receive errors
执行 netstat -s -u（或 netstat -s | grep -A 5 "Udp:"），关键字段如下：
-
receive buffer errors：UDP socket 接收缓存满导致丢包。该值持续增长，说明应用读取太慢、或net.core.rmem_max设置过小 -
packet receive errors：IP 层已成功交付，但 UDP 层校验失败、端口无监听等。若该值高，先确认目标端口是否有进程在 listen（ss -uln | grep :端口） -
packets to unknown port received：发给本机未监听 UDP 端口的包，内核静默丢弃（不回 ICMP Port Unreachable，除非开启net.ipv4.icmp_echo_ignore_broadcasts=0）
怎么看 TCP 层异常：别只盯 retransmits，先看 timeouts 和 estabresets
netstat -s | grep -A 3 "Tcp:" 输出中：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
retransmits高 ≠ 本机丢包，可能是对端响应慢、网络中间丢包，需配合对端netstat -s或抓包验证 -
timeouts持续上升，说明连接建立或数据传输阶段反复超时，更可能指向路由、防火墙拦截或 SYN 包被 drop -
estabresets突增，大概率是应用主动 close 或收到 RST，不是丢包，但会干扰重传判断
为什么 netstat -s 显示丢包，但 ethtool -S 和 ifconfig 却没看到 dropped？
因为 netstat -s 统计的是协议栈**软件层**丢弃，而 ethtool -S 和 ifconfig 反映的是网卡驱动/硬件层丢弃。两者不重叠：
- 网卡 ring buffer 溢出 →
ethtool -S eth0 | grep rx_missed_errors增长，netstat -i的Rx-DRP也涨 - UDP 缓存满 →
netstat -s中receive buffer errors增长，但ethtool和ifconfig的 dropped 为 0 - conntrack 表满 → 新建连接 SYN 包被静默丢弃，
netstat -s不体现，需用conntrack -S查insert_failed
容易忽略的陷阱：UDP 丢包统计不等于“业务不可用”
UDP 是无连接、不可靠协议，内核丢包本身不触发重传或告警。很多场景下，只要 receive buffer errors 不随时间线性上涨，就说明瞬时压力已过去；但如果该值每秒稳定增长 >10，才真正值得调大 rmem_default 或优化应用读取逻辑。另外，netstat -s 是累计值，重启后清零——若只看单次输出，无法判断是否“正在发生”丢包。
