VPS丢包这件事，最让人头疼的地方在于：它同时可以是线路问题，也可以是超售问题，而且两者的表象高度重叠。你看到的是ping丢包率百分之几，但背后可能是国际出口在晚高峰被挤爆，也可能是同一台宿主机上的邻居把你的带宽配额吃光了。更麻烦的是，这两种原因经常同时存在、互相放大。一个线路本身一般的机器，如果超售严重，丢包会比正常超售的机器更早出现;一个线路优质的机器，如果宿主机塞了太多用户，晚高峰照样丢包。所以判断的关键不是二选一，而是用数据把两条线索分开：先看丢包发生在链路的哪一段，再看同一时段机器本身的资源状态。

　　先确认丢包是真的，还是ICMP被限了

　　动手分析之前，得先排除一个常见的假阳性。有些路由节点会对ICMP包做限速或降优先级，导致mtr中间某一跳显示丢包，但后续节点和最终目标完全正常。这种情况不代表你的VPS有问题，只是那个节点不欢迎探测包。

　　判断方法很简单：看mtr的最后一跳。如果最终到达VPS的丢包率很低(比如0%到1%)，而中间某跳丢包很高，基本可以忽略那个中间节点。只有最后一跳或者接近最后一跳的位置持续丢包，才值得往下深究。

　　另一个基础确认是丢包率量级。晚高峰低于1%的丢包，对于跨境线路来说属于可接受范围，用户几乎无感知。持续在1%到3%之间，属于需要关注但不算异常的波动。如果稳定超过5%，网页加载会明显卡顿，SSH输入出现可感知的延迟。超过10%基本可以判定链路存在实质问题。

　　用mtr把“线路问题”从链路里剥出来

　　线路问题的核心特征是：丢包出现在你控制范围之外的网络节点上，而且和你自己的流量大小没有直接关系。

　　用mtr做双向追踪。从本地机器向VPS跑一次，再从VPS向你的本地IP跑一次。重点是看丢包从哪一跳开始。

# 在本地机器上执行（假设VPS IP为 203.0.113.10）
mtr -rwc 100 203.0.113.10

　　-r输出报告模式，-w宽屏显示避免截断，-c 100发100个包足够覆盖一分钟左右的采样。跑完之后看Loss%列。如果从某一跳开始，后续所有跳的丢包率都维持在一个相近的水平，而且这个节点位于国际出口或者境外机房的入口位置，那这就是线路侧的丢包。典型的场景是：国内段正常，到了某个国际骨干节点(比如电信的出口路由器、或者某个Transit运营商)丢包突然跳起来，之后一直丢到VPS。

　　线路问题的另一个标志是时段规律性。如果丢包只在晚八点到十一点出现，白天完全正常，且mtr显示拥堵点在国际出口或跨境段，那基本可以归因于骨干网拥塞。普通163线路在晚高峰的丢包率可以到5%到15%，而真正的CN2 GIA在同条件下通常能压在1%以下。如果你的线路宣称是优化线路，但晚高峰的mtr显示跨境段丢包和普通线路无异，那线路的“优化”大概率打了折扣。

　　如果追踪结果显示丢包集中在最后一跳(也就是VPS本身)，而中间所有节点都干净，那嫌疑就从线路转移到了VPS这一侧。这时候需要看第二个维度。

　　从VPS内部看：超售的丢包长什么样

　　超售导致的丢包，根源在宿主机层面。你的VPS被分配到的网络带宽、CPU时间片、甚至网卡的中断处理能力，都被同一台物理机上的其他实例分摊了。当邻居在跑备份、做下载、或者跑高并发服务时，你的数据包在宿主机内部就开始排队，表现出来就是丢包和延迟抖动。

　　超售丢包的典型特征和线路问题有几个区别。

