服务器侧排查丢包，核心不是盯着服务器发呆，而是先用ping和mtr把丢包路段切成“客户端链路、接入设备、服务器网卡、内核协议栈”四段，逐一排除。下面这四步按顺序走完，问题基本能从一堆可能性里被逼出来。
网络丢包服务器侧排查：先确认丢包发生在哪一跳
很多人一收到丢包告警,就急着登录服务器抓包，这个习惯得改。抓包只能证明“应用层确实丢了”，证明不了“丢在哪一层”，甚至会让你被海量流量淹没。
先把范围切清楚,需要做三组基准测试：
- ping 127.0.0.1丢包说明本机协议栈已坏，概率极低，但值得花十秒排除。
- ping 网关丢包说明二层链路或本机网卡有问题。
- ping 公网业务IP丢包说明问题出在三层以上路径。
然后是mtr,这是判断丢包路段最有用的工具，执行 mtr -rw 目标IP，它会列出每一跳的丢包率，这里有个容易误判的细节：最后一跳丢包率高，往往不代表服务器有问题，而是路由器不回应探测包，真正要看的是起始几跳的丢包率，以及整条路径丢包率是否呈“突然升高”的断层。
如果从电信、联通、移动多个网络分别测同一个服务器，丢包现象一致，那问题大概率在服务器或靠近服务器的接入链路，如果只有某一个地区丢，问题多半在中间运营商互联节点。
网络丢包严重怎么排查：把带宽和链路状态盘一遍
确认了丢包路段之后,网络丢包严重怎么排查这个问题就落到两个词上：带宽打满和链路劣化。
先查带宽,登录服务器执行 sar -n DEV 2 5，观察流量是否接近网卡上限，如果是，再用 iftop -i eth0 -n 按IP排序，找出谁是流量大头，常见场景是备份任务在高峰期跑满带宽，或是被某台失陷主机当作肉鸡对外发包，把出口挤爆了。
接着查链路质量。爬上交换机，看端口统计里的CRC错误、FCS错误、runts和丢包计数，这几个数值只要在上涨，物理链路或光模块大概率在闹脾气。
| 现象特征 | 排查方向 | 高频根因 |
|---|---|---|
| 小包通、大包丢 | MTU路径黑洞 | 防火墙拦截ICMP不可达、中间设备MTU不一致 |
| 白天正常、深夜丢 | 光模块/光纤衰耗 | 光模块DDM告警、光纤接头污染 |
| 双向等比例丢包 | 物理链路 | 网线或光纤质量差、端口协商异常 |
| 连接一多就开始丢 | 设备转发能力 | 交换机缓存不足、QoS队列被占满 |
MTU问题有个经典特征：小包通畅，需要分片的大包直接消失，可以用 ping -M do -s 1472 目标IP 测试，如果通，说明路径MTU至少1500，被防火墙拦截ICMP时，服务器收不到“需要分片”的通知，就会一直硬塞大包，被动丢包，行业共识认为，跨地域链路中“小包通大包不通”的故障，绝大多数是MTU分片机制和ICMP策略共同造成的。
云服务器丢包原因：服务器本地的几个隐蔽角落
物理链路查完,毛病还在，就得把注意力搬回服务器本身，云服务器丢包原因里，网卡软队列和内核连接跟踪表两处最容易出事。
先看网卡层,执行 ip -s link show eth0，注意RX/TX的errors、dropped、overruns三个计数，overruns增长说明网卡环形队列（ring buffer）满了，数据包根本没进内核就被丢了，接着用 ethtool -S eth0 | grep -Ei 'drop|error|miss' 查详细原因，重点关注rx_missed和rx_fifo_errors。
如果队列溢出频繁,可以调大ring buffer：ethtool -G eth0 rx 4096，但这不是根治方案，得检查CPU软中断分配。
top 里看si（软中断占用），如果某个核心的si飙到高位，其他核心闲置，就是中断分配不均，解决思路是启用网卡多队列（RSS），或者打开RPS让中断分摊到多个CPU核心。
再看内核协议栈,执行 netstat -s | grep -i listen，如果listenOverflows在增长，说明TCP半连接或全连接队列溢出，客户端请求在握手阶段就被内核丢弃，业务表现为连接建立慢、偶发超时，但ping一切正常，业内专家指出，云服务器丢包大多数时候并不在物理网卡，而是宿主机的虚拟交换机软队列或连接跟踪表先扛不住。
连接跟踪表是云服务器另一个常见丢包点,高并发场景下，nf_conntrack 表会被打满，新连接直接被丢弃，表现为ping通但TCP建连失败，执行 sysctl net.netfilter.nf_conntrack_count 和 sysctl net.netfilter.nf_conntrack_max 对比，如果当前值接近上限，要么调大max，要么排查是否有大量异常TIME_WAIT连接堆积。
服务器丢包排查命令：一套组合拳逐层确认
实操环节,所有命令可以按顺序串成一套动作，照着敲就行：
- 三层定位：
ping -i 0.2 -c 100 网关IP，观察丢包是否稳定均匀，稳定丢包多半是链路劣化，间歇丢包更像拥塞。 - 接口统计：
ip -s link show eth0，看dropped和errors。 - 网卡细节：
ethtool -S eth0 | grep -Ei 'drop|error|miss'，区分rx和tx方向。 - 队列溢出：
ethtool -g eth0看当前ring buffer值。 - 内核统计：
netstat -s | grep -Ei 'drop|retrans|listen'，查TCP重传和队列溢出。 - 内核丢包观测：执行
dropwatch -l kas，输入start后开始实时跟踪，close停止，它能告诉丢包发生在哪个内核函数路径上，比如是协议栈处理不过来，还是socket缓冲区被挤爆。 - 抓包验证：
tcpdump -i eth0 -w /tmp/drop.pcap，用Wireshark打开后看DUP ACK和乱序包，如果大量DUP ACK出现，说明链路里确实有包没到；如果重传很少，那“丢包”很可能只是应用层响应慢造成的错觉。
这套组合拳的核心逻辑是从接口层往内核层收窄，最后才动抓包工具，直接抓包容易被流量淹没，反而不容易定位。
据统计,自建机房中相当一部分丢包问题源于网卡驱动与固件版本不兼容，表现特征是：ping不超时，丢包率稳定在很低的水平，但吞吐上不去，遇到这类情况，更新网卡驱动往往比调一堆内核参数更管用。
关于网络丢包服务器侧排查的高频疑问
问：ping本机不丢，ping网关就丢，问题出在哪？
大概率在二层链路,检查网线或光纤接口是否松动，用 ethtool eth0 查看协商速率，需要确认是否出现半双工状态，两端速率不匹配也会造成低速率丢包，多数情况下，换一根网线或强制固定两端速率就能恢复。
问：游戏服务器掉线排查时，丢包率不高但玩家频繁掉线，是什么原因？
关注TCP层,丢包率不高却频繁掉线，通常不是物理链路问题，而是服务器连接数打满，或者负载均衡后端健康检查失败导致节点被摘除，抓包观察SYN包和SYN-ACK包的交互即可确认，没有SYN-ACK响应往往是连接跟踪表满，有SYN-ACK但连接还是断，则是应用层超时设置过短。
问：服务器丢包率多少算正常？
内网链路的丢包率应该无限接近0,公网环境下，连续ping 1000个包，丢包率在0.1%以内可视为正常链路波动，一旦超过1%，业务就会明显感知，游戏和实时音视频这类场景超过0.5%就会有卡顿。