国外大带宽服务器丢包严重?5步快速排查法?

做跨境业务的朋友，最怕的不是服务器宕机，而是那种“半死不活”的状态：网站能打开，但图片加载一半卡住了;视频流播着播着就缓冲;SSH连上去敲个命令，回显要等好几秒。这种体验，比直接打不开还让人抓狂。

丢包，就是罪魁祸首。

我有个做海外直播业务的朋友阿杰，他的服务器放在美国洛杉矶，带宽不小，足足有200Mbps。但每到北京时间晚上八九点，也就是美国那边凌晨四五点的时候，他的直播间就开始卡顿，观众反馈画面模糊、频繁断流。阿杰一开始以为是服务器配置不够，又是升级CPU又是加内存，问题依然没解决。

后来我帮他做了个简单的mtr测试，结果发现从国内到他服务器的这条链路上，丢包率在某个节点突然飙到了15%。这不是服务器性能的问题，是网络传输的问题。

很多人在遇到国外服务器丢包时，第一反应就是“服务商不行，换一家”。但说实话，国际互联网传输本身就充满了不确定性，跨大洋、跨运营商、跨国家，任何一个环节出问题都可能导致丢包。与其盲目换服务器，不如先学会一套系统的排查方法，把问题到底出在哪个环节搞清楚。

今天这篇文章，我就把这套我自己用了很多年的“5步快速排查法”分享出来。希望对正在被丢包问题折磨的你，能有一些实际的帮助。

第一步：确认丢包的真实状况，别被直觉骗了

很多人一感觉“卡”，就断定是丢包。但实际上，服务器响应慢也可能是因为CPU满了、内存不够、磁盘IO太高。所以第一步，是先确认丢包到底存不存在、有多严重。

用什么工具? mtr。这个工具比单纯的ping或者traceroute都好用，它把路由追踪和实时丢包统计结合在了一起。

在你的本地电脑(或者一台国内的小鸡)上，运行：

mtr -r -c 100 你的服务器IP

这条命令会向你的国外服务器发送100个数据包，然后输出一份统计报告。报告里会列出从你本地到目标服务器经过的每一个网络节点，以及每个节点的丢包率和延迟。

怎么看结果? 你的关注点不应该只在最后一跳。如果最后一跳有5%的丢包，但中间有一个节点也有5%的丢包，而且后面的节点丢包率没有再增加，那说明丢包可能就发生在这个中间节点，而且这个节点可能只是“不响应测试包”而已，不代表真的丢包了。

真正需要警惕的情况是：丢包率随着跳数增加而累积。比如第5跳丢包1%，第6跳丢包3%，第7跳丢包5%，第8跳丢包8%。这说明确实有数据包在路上丢了。

还有一个常见的误区：不要只看平均值，要看波动。如果某几跳的延迟突然从10毫秒飙到300毫秒然后又降回来，这说明路由在震荡，也是网络不稳定的表现。

第二步：画一条时间线，找出丢包的高峰期

网络丢包，很多时候不是24小时持续的，而是在特定时间段集中爆发。找到这个规律，你就能大概判断问题的性质。

怎么找规律?你可以在不同时间段跑mtr测试。比如早上8点跑一次，中午12点跑一次，下午6点跑一次，晚上10点跑一次，凌晨2点跑一次。连续测两三天，你就能画出一条“丢包率随时间变化”的曲线。

我遇到过几种典型的规律，你可以对照一下：

第一种，丢包只出现在晚高峰(比如北京时间20点到23点)。 这种情况十有八九是国际出口带宽拥堵。这个时间段是中国网民上网的高峰期，电信、联通的国际出口带宽被大量挤占，你的数据包出去的时候堵在门口了。这种拥堵，换再贵的服务器也没用，需要考虑优化线路或者上CN2这类精品网。

第二种，丢包出现在你的目标地区的工作时间。 比如你的服务器在美国，丢包最严重的时段是美国当地的中午到下午。那可能是美国那边的本地运营商网络拥堵，或者你的服务器所在的机房本身带宽跑满了。这种情况，你可以联系服务商看看是不是机房的上级带宽不够。

第三种，丢包完全没有规律，随时都可能发生。 这种情况要警惕，可能是路由波动，也可能是你的服务器正在遭受小流量的DDoS攻击。建议检查一下服务器的流量监控图，看看有没有异常的小峰值。

阿杰当时的情况就是第一种。他连续测了三天，发现每天晚上8点到11点丢包率最高，到了凌晨12点以后就恢复正常了。这说明问题的根子在“国际出口拥堵”，而不是服务器本身。

第三步：分段测试，把问题卡在某一环

这一步是整个排查过程里最核心、也最能体现水平的一步。我们要做的是：把从你本地到国外服务器的整条路径，切成几段，分别测试，找出到底是哪一段在丢包。

怎么切段?你可以找几台中间位置的测试机，比如：

第一段：从你的本地到国内某大城市的一个节点

第二段：从国内节点到香港或者新加坡的节点

第三段：从香港节点到你最终的目标服务器

如果你手头没有那么多测试机，也可以利用一些公共的Looking Glass服务。很多大型网络服务商都提供Looking Glass页面，你可以从他们的网络节点向你服务器发起测试。

通过分段测试，你大概能判断出丢包发生在哪一段：

如果在国内段就开始丢包了，那问题出在本地运营商。可能是你家里的宽带质量问题，也可能是你所在地区到骨干网之间有拥堵。如果你是家用宽带，试试重启光猫、换DNS，或者联系运营商报修。如果你是公司网络，联系网管看看是不是公司防火墙或者流控设备的问题。

