云服务器网络丢包如何解决?从“时断时续”到“稳如磐石”的排查指南

那天晚上，我正在和一个远程团队进行视频会议，聊到关键方案的时候，对方的声音突然变成了“机器人”，断断续续，画面也卡住了。紧接着，屏幕上弹出了一行提示：“网络不稳定”。我切换到手机热点，会议才得以继续。会后我检查了云服务器上的服务，发现一切运行正常，但监控系统赫然记录着：过去一个小时出现了百分之二到百分之三的丢包率。

网络丢包，大概是云服务器使用者最头疼的问题之一。它不像宕机那样直接给你一个痛快，而是像牙疼一样，时不时发作一下，让你的服务变得难以忍受。一个HTTP请求，可能因为丢包而重传，导致响应时间从几十毫秒变成几秒。一个实时音视频流，可能会因为丢包而花屏、卡顿。一个数据库同步，可能会因为丢包而延迟暴增。今天，我就把处理云服务器网络丢包的经验做一个系统性的总结，希望能帮你从“为什么这么卡”的困惑中走出来。

什么是丢包?通俗地说，就是你的服务器发送出去的网络数据包，或者客户端发过来的数据包，在半路上丢失了，没有到达目的地。TCP协议因为有重传机制，丢包会自动补救，但代价是延迟大大增加。UDP协议没有重传，丢包就直接表现为数据丢失。无论是哪种情况，用户感受到的都是“卡”和“不稳定”。

我处理过最复杂的一个丢包案例，发生在一年前。一家做在线棋牌游戏的公司，他们的用户在晚上高峰时段频繁“掉线”，但不是完全断开，而是游戏动作延迟几秒钟才生效。他们检查了服务器CPU和内存，都很正常，带宽也没有跑满。他们一度认为是游戏服务器的代码有bug，花了两个星期重构了网络模块，问题依旧。我介入之后，第一件事就是在游戏服务器上用ping命令持续向客户端IP发送测试包，发现丢包率随着在线用户数的增加而上升，从百分之零点五逐渐攀升到百分之三。我又用mtr工具追踪路由，发现丢包并不是发生在某一个固定的路由器上，而是云服务器的出口网卡本身就有少量的丢包计数。最后我登录云控制台，查看了云服务商提供的网络出入方向丢弃数据包统计，发现入方向的一个队列有大量的溢出丢弃。原来他们的游戏服务器有一个防攻击的配置，限制了单个源IP的连接数，但是限制得太严格了，正常的高频游戏数据包被误判为攻击流量而丢弃。调高了那个阈值之后，丢包率立刻降到了零。这个案例让我意识到，丢包的根源可能藏在你根本没有注意到的配置里。

下面，我把导致云服务器网络丢包的常见原因分成几大类，每一类都说清楚现象、排查方法和解决方案。

第一类，物理链路和运营商层面的丢包。

这是最外层的原因。你和云服务器之间的网络要经过很多段：你家里的路由器、你所在小区的宽带汇聚、运营商的城市骨干网、跨省的骨干网、云服务商的入口路由器、云服务商内部的虚拟网络，最后才到你的云服务器。其中任何一段的光纤劣化、路由拥塞、设备故障，都可能导致丢包。这种丢包的特点是不受你服务器内部配置的影响，而且往往有地域性，比如某个城市的用户都卡，其他城市正常。

怎么判断是不是运营商层面的丢包?用mtr这个工具。mtr结合了ping和traceroute，它能显示从你的电脑到云服务器的每一跳路由器上，丢包率和延迟分别是多少。运行mtr 你的云服务器IP，等待几分钟，看结果。如果发现中间某一跳的丢包率很高，但是后续的跳数丢包率又降下来了，那通常是因为中间那个路由器设置了高优先级转发，它不回应ICMP测试包，但实际转发的数据包并没有丢。这种情况不用管。如果发现某一跳的丢包率很高，并且后面的所有跳数丢包率同样高或者更高，那问题就出在这一跳或者它的下游。这时候你可以把mtr的结果截图，发给你的宽带运营商或者云服务商的技术支持，让他们去协调处理。

