排查linux网络丢包应先验证是否真丢包，再分层定位：先用ping、netstat -i、ss -s和tc qdisc检查硬件、驱动、队列及人为策略，再针对性tcpdump抓包分析tcp握手、重传与ack模式，最后结合somaxconn等内核参数交叉验证。
排查 Linux 网络丢包，抓包不是第一步，而是验证环节的关键动作——前提是已初步锁定问题范围。盲目抓包容易淹没在海量数据中，真正有效的方式是“先缩小范围、再精准捕获、最后分层分析”。
先确认是否真丢包，再决定抓哪里
很多所谓“丢包”其实是协议栈内部丢弃（如队列满、防火墙拦截）或重传误判，并非链路丢失。操作顺序很关键：
- 用 ping -c 100 目标IP 看基础连通性与丢包率；
- 用 netstat -i 查网卡统计：重点关注 RX-DRP（接收后丢弃） 和 RX-OVR（环形缓冲区溢出） 是否持续增长；
- 用 ss -s 查 TCP 统计，观察 retransmitted 和 synrecv 数值是否异常升高；
- 检查 tc qdisc show dev eth0，确认是否有 netem 等人为丢包策略启用。
选对网卡和过滤条件，避免无效数据
抓包位置直接影响结论可靠性。若怀疑服务端丢包，必须在服务端网卡抓；若怀疑中间设备问题，需两端同时抓并比对。常用 tcpdump 命令示例：
- 只抓目标 IP 和端口的 TCP 包：tcpdump -i eth0 host 10.1.2.3 and port 8080 -w out.pcap；
- 排除本机 SSH 干扰，专注业务流量：tcpdump -i eth0 'tcp and not port 22' -w app.pcap；
- 限制包大小节省空间（避免截断）：tcpdump -i eth0 -s 65535 ...；
- 加 -nn 跳过 DNS 反查，提升实时性；加 -q 减少输出冗余。
聚焦三层关键现象，快速定位丢包环节
打开 pcap 文件（可用 Wireshark 或 tshark），不看全量，直奔三类信号：
- TCP 握手失败：客户端发 SYN 后无 SYN+ACK 回复 → 检查服务端端口监听状态（ss -tlnp | grep 端口）、防火墙（iptables -L -n -v）、SYN 队列是否溢出（netstat -s | grep -i "listen overflows"）；
- 大量重传且无 ACK：说明包发出后对方根本没收到 → 问题可能在链路层（网卡驱动、MTU 不匹配、交换机 ACL）、或中间网络设备（如 QoS 限速丢包）；
- 有 ACK 但应用层无响应：比如 HTTP 请求发出去，收到 TCP ACK，但无 HTTP 响应 → 问题大概率在应用进程本身（卡住、崩溃、未读取 socket 缓冲区）或内核套接字队列（ss -ti 中 rmem/ wmem 接近 max，或 drops 字段非零）。
结合内核参数交叉验证丢包原因
抓包发现重传集中、rto 波动大、连接频繁 reset，要立刻检查几个关键内核参数：
- net.core.somaxconn：全连接队列上限，小于并发连接数时会丢新连接；
- net.ipv4.tcp_max_syn_backlog：半连接队列上限，SYN 洪水或瞬时建连高峰易触发丢弃；
- net.ipv4.ip_local_port_range：本地端口范围过小会导致 TIME_WAIT 耗尽端口；
- 查看方式：sysctl net.core.somaxconn；修改后需 sysctl -p 生效。