如果国内段正常，但从国内到香港或者日本这段开始丢包，那问题出在运营商的国际出口。这是最常见的情况，尤其是面向美国或者欧洲的业务。解决方案通常就是两条路：升级到CN2 GIA这样的优质线路，或者换一个离国内更近的机房，比如香港、新加坡、日本。

如果前面都正常，只在最后一跳到服务器之间丢包，那问题就在服务器本身或者机房的接入网络。这时候你需要登录服务器，看看系统负载是不是太高了。可以用top命令看CPU和内存，用iftop看实时带宽使用情况。如果带宽被跑满了，那说明你的业务量太大了需要升级带宽;如果系统负载正常但依然丢包，那可能是机房的交换机端口有问题或者上游链路有故障，这时候就该联系服务商的技术支持了。

第四步：用不同的协议和端口交叉验证

很多人忽略了一点：不同的网络协议，走的路径和优先级可能不一样。ICMP、TCP、UDP，在运营商的网络里受到的对待是有区别的。

你平时用ping或者mtr测试，默认用的是ICMP协议。但你的网站业务走的是TCP协议(HTTP/HTTPS)，你的视频流或者游戏可能走的是UDP协议。

有些运营商会针对ICMP做限速或者降级处理，导致你用ping测试发现丢包很严重，但实际上TCP业务跑得挺顺畅。反过来，也有可能是ICMP正常但TCP丢包。所以，不能只测ICMP，要用实际业务的协议去验证。

怎么测TCP丢包?可以用tcping或者psping这类工具。比如：

tcping -t 你的服务器IP 80

这个命令会持续向你的服务器80端口发起TCP连接，然后统计成功率和延迟。

如果是UDP业务，比如RTC实时音视频、DNS查询、游戏服务器，那更需要单独测UDP的丢包情况。可以用iperf3的UDP模式来测试，但需要有服务端配合。

阿杰当时就犯了这个错误。他只测了ICMP的ping，发现丢包率不高就没在意。后来我们用tcping测80端口，发现TCP连接的成功率只有85%左右。而他的直播业务是基于TCP的RTMP协议，这15%的连接失败直接导致观众频繁断流。

第五步：借助第三方工具，验证是不是本地网络的问题

有时候，你测来测去发现丢包率很高，但你的服务商告诉你“其他客户都正常”。这时候你需要跳出自己的网络环境，从第三方视角来看看你的服务器到底有没有问题。

推荐两个好用的工具：

第一个是站长之家的Ping检测或者类似的海外监测服务。 你可以从全球多个节点，比如美国、欧洲、东南亚、澳洲，同时向你的服务器发起测试。如果全球节点都正常，只有中国节点丢包严重，那问题就锁定在国际出口这一段。如果全球节点都丢包，那问题就在你的服务器或者机房的网络上。

第二个是使用Cloudflare或者其它CDN服务商提供的诊断工具。 把域名套上CDN之后，你可以利用CDN的监控面板查看回源链路的健康状况。这些面板通常能看到从CDN边缘节点到你源站服务器的丢包率和延迟，数据比你自己测的更全面。

阿杰后来就是用全球Ping工具做了验证。他发现从美国本土的节点测试他的洛杉矶服务器，丢包率几乎为零，延迟也就几毫秒。但从中国电信的节点测试，丢包率高达10%到15%。结论很明确：问题不在服务器，在中国电信的国际出口。

一个完整的案例复盘

把上面这五个步骤串起来，我给你复现一下阿杰那个案例的完整排查过程：

第一步，他用mtr从本地到洛杉矶服务器测了100个包，发现第8跳到第12跳之间丢包率从0%逐步上升到12%，最后一跳丢包率12%。

第二步，他连续测了三天，发现丢包只出现在北京时间晚上8点到11点，白天和深夜都正常。初步判断与国际出口拥堵有关。

第三步，他找了一台香港的VPS做中转测试。从国内到香港这一段丢包只有1%，但从香港到洛杉矶这一段丢包有10%。说明问题不在国内最后一公里，而在跨太平洋这一段。

第四步，他用tcping测了服务器的80端口，发现丢包情况与ICMP测试基本一致，排除协议差异。

第五步，他用全球Ping工具从多个海外节点测试，全部正常，只有中国节点丢包。最终确认问题出在中国电信到美国西海岸的国际链路拥堵。

找到根因之后，解决方案反而简单了：他把服务器从普通BGP线路换成了CN2 GIA线路。换完之后，同样在晚高峰测试，丢包率从12%降到了1%以内。直播再也不卡了。

总结

国外大带宽服务器丢包严重，这几乎是每个做跨境业务的人都会遇到的问题。但很多人处理这个问题的方式很原始，要么不停地换服务商，要么不停地升级配置，花了很多冤枉钱却找不到病根。

其实，丢包排查这件事，是有方法论的。我总结的这五个步骤，你可以记一下：

第一步，用mtr确认丢包的真实状况，别凭感觉，要拿数据说话。

第二步，画出丢包的时间线，找出高峰期和规律，判断是拥堵还是故障。

第三步，分段测试，把问题卡在国内段、国际出口段还是服务器本地段。

第四步，交叉验证不同的协议，ICMP、TCP、UDP分开测，别让协议差异误导你。

第五步，借助第三方工具，从全球视角验证，排除本地网络的影响。

这套方法用熟了之后，你面对丢包问题就不会再慌了。你会很清楚：是线路问题就换线路，是本地网络问题就找运营商，是服务器问题就联系服务商。

当然，也有些丢包是你无能为力的，比如海底光缆断了、国际政治因素导致的网络波动。但绝大多数情况，按照这五个步骤走一遍，你都能找到根因，并且给出一个有效的解决方案。