我亲身经历过一次，公司从北京访问上海机房的云服务器，晚上八点到十点之间丢包严重。用mtr一看，丢包全部集中在北京联通的某个骨干节点上，过了那个节点之后延迟也异常高。经过多次投诉，联通方面确认是有一条光缆被施工挖断了，流量绕了远路导致拥塞。修好之后丢包消失。这种问题作为普通用户无法直接解决，但至少知道了不是自己服务器的问题，心里就有底了。

第二类，云服务商的安全组或者防火墙限速丢包。

云服务商为了保护整个网络不被某个实例的异常流量拖垮，通常会在虚拟交换机层面做限速。比如你的带宽买的是5Mbps，如果你持续发送超过5Mbps的流量，云服务商的虚拟交换机就会主动丢弃超过配额的数据包。这种丢包是“有纪律的”，你发的越多，丢的越多。表现就是服务器的出方向或者入方向流量曲线，像被削平了脑袋一样，平顶之后就是丢包。

怎么确认是不是限速丢包?登录云控制台，查看网络带宽的使用监控。如果看到带宽指标经常顶着上限跑，呈一条平直的线，同时观察云主机内部的网卡流量统计，发现内部统计的发送字节数大于控制台显示的，那么多出来的部分就是在交换机层面被丢弃了。解决方案也很直接——升级带宽配额。或者优化程序，减少不必要的网络传输，比如压缩数据、合并小包请求、减少日志输出等。

还有一个容易被忽略的点：云服务商对单个数据包的速率也有隐性限制。比如有些云平台对每秒新建连接数有限制，超过限制的新连接SYN包会被直接丢弃，导致客户端连接超时。还有一个是小包限速，如果你发送大量的小于64字节的数据包，可能会被视为攻击而丢弃。这些问题通常不会写在官方文档的显眼位置，需要通过工单咨询或者踩坑之后才知道。

第三类，云主机操作系统内部的协议栈和网卡驱动问题。

数据包通过云服务商的虚拟网络后，会交给云主机操作系统内核的网卡驱动。如果内核的协议栈参数配置不当，或者网卡驱动有bug，也可能产生丢包。最常见的有两种情况：环形缓冲区太小导致丢包，和反向路径过滤导致丢包。

环形缓冲区是网卡驱动用来暂存收发包的内存区域。如果短时间内有大量突发流量涌入，环形缓冲区满了，后续的新包就会被丢弃。你可以在系统里用ethtool -S eth0 | grep drop命令查看网卡的丢包计数。如果发现rx_dropped或者tx_dropped计数很高，就说明是环形缓冲区不足导致的丢包。解决办法是增大环形缓冲区的大小，通过ethtool -G eth0 rx 4096 tx 4096这样的命令调整，具体数值要根据你的云主机的内存大小和流量特征来设置。

反向路径过滤是Linux内核的一个安全特性，它会检查进入的数据包是否从“正确”的网络接口进来。如果你有一台云主机有多个网卡，或者配置了策略路由，反向路径过滤可能会把合法的数据包误认为是伪造的而丢弃。你可以查看/proc/sys/net/ipv4/conf/all/rp_filter的值，0表示关闭过滤，1表示严格过滤，2表示松散过滤。如果这个值设置为1，并且你的网络配置比较复杂，可以临时改为2或者0来测试是否解决了丢包问题。

还有一个经典的内核参数：net.core.netdev_max_backlog，它控制了当内核处理报文速度跟不上网卡接收速度时，最多缓存多少个包。如果这个值太小，突发流量来了也会丢包。一般可以调大到比如100000。另外，/proc/sys/net/ipv4/tcp_max_syn_backlog控制着半连接队列的大小，如果SYN flood攻击或者高并发新建连接，队列满了就会丢弃新的SYN包。

