用 mtr 定位丢包位置：若仅末跳丢包，多为服务端问题；若中间某跳持续高丢包，则锁定该网络设备；需结合 tcping 验证端口、netstat -i 查 RX-OVR/RX-DRP、tc qdisc 检查 netem 丢包、iptables/conntrack 排查内核过滤、tcpdump 抓包确认是否入栈、ss -i 分析套接字层接收队列堆积。
用 ping 和 mtr 判断丢包是否在链路中
先确认丢包真实存在，且不是本地或远端单点问题。直接 ping 只能告诉你“有没有丢”，但没法说清“在哪丢”。这时候必须上 mtr——它一边 traceroute 逐跳探测，一边持续 ping 每一跳，输出里每行的 Loss% 就是关键证据。
- 如果只有最后一跳（目标主机）丢包，大概率是服务端问题（如 Nginx 未监听、防火墙拦截、应用崩溃）
- 如果中间某跳（比如第 4 跳）持续 >10% 丢包，而前后跳正常，基本锁定该网络设备（运营商节点、IDC 接入交换机等）有问题
- 注意：部分路由器禁 ICMP 回复，
???或高 Loss% 是假阳性，需结合tcping -x 5 www.example.com 443验证业务端口是否真不通
查网卡统计：别让 RX-OVR 欺骗你
netstat -i 输出里的 RX-OVR（Ring Buffer 溢出）常被当作“网卡扛不住”的铁证，但现实更复杂：它只反映驱动层 Ring Buffer 满了之后丢包，不包括后续协议栈各层丢弃。更隐蔽的是——tc qdisc 配置的丢包（比如 netem loss 30%）完全不会出现在这里。
- 执行
netstat -i，重点看RX-DRP（进缓冲区后因内存不足等丢）和RX-OVR是否持续增长 - 若两者都为 0，但业务明显丢包，立刻检查 QoS：
tc qdisc show dev eth0，尤其留意含loss、limit、delay的netem规则 -
ethtool -S eth0 | grep -i "drop\|overrun"可看到更底层硬件计数，但虚拟网卡（如 virtio）这些字段常为 0，不可全信
绕过 iptables 和 conntrack 看真实流向
很多丢包根本不是网络问题，而是被内核“主动杀掉”了。iptables 的 DROP 规则不记日志时，包就静默消失；更麻烦的是连接跟踪（conntrack）满表导致新连接 SYN 包被丢，现象和网络中断一模一样。
- 临时清空过滤链验证：
iptables -P INPUT ACCEPT; iptables -P FORWARD ACCEPT; iptables -F（操作后务必恢复） - 查 conntrack 压力：
conntrack -S看entries是否接近max，再用sysctl net.netfilter.nf_conntrack_max确认上限 - 抓包验证是否真到协议栈：
tcpdump -i eth0 -n 'host 192.168.0.30 and port 80'。如果 tcpdump 没抓到包，但 mtr 显示最后一跳通——说明包压根没进本机，问题在链路或对端防火墙
套接字层丢包：ss -i 比 netstat -s 更准
当 TCP 连接已建立但数据收发异常，netstat -s | grep -i "retransmit\|drop" 只给汇总值，无法定位具体 socket。而 ss -i 能显示每个连接的重传、SACK、接收队列溢出（rcv_space vs rcv_rtt）等实时指标。
- 查接收队列堆积：
ss -tin state established '( dport = :80 )' | head -10，关注skw（发送队列）、skr（接收队列）和rcv_space - 若
skr接近rcv_space且持续不降，说明应用读取太慢，内核被迫丢后续包（TCP RcvQ Full类丢包） - 对比
ss -s中packets received和with invalid CSUM差值，可粗略估算校验失败丢包比例
真正难缠的丢包，往往藏在“看似正常”的环节里：tc 规则无声无息吃掉 30% 包，conntrack 表满导致新连接永远卡在 SYN_RCVD，甚至应用层 recv() 调用太慢，让内核在套接字缓冲区就把包扔了——这些都不会在 ping 或 ifconfig 里报错，必须一层层剥开协议栈验证。
