物理层故障时link detected: no，需检查网线、交换机端口、光模块；link detected: yes但rx_errors上涨则关注线路干扰或对端异常；rx-ovr高说明cpu处理不过来或ring buffer过小，rx-drp高而rx-ovr为0则可能内存压力大或应用读取慢。
先看 ethtool 输出的 Link detected 和 rx_errors
如果 ethtool eth0 显示 Link detected: no，问题基本锁定在物理层：网线松了、交换机端口 down、光模块故障或双工/速率协商失败。此时不用查服务器系统，直接去机房拔插网线、换端口、换模块。若显示 Link detected: yes 但 rx_errors 持续上涨（尤其 rx_crc_errors 或 rx_frame_errors 非零），大概率是线路干扰或对端设备（交换机）发包异常——比如交换机端口损坏、镜像配置错乱、或使用了劣质光纤跳线。
对比 /proc/net/dev 的 RX-DRP 和 RX-OVR
运行 cat /proc/net/dev，重点关注网卡行的 RX-DRP（Ring Buffer 已接收但内核没来得及取走导致丢弃）和 RX-OVR（Ring Buffer 满了，新包直接被网卡硬件丢弃）：
-
RX-OVR显著增长 → CPU 处理不过来（如软中断集中在一个 CPU 核上、NAPI 调度延迟），或 Ring Buffer 太小（可通过ethtool -G eth0 rx 4096扩大） -
RX-DRP高但RX-OVR为 0 → 内存压力大、socket 接收缓冲区满、或应用读取太慢 - 两者都低，但业务明显丢包 → 问题不在本机网卡，往交换机或上游链路找
用 arping 和 ip neigh 看邻居状态是否稳定
如果丢包集中在与某台交换机直连的网段，且该交换机是二层设备，arping -I eth0 -c 5 192.168.1.1（替换为交换机管理 IP）的结果比 ping 更有说服力。因为 arping 绕过 IP 层，只走链路层；若它也丢包，说明 MAC 层通信已不可靠。再执行 ip neigh show dev eth0，观察对应交换机 MAC 条目的状态：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 状态为
REACHABLE或STALE→ 正常 - 频繁出现
FAILED或条目秒级消失 → 交换机端口学习不到本机 MAC，或启用了端口安全、DAI 等策略拦截了 ARP - 同一 MAC 对应多个 IP 或 IP 对应多个 MAC → 存在 ARP 欺骗或交换机 MAC 表震荡
在交换机侧抓包或查端口统计（需权限）
仅靠服务器端工具无法 100% 排除交换机问题。最直接的方式是登录交换机，查对应端口的错误计数：
- Huawei/Cisco：
display interface GigabitEthernet 0/0/1或show interfaces gi0/1，重点看input errors、runts、giants、CRC、collisions - 若这些值非零且随时间上升 → 交换机端口或连接线路有问题
- 若服务器侧
ethtool -S eth0中rx_no_buffer_count或rx_missed_errors上涨，而交换机端口无错误 → 问题在服务器驱动、vCPU 负载（虚拟机场景）或内核参数
没有交换机权限时，可用 tcpdump -i eth0 -c 100 'ether dst ff:ff:ff:ff:ff:ff' 抓广播包，对比发送量与服务器收到的 ARP 请求量。若大量 ARP 请求根本没到服务器，就不是网卡的事了。