第四类，应用层和TCP协议栈的参数不匹配。

有时候丢包不是真的丢了，而是对方等不及了。比如TCP的RTO重传超时设置过长，或者重试次数过少，会导致连接异常断开。或者在移动网络环境中，IP切换导致旧连接失效，也会表现为丢包。还有NAT网关的会话表老化时间过短，长时间没有数据活动的TCP连接会被中间设备清理掉，当再有数据发送时，实际已经丢了。

我有一个做即时通讯的客户，他们的App经常出现消息发送失败的情况。抓包分析后发现，手机端因为切换到WiFi或者4G网络，源IP发生了变化，但TCP连接还是旧的，服务器端发往旧IP的数据包全部丢失。解决方法是让客户端在检测到网络切换后主动重建连接，或者使用MQTT这类专门为移动网络设计的协议，而不是长期保持的TCP长连接。

另外一个常见的问题是MTU不匹配。最大传输单元MTU定义了单个数据包的大小上限。如果云主机的MTU设置是1500字节，而中间某个路由器只能处理1492字节，那么超过1492字节的包就会被拆分成碎片，如果碎片到达不了，就相当于丢包。更严重的是，有些防火墙会丢弃ICMP分片需要的消息，客户端和服务器无法协商出更小的MTU，导致大包一直发不出去。这种情况表现为小文件或者小消息正常，大文件上传下载总是失败或者卡住。解决办法是在服务器和客户端都启用路径MTU发现，或者手动将MTU调低到比如1400字节，避开大部分限制。

第五类，遭受DDoS攻击或者扫描导致的丢包。

当你的云服务器成为攻击目标时，攻击者会发送海量的数据包，占满你的带宽或者耗尽你的连接资源。这时候，正常的用户请求就会被挤掉，表现为高丢包率。这种丢包的典型特征是，突然发生，丢包率极高，而且伴随着异常的流量峰值。云服务商一般都会提供基础防护，但超过阈值后会触发黑洞或者清洗。

我处理过一个攻击案例。客户的小网站突然打不开了，ping的时候丢包率达到了百分之九十以上。登录云控制台看到，入向流量瞬间冲到了几个Gbps，而平时只有几Mbps。这是典型的DDoS攻击。客户的云主机配置不高，也没有购买高防服务。我建议他立即联系云服务商开启黑洞引流，把攻击流量导向清洗中心。清洗之后，丢包率降到百分之零点几，网站恢复正常。后来他购买了云服务商提供的高防IP服务，把域名解析到高防IP上，攻击流量在高防节点就被过滤了，源站云主机再也不受冲击。

还有一种不是针对你的，但是受牵连的丢包。比如同一台物理机上的其他云主机被攻击，整台物理机的网络出口被打满，你的云主机作为邻居也遭殃。这种丢包虽然少见，但在共享型实例上确实有可能发生。如果你怀疑这种情况，可以多次迁移云主机到不同物理机，或者升级到独立资源的实例类型。

第六类，应用进程处理能力不足导致的丢包。

最后一个原因，可能出乎很多人的意料：你的应用程序处理请求太慢了。当数据包被内核接收后，会被放到socket接收缓冲区中，等待应用程序调用recv读取。如果应用程序来不及读，缓冲区满了，内核就会丢弃新到达的数据包。这种现象表现为：服务器CPU使用率很高，或者应用程序日志里出现大量的“队列已满”的报错，而网络层面没有明显的丢包统计。

我遇到过这样一个问题。一个客户用Node.js写了一个HTTP服务，每次请求都要做一次复杂的数据库查询和图片处理。在低并发时，一切正常。但在高并发时，大量请求积压，Node.js事件循环被阻塞，来不及调用recv从内核缓冲区取数据。内核的TCP接收缓冲区以肉眼可见的速度增长，直到达到上限，然后开始丢包。客户看到丢包，以为是网络问题，加了带宽、换了好交换机还是没有用。后来我们在应用程序前面加了一层反向代理，并且优化了数据库查询和图片处理的异步化，应用程序的处理能力提升了好几倍，核缓冲区再也没有溢出过，丢包自然消失了。

