服务器网卡丢包排查需分层验证：先查物理连接与led指示灯、ethtool确认链路状态；再用netstat -i和ethtool -s分析收发错误；接着通过ping网关/外网及mtr定位丢包节点；最后tcpdump抓包+wireshark验证协议层问题，并测试mtu匹配性。
检测服务器网卡链路状态并排查丢包故障，核心是分层验证：从物理连接→网卡硬件/驱动→系统协议栈→网络路径→安全策略，逐级排除。不能只看 ping 结果，要结合多工具交叉印证。
一、确认物理与链路层状态
先排除最基础的硬件和连接问题：
- 观察网卡 LED 指示灯：常亮表示链路连通，闪烁表示有数据收发；完全不亮或异常快闪，优先检查网线、交换机端口、网卡插槽
- 执行 ethtool eth0（替换为实际网口名）：关注 Link detected: yes、Speed（如 1000Mb/s）、Duplex（应为 Full）、Auto-negotiation（建议开启）；若显示 no 或 Unknown，说明物理层未协商成功
- 检查网线是否松动或老化——尤其在机房环境，可临时更换网线或换到其他交换机端口复测
二、查看网卡收发统计与错误计数
用内核暴露的底层指标判断是否真丢包，而非上层误判：
- 运行 netstat -i | grep eth0：重点看 RX-ERR/TX-ERR、RX-DROP/TX-DROP、collisions 列。非零且持续增长，说明网卡或驱动层面已开始丢弃
- 更详细统计用 ethtool -S eth0：查找 rx_errors、tx_errors、rx_missed_errors（接收缓冲区溢出）、rx_over_errors（FIFO溢出）、rx_frame_errors（CRC校验失败）等字段
- 若 rx_missed_errors 高，常见于流量突增、中断处理不及时（如 RPS/RFS 未启用或多队列未均衡），需调优内核网络参数
三、验证网络路径与定位丢包节点
区分是本地网卡问题，还是中间链路或远端问题：
- 先 ping 网关（如
ping -c 50 192.168.1.1）：若丢包，问题在本地局域网（交换机、网线、网卡） - 再 ping 外网 DNS（如
ping -c 50 8.8.8.8）：若网关不丢包但外网丢包，说明问题在上行链路或运营商侧 - 用 mtr --report -c 100 目标IP 替代 traceroute：它同时给出每跳的延迟和丢包率。重点关注哪一跳开始出现 * 或丢包率骤升（如第5跳 0%，第6跳 25%），该节点即故障点
- 注意：部分中间节点屏蔽 ICMP，mtr 中显示 * 不一定代表故障，需结合 tcpdump 抓包进一步确认
四、抓包分析与协议层验证
确认丢包是否真实发生，以及发生在哪一层：
- 在服务器上运行 tcpdump -i eth0 icmp and host 目标IP -w ping.pcap，同时另一终端 ping 目标IP
- 用 Wireshark 打开 pcap 文件，过滤
icmp，查看是否发出 Echo Request 但无 Echo Reply；或 Reply 明显少于 Request - 若 Request 发出但无 Reply，且 mtr 显示某跳丢包 → 链路问题；若 Request 和 Reply 都存在但应用仍超时 → 可能是防火墙拦截回复、TCP 层重传或应用层处理慢
- 补充检查：用 ping -s 1472 -M do 8.8.8.8 测试 MTU 是否匹配（1472 + 28 字节 ICMP 头 = 1500），避免因分片导致丢包
