Linux网络丢包需逐层排查：从物理链路、驱动、内核协议栈、防火墙到上层服务；先用ethtool、netstat、netstat -s定位丢包位置，再针对性tcpdump抓包分析，注意伪丢包场景如conntrack满、offload干扰等。
Linux网络丢包不能只盯着应用层或某一个环节，得从物理链路、驱动、内核协议栈、防火墙到上层服务逐层排查。抓包是手段，链路分析才是关键——先确认丢包发生的位置，再决定在哪抓、怎么抓、看什么字段。
一、快速定位丢包发生在哪一层
丢包可能出现在：网线/光模块故障、交换机端口限速、网卡驱动异常、内核收发队列溢出、iptables/nftables规则丢弃、TCP重传超时等。别一上来就 tcpdump，先用基础命令缩小范围：
- 看网卡硬件状态：运行 ethtool eth0，重点关注 Link detected: yes（物理连通）、Speed/Duplex（协商是否正常）、rx/tx errors 和 dropped（驱动层丢包）
- 查内核收发统计：运行 netstat -i 或 cat /proc/net/dev，对比 Rx dropped 和 Tx dropped —— 若 rx dropped 持续增长，可能是中断风暴、NAPI 调度不及时或 ring buffer 溢出；若 tx dropped 高，常见于 qdisc 队列满（如 pfifo_fast 默认只有 1000 包）
- 检查连接级重传：运行 netstat -s | grep -A 5 "Tcp:"，关注 retransmits 和 timeouts；高重传率说明丢包已影响到 TCP 层，但未必是本机问题，需结合对端日志交叉验证
二、针对性抓包：在哪抓、抓什么、怎么看
抓包位置决定你能看到什么。同一丢包现象，在不同位置抓包结论可能完全相反：
- 网卡入口（-i eth0）：能看到所有进来的原始帧，包括被 iptables INPUT 丢弃的包。若这里没抓到目标请求，说明丢包在物理链路或上游设备
- lo 接口：用于排查本地服务间调用（如 curl localhost），可排除网卡和网络路径干扰
- 加 -n -t -S 参数组合：避免 DNS 解析延迟、打印时间戳、显示绝对序列号（-S），便于比对重传行为。例如：tcpdump -i eth0 -n -t -S port 8080
- 关注关键字段：SYN 未回复 → 对端未收到或拒绝；ACK 未到达 → 中间丢包；重复 ACK + 后续重传 → 接收方丢包或乱序严重；RST 突然出现 → 应用主动关闭或防火墙拦截
三、常见易忽略的“伪丢包”场景
有些现象看似丢包，实为机制或配置导致，不必深挖链路：
- iptables LOG 规则未接 DROP：只记录不丢弃，日志里看到大量匹配但连接正常，容易误判为丢包源
- conntrack 表满：运行 conntrack -S 查看 insert_failed，值持续上升会导致新建连接被静默丢弃（无 RST，客户端超时）
- 网卡 offload 功能干扰抓包：TSO/GSO/LRO 可能导致 tcpdump 看到“巨帧”或分段异常。临时关闭：ethtool -K eth0 tso off gso off lro off
- 容器或虚拟网卡路径复杂：如 veth-pair + bridge + iptables + cni 插件，建议在 veth 主机侧、容器 netns 内、宿主机物理口分别抓包，画出数据流向图再比对
四、实用诊断组合命令速查
把高频操作固化成一行命令，减少排查盲区：
- 查实时丢包+错误：watch -n 1 'ethtool eth0 | grep -E "(Speed|Link|errors|dropped)"; echo; cat /proc/net/dev | grep eth0'
- 抓最近 10 秒 HTTP 流量并保存：timeout 10 tcpdump -i eth0 -w /tmp/http.pcap port 80 or port 443
- 查本机所有连接的重传统计：ss -i | awk '$1 ~ /^[te]/ {print $1,$2,$3,$NF}' | grep retrans
- 检查是否被 conntrack 拦截：grep -r "nf_conntrack" /proc/sys/net/netfilter/; conntrack -S