所以，当你排查丢包的时候，一定要同时看应用程序的处理速度。用netstat -an命令查看各个端口的Recv-Q和Send-Q队列长度。如果Recv-Q长期不为零甚至很大，说明应用程序读取太慢。如果Send-Q长期不为零，说明对端接收太慢或者网络拥塞。这些都是应用程序层面或者对方服务的问题，而不是中间链路的问题。

梳理清楚原因之后，我把我常用的排查和解决流程总结一下，你可以照着这个顺序去做。

第一步，先用ping命令测试丢包率。从你的客户端连续ping云服务器的IP地址，比如ping 1000个包，看最后统计的丢包率。同时也在云服务器上ping你客户端的IP，双向测试。单边丢包可能是路由不对称导致的。

第二步，使用mtr工具追踪路由，观察丢包发生在哪一跳。如果丢包只发生在云服务商的最后一跳之前，说明问题在运营商网络。如果最后一跳也丢包，那就是云主机本身的问题。

第三步，登录云控制台，查看云主机自身的网络流量监控和丢包监控。很多云服务商现在会单独展示租户层面的丢包统计。如果看到丢包与带宽占满同时出现，就是限速问题，升级带宽或者优化流量。

第四步，在云主机内部，用ethtool -S eth0查看网卡驱动统计信息，关注rx_dropped、tx_dropped、rx_over_errors等字段。如果这些计数很高，调整环形缓冲区大小或者检查网卡驱动版本。

第五步，检查内核参数。netstat -s可以显示TCP协议的统计信息，包括重传段的数量、丢包数量、接收队列溢出次数等。如果发现有大量的“packets pruned from receive queue”或者“TCPBacklogDrop”，说明内核接收队列溢出了，需要增大net.core.rmem_max和net.ipv4.tcp_rmem等参数。

第六步，用netstat -an查看端口的Recv-Q和Send-Q。如果某个端口的Recv-Q长期很大，说明应用程序处理不过来，需要优化代码或者增加处理进程数量。如果是Send-Q很大，说明网络发送慢或者对方接收慢，结合重传率一起看。

第七步，抓包分析。使用tcpdump在服务器上抓取几分钟的数据包，然后用Wireshark打开，使用“Statistics”菜单下的“Summary”和“Conversations”功能，可以统计出重传、重复ACK、乱序等事件。这些事件的数量和比例能直接说明网络质量。如果重传率超过百分之二，就属于比较差的网络了。

第八步，根据抓包结果和前面的统计信息，确定问题归属。如果是运营商和物理链路问题，联系ISP或者云服务商协助更换路由或者提供解决方案。如果是云平台限速或者安全组配置问题，调整配额和规则。如果是内核参数问题，按推荐值调整。如果是应用程序问题，压力测试和优化代码。

最后，我来总结一下。云服务器网络丢包不是一个单一原因造成的问题，它可能是运营商骨干网抖动，可能是云平台限速，可能是你Linux内核参数没调好，也可能是你的程序处理不够快。面对丢包，不要慌张，也不要盲目升级带宽。按照从外到内、从大到小的思路，用工具逐个验证。ping看到的是表象，mtr能看到路径，ethtool看驱动，netstat看协议栈，tcpdump看细节。丢包率在千分之一以内，对于大多数应用来说是可以接受的。但一旦超过百分之二，就会明显影响体验。你的目标不一定是把丢包消灭到零，而是要把丢包控制在一个你的应用协议能够容忍的范围内，并且知道丢包的原因是什么，而不是糊里糊涂地忍受“时断时续”。