　　第一，它通常伴随资源指标的异常。在丢包发生的同一时段，登录VPS跑top，看%st(steal time)这一列。如果%st持续高于5%甚至10%，说明CPU时间被宿主机收走了。再看vmstat 1的r列(运行队列)，如果长期大于CPU核心数，说明你的进程在排队等CPU，这种情况下网络处理也会被拖慢。

　　第二，超售丢包往往表现为间歇性、突发性，而不是像线路拥塞那样持续整个晚高峰。邻居的一次大流量传输可能在几分钟内把你的可用带宽挤到零，然后恢复，再过一阵又来一次。mtr的结果里，丢包率可能看起来不算太高，但StDev(延迟标准差)会很大，因为延迟在剧烈波动。

　　第三，检查带宽是否被吃满。在VPS上装iftop或nload，观察丢包发生时你的实际出站和入站流量。如果你自己的流量远低于标称带宽，但丢包在发生，说明带宽被邻居占了。反过来，如果你自己的流量已经跑到套餐上限，那丢包是正常的限速行为，不怪超售。

　　还有一个辅助指标：netstat -s | grep -i retrans看TCP重传率。超售导致的丢包会引发大量重传，如果重传率在丢包时段明显升高，且你的应用没有在跑异常的大流量，那指向宿主机网络资源争抢。

　　交叉验证：同时段、双向、多晚重复测试

　　单一时间点的一次测试，无论mtr结果多漂亮或多难看，都不足以定性。线路拥塞和超售丢包都需要时段对比才能锁定。

　　做法是：选一个工作日的晚八点到十一点，每半小时跑一次mtr和vmstat，持续记录。同时，在同一个VPS上，从你的本地网络跑一次mtr到VPS(测去程)，再从VPS跑一次mtr到你的本地IP(测回程)。如果去程在境外段丢包而回程正常，问题偏向线路的单向质量;如果两个方向都在接近VPS的位置丢包，且VPS内部%st偏高，超售的权重就更大。

　　连续观察三个晚上。偶尔一晚的波动可能是运营商临时调度或一次性的DDoS清洗，连续三晚在同一时段出现相似模式，才能作为判断依据。如果三个晚上的丢包都集中在跨境段且与%st无关，线路问题坐实。如果丢包的时间点和幅度都不规律，但每次出现时%st或磁盘await都在飙升，超售的嫌疑更大。

　　确定VPS丢包后要做什么？

　　如果是线路问题，你能做的有限。调内核参数、开BBR，对已经拥塞的骨干网没有实质帮助。BBR能改善高丢包链路上的TCP吞吐效率，但不会让丢掉的包重新回来。线路问题唯一的解法是换一条路：换机房、换线路类型、或者在前端加一层CDN把回源流量分散掉。

　　如果是超售问题，先看严重程度。%st偶尔到5%以下、晚高峰丢包在1%以内，对于非关键业务可以容忍。如果%st长期两位数、丢包影响到了实际使用，联系服务商要求迁移宿主机是第一步。对方如果含糊其辞或者建议“升级套餐”，那基本说明他们不打算在资源隔离上做投入。对于跑着正经业务的机器，换一家对超售有明确约束的服务商，比在上面继续折腾划算。

　　开了BBR之后丢包会减少吗？答案是不会。BBR优化的是拥塞控制算法，让TCP在已有丢包环境下更高效地利用剩余带宽，它不解决“包为什么丢”的问题。线路拥塞该丢还是丢，超售该抢还是抢。BBR能让你的下载速度在丢包时好看一点，但ping的丢包率不会因此下降。

　　华纳云在香港、美国、日本、新加坡均有云服务器节点，主打的是线路质量而非堆配置。双向CN2 GIA，电信去回程均经59.43骨干，联通AS9929、移动CMI各自优化，晚高峰跨境段延迟和丢包控制得住，千次Ping零丢包——这个数字的意义不在绝对值，而在于它说明线路没有在高峰期被挤到崩溃。美国、日本、新加坡节点覆盖不同区域的访问需求，适合外贸站、API后端、远程管理入口这类对往返时间敏感、对带宽质量要求高的业务。