linux网络丢包需分层定位：先用ping验证真实性，再查网卡驱动（ethtool）、内核协议栈（netstat -s）、防火墙及conntrack，逐层排除物理链路、驱动、IP/udp/TCP层、socket层和策略拦截问题。
Linux网络丢包严重时，不能只盯着ping结果看丢包率，关键要定位丢包发生在哪一环——从物理链路、网卡驱动、内核协议栈到应用层，每一层都可能“吃掉”数据包。下面按排查逻辑分步说明。
先确认丢包是否真实存在
用标准方式测，避免误判：
- 执行 ping -c 100 -W 2 -i 0.2 www.baidu.com（100次、超时2秒、间隔0.2秒），观察 loss% 是否持续高于1%
- 同时加 -D 参数输出时间戳，判断丢包是否集中出现在某时段（如系统负载高峰）
- 换目标再试：ping 同网段另一台机器、ping 网关、ping 127.0.0.1；若仅对外丢包，说明问题在出口方向；若连本地回环都丢，基本是系统级异常（如高负载、内存不足、内核崩溃）
查网卡与驱动层丢包
这是最常被忽略但最容易验证的一环：
- 运行 ethtool eth0，确认 Link detected: yes、Speed/Duplex 协商正常，且无大量 rx/tx Errors 或 dropped
- 运行 ethtool -S eth0 | grep -i “drop|error|missed”，重点看 rx_missed_errors（ring buffer 溢出）、rx_dropped（NAPI 处理不及时）、rx_crc_errors（物理链路干扰）
- 对比 netstat -i 输出中的 Rx-DRP 列，若该值随时间持续增长，说明内核已开始丢弃接收包
看内核协议栈各层统计
明确丢包发生在IP层、UDP/TCP层还是socket层：
- netstat -s | grep -A 5 -B 5 “drop|overflow|full”：重点关注 Udp: 下的 receive buffer errors（socket缓存满）、packet receive errors（校验或端口错误）
- cat /proc/net/snmp | grep -A 2 “Udp:” 可看到更底层的 UDP 统计，如 InNoPorts（发给未监听端口）
- 查 TCP 重传：netstat -s | grep -A 3 “Tcp:” 中的 retransmits 和 timeouts 高，说明丢包已影响传输可靠性，但未必是本机造成
排除防火墙与连接跟踪干扰
很多“丢包”其实是被静默拦截或资源耗尽导致：
- 检查 iptables/nftables 规则：iptables -L -n -v | grep DROP，特别注意 input 链中是否有无意识的 reject/drop 规则
- 查 conntrack 表是否溢出：conntrack -S，若 insert_failed 持续上升，说明新建连接因表满被丢弃（无日志、无RST，客户端只能超时）
- 临时禁用防火墙测试：systemctl stop firewalld 或 iptables -F（测试后务必恢复）