Linux 服务器出现 RX dropped 或 TX dropped 时，先不要急着认定是网线、交换机或运营商线路故障。接口丢包计数可能产生在网卡硬件、驱动、接收环形队列、内核网络 backlog、流量控制队列、虚拟网卡乃至云平台宿主机等不同位置。正确的处理方式，是先确定计数在哪一层增长，再结合业务异常、CPU 软中断和驱动统计缩小范围。
一、先确认是否真的存在业务丢包
接口计数增加，并不一定意味着用户请求已经失败。先记录故障时间、目标地址、协议和受影响方向，再同时检查延迟、重传、超时和应用错误。建议在问题发生时保留一组基线：
date ip -s link ss -s nstat -az sar -n DEV 1 ping -c 20 目标地址 mtr -rwzc 50 目标地址
ping 和 mtr 只能提供路径层面的线索。中间设备可能限制 ICMP，因此某一跳显示丢包、但后续节点正常，并不能直接证明该跳正在丢弃业务流量。若应用使用 TCP，还要结合 TCP 重传、请求超时和服务端日志判断。
二、用 ip 查看接口总计数
ip -s link ip -s -s link show dev eth0
重点观察 RX 和 TX 两个方向的 errors、dropped、overrun 等字段是否持续增长。建议间隔 30 秒或 1 分钟采样两次，而不是只看开机以来的累计值。
RX errors：通常表示接收阶段发现了错误，但具体含义仍取决于驱动和硬件。
RX dropped：数据包在接收路径某个阶段未被继续处理，可能与缓冲区、backlog、协议处理或虚拟网络有关。
TX errors：发送过程中出现错误。
TX dropped：数据包在发出前被队列、流量控制或设备层丢弃。
不同驱动对统计字段的映射并不完全相同，所以接口总计数只能作为入口，不能单独用于判断根因。
三、用 ethtool 定位网卡和驱动层问题
ethtool eth0 ethtool -S eth0 ethtool -g eth0 ethtool -k eth0
ethtool eth0 可查看链路速率、双工模式和 Link detected 状态；ethtool -S 会显示驱动或设备提供的扩展计数。常见字段可能包含 CRC、frame、missed、no buffer、timeout、reset、queue drop 等，但字段名由驱动决定，不应脱离网卡型号和驱动文档机械解读。
如果 CRC 或 frame 类错误持续增长，优先检查物理链路、模块、线缆、交换机端口、速率与双工协商。如果 missed、no buffer 或某个 RX queue 的丢弃计数增长，则更应关注接收队列、CPU 处理能力和中断分配。
四、检查 CPU、softirq 和 IRQ 是否处理不过来
高包速率场景中，总带宽未跑满也可能丢包。大量小包会提高每秒包数，使单个 CPU、软中断或某个接收队列先达到瓶颈。
mpstat -P ALL 1 cat /proc/interrupts cat /proc/net/softnet_stat sar -n DEV 1
检查网卡 IRQ 是否长期集中在少数 CPU，以及这些 CPU 的软中断占用是否明显偏高。/proc/net/softnet_stat 可帮助发现内核网络处理队列中的丢弃或时间片耗尽，但字段布局可能随内核版本变化，解析时应参考当前内核文档、源码或发行版说明。
若多队列网卡的流量分布不均，可继续检查 RSS、RPS、RFS、XPS、irqbalance 和 CPU 亲和性。调整前先记录队列计数和 CPU 基线；错误的亲和性设置可能把压力进一步集中到单核。
五、检查 ring buffer 与内核 backlog
接收速度短时间超过内核处理速度时，RX ring 或内核 backlog 可能溢出。先查看网卡支持值和当前值：
ethtool -g eth0 sysctl net.core.netdev_max_backlog sysctl net.core.netdev_budget sysctl net.core.netdev_budget_usecs
不要看到丢包就直接把所有缓冲参数调到最大。更大的队列可能吸收短时突发，但也可能增加排队延迟和内存占用，并掩盖 CPU、驱动或应用处理不足的问题。合理做法是一次只调整一个变量，在业务低峰灰度修改，同时观察丢包、延迟、CPU、内存和队列长度。
六、排查 TX 队列和流量控制
如果主要是 TX dropped，应查看 qdisc、发送队列和出口整形规则：
tc -s qdisc show dev eth0 ip -s link show dev eth0 ip link show dev eth0
tc -s qdisc 中的 dropped、overlimits 和 backlog 可以说明数据包是否在流量控制层排队或被丢弃。限速策略、队列长度、突发流量以及下游链路拥塞，都可能导致发送方向计数增加。修改 qdisc 前，应先导出现有配置并准备回滚命令。
七、检查 MTU 与 offload
ip link show dev eth0 ethtool -k eth0 ping -M do -s 1472 目标地址
主机、虚拟网卡、隧道、负载均衡器和上游网络的 MTU 不一致，可能引起分片、丢弃或“部分请求正常、大包请求失败”。带 VXLAN、GRE、VPN 等封装时，需要给额外头部预留空间。
GRO、GSO、TSO、LRO 和 checksum offload 会改变抓包时看到的数据包形态。不要仅因 tcpdump 中出现看似异常的校验和就认定线路错误，也不要在生产环境一次性关闭全部 offload。若需要验证，应逐项临时测试并观察 CPU 与吞吐变化。
八、虚拟机、容器和云服务器要逐层检查
在虚拟化环境中，丢包可能出现在 guest 网卡、veth、bridge、tap、宿主机物理网卡或云平台虚拟交换层。容器场景可分别检查：
ip -s link ip -d link tc -s qdisc show nsenter -t <PID> -n ip -s link
如果虚拟机内部计数正常，但应用仍出现重传或超时，需要结合宿主机和云平台监控。普通云主机通常看不到底层物理 NIC 的完整驱动统计，此时应保留时间点、实例、可用区、五元组和抓包证据，交给云服务商进一步核查。
九、推荐的排查顺序
确认异常时间、接口、流量方向和受影响业务。
连续采样
ip -s link，确认哪些计数正在增长。使用
ethtool -S区分物理、驱动和队列线索。检查 CPU、softirq、IRQ 分布及每秒包数。
分别检查 RX ring、softnet backlog 和 TX qdisc。
核对 MTU、隧道封装与 offload 设置。
在虚拟化环境中逐层检查 guest、veth、bridge、host 和云平台。
一次只做一项可回滚调整，再用相同负载复测。
十、修复后如何验证
修复是否有效，不能只看某个累计计数仍然大于零。应记录变更前的时间窗口，再比较变更后单位时间的增量：
ip -s -s link show dev eth0 ethtool -S eth0 sar -n DEV 1 ss -s nstat -az
同时验证业务请求成功率、P95/P99 延迟、TCP 重传、CPU softirq、队列 backlog 和吞吐。若丢包减少但延迟明显升高，可能只是把“丢弃”变成了更长时间的排队，仍需继续优化。
常见问题
RX dropped 增长一定是网卡坏了吗？
不一定。它也可能来自驱动队列、内核 backlog、虚拟接口或协议处理。应结合 ethtool -S、softnet、CPU 和链路错误计数判断。
带宽没有跑满，为什么仍会丢包？
瓶颈可能是每秒包数而不是每秒比特数。大量小包、单队列热点、单核软中断或突发流量，都可能在总带宽达到上限前造成丢包。
可以直接增大 netdev_max_backlog 吗？
可以作为经过验证的调优选项，但不应作为默认答案。先确认 softnet 队列确实溢出，并评估延迟、内存和 CPU；修改后要监控并保留回滚值。
为什么 tcpdump 显示 checksum incorrect？
发送方向的校验和可能由网卡 offload 在数据包离开主机前计算，因此主机内抓包看到的值不一定代表线上数据包错误。可结合对端抓包、驱动统计和 offload 状态验证。
结论
Linux 网卡丢包排查的关键，不是看到 dropped 就立即修改内核参数，而是先确定丢包发生在物理链路、驱动队列、softnet、流量控制还是虚拟网络层。用 ip 建立总览，以 ethtool、CPU/IRQ、softnet_stat 和 tc 逐层定位，再进行单变量、可回滚的调整，才能避免把真实瓶颈转移到其他位置。
参考资料
Linux man-pages：ip-link(8)，核查日期：2026-09-07
Linux man-pages：ethtool(8)，核查日期：2026-09-07
Linux Kernel Documentation：Interface statistics，核查日期：2026-09-07
Linux Kernel Documentation：Scaling in the Linux Networking Stack，核查日期：2026-09-07
