先说结论：同一家机房、同一台机器、同一个配置，白天 ping 过去 120ms，晚上能飙到 330ms差了 200 多毫秒。这不是服务器被打了，也不是带宽被占满，而是「回程」和「去程」走了完全不同的两条路。所谓 BGP 多线机房卖的就是这个卖点，但很多人在实际用的时候根本没搞清楚去程和回程的区别，出了问题只会觉得「这家机房线烂，换一家」。
我是做运维的，去年下半年遇到一个挺典型的单子。客户买的是一台香港 BGP 多线的机器，配置给得也不低，8 核 16G，跑一个普通的 PHP 站点。白天一切正常，浏览器打开首页 1 秒内加载完，监控面板上的响应时间稳定在 200ms 上下。结果一到晚上八点到十点，客户就开始抱怨「网站卡得像PPT」，自己 ping 服务器也发现延迟肉眼可见地往上跳。客户第一反应是让我们升配，我让他先别急，先把链路搞明白。
我拉了三网分别做路由追踪，发现三网去程都干净地走进了这家机房的自有骨干网，回程却各自散开：电信走的是骨干直连，联通绕到某个中转节点，移动更离谱，绕了一圈走了一条看起来很不合理的路径，还中途丢了包。最后一次回程多出来的那 200 多毫秒，就是这么来的。这台机器硬件一点问题没有，是「回程路径」被运营商的调度策略坑了。
那台可以先看看，如果你手上有海外服务器、经常要排查线路问题，这工具能直接省事：
需要先看清一条链路到底走了哪几跳、每一跳延迟多少，先拿工具测一遍：深蓝群Ping（多服务器断线与网络质量检测）（站长工具，V3.5.2绿色最新版）支持多服务器同时拨测、断线检测和链路质量统计，比你一台台机器上手敲 ping 直观得多，也能把「白天好、晚上卡」这种时段性问题拉成一张曲线看。下面这套排查流程我是配合它做的。
下面我把整个过程按顺序写下来，包括怎么判断问题在回程、怎么读懂路由追踪的输出、怎么用三网对比定位，以及最后有哪些能落地的解决办法。算是给同样踩过这个坑的人留一份记录。
一、先把「去程」和「回程」这两个词搞明白
这是整件事的地基。任何一个网络请求其实都是两段拼起来的：去程是你本地（或者用户）发出去，到达服务器这一段；回程是服务器把响应数据送回你本地这一段。
这里有个反直觉的地方：去程和回程走的是完全独立的路由决策。去程是你本地运营商根据它的路由表选路，回程是服务器所在网络根据它自己的路由表选路。两条路可能一个在内网骨干上飞，一个绕到海外中转点再回来。更麻烦的是，这两条路是动态的，运营商的调度策略随时可能调整，白天给你一条好路，晚上给你换一条烂路而且你完全感知不到它什么时候换的。
回到我那个客户。网站慢的表现是「页面加载慢」，但服务器侧的资源监控完全正常：CPU 不到 10%，内存用了 40% 出头，网卡流量只有带宽上限的两三成。这基本可以排除服务器本身的问题。真正能解释「资源正常但体感很慢」的，就只剩网络路径了。
这里有个更省事的经验判断：如果慢的只是你一个人，而同一台机器上别人访问很快，那是本地网络的问题；如果所有人都慢，那才轮到怀疑服务器或者机房出口。
二、路由追踪输出怎么看：盯住三个位置
路由追踪（traceroute / tracepath）会给出从起点到终点每一跳的路由节点和往返延迟。输出可能有一百多行，但真正需要盯的只有三处。
第一处是前几跳。前几跳是你本地接入网和运营商骨干的固定部分，平时没什么好看的，出问题多半不在这。
第二处是延迟突然跳上去的那一跳。比如前面七八跳都是 8ms、9ms，到第 9 跳突然变成 180ms，那这一跳就是「墙」的位置，往往对应一次国际出口或者某个中转节点。这一跳的归属比延迟数字更有价值它告诉你坏点大概在谁的网络里。
第三处是星号和丢包。中间某一跳显示 * 不一定是真丢包，因为那一跳常常只是不回应探测包（ICMP 限速很常见），但如果星号连续出现在好几跳且延迟同时劣化，那这段链路的状态就真的要打问号了。判断丢包要看终点，终点稳定、只有中间星号，通常可以忽略。
还有个实操细节：一定要分时段跑。上午跑一次、晚上八点跑一次，两份结果摆在一起对比，才能看出「路径被换过」。只看一次的结果，你很可能把「晚上才坏的线路」误判成「一直就这水平」，然后在选机房的时候做出错误判断。
三、三网对比怎么定位：看回程，不看去程
这一步是整个排查里最容易被做错的地方。很多人拿到路由追踪结果，第一反应是「去程绕了」其实对服务器托管来说，去程是你（用户）那一侧的事，服务器商家管不了也改不了；你真正能抱怨、能要求换的，是回程。
所以正确的做法是：让电信、联通、移动三条线分别 ping 你服务器，然后分别做路由追踪，把最后几跳（靠近服务器那一段）单独拎出来看。回程这段如果走了中转、走了绕路、走了拥塞的骨干，那就是机房的锅，供应商应该给解释甚至给补偿；反过来，如果回程干干净净，但延迟本身就是从某个国际出口开始高的，那就是国际段公共链路的问题，换机房未必能解决，得看具体落点。
我那台机器的结论就是这么来的：电信回程干净，延迟稳定在 130ms 左右；联通回程多绕一跳，180ms；移动回程绕得最狠，330ms 且有丢包。跟客户一确认，他主要用户确实集中在移动侧这就把「站点整体慢」和「移动用户特别慢」完全对上了。
四、能落地的几个办法，从省事到折腾排序
第一，换一台 IP 或者换一台机器。BGP 多线机房里，不同 IP 段可能挂在不同的接入路由器上，回程路径不一样。这是最省事的操作重装系统前先把 ping 三网走一遍，挑一个回程干净的 IP。你也可以同时开两三台，用同一套脚本连续拨测一周，看哪台最稳再切流量过去。
第二，换机房。如果整个机房的回程都绕，那就没什么可优化的了，走之前先拿到三网回程的实测数据，别只听销售说「CN2 直连」。
第三，把静态资源拆到 CDN 或对象存储上。这条不是修线路，是绕开线路。图片、JS、CSS 走 CDN，用户就近拉取，只有动态请求回源到服务器，体感会好很多。静态资源占比高的站点，效果尤其明显。
第四，给特定用户做分流。如果你的用户本来就集中在某一家运营商（比如移动），那可以考虑用 DNS 解析把不同地区的用户指向不同的接入点，甚至针对移动做一条专门的回源链路。成本上去了，但对付大流量业务是值得的。
第五，长连接优化。如果你的业务是 API 为主，把短连接改成 keep-alive 长连接，能显著减少握手和中间路由跳数带来的额外延迟。这一条和线路无关，但对跨境链路的效果出奇地好。
五、把这些做进日常监控里
排查完只是一次性的，真正的价值在于让问题在影响用户之前就被发现。我现在的做法是：拿三网拨测节点对服务器做持续监控，采样间隔 1 分钟，同时保留去程、回程的路由追踪快照，每小时存一次；一旦某个运营商的延迟超过基线（比如超过 50ms）或者丢包率超过 1%，就自动告警。
监控的时候有两个细节容易踩坑。一是基线要按时段分开算，晚高峰本来就比白天慢，用一个统一的阈值会在晚上疯狂误报，最后大家就把告警静音了。二是要同时看丢包和延迟，有时候延迟涨 20ms 但 0 丢包，用户其实感知不大；而延迟看着正常但持续丢包 3%，体感反而更糟那种情况下应用的请求重试会让实际耗时翻倍。
把这套东西跑起来之后，我那个客户的站点在半年里再没因为线路问题被投诉。中间有一次移动侧回程被调整，延迟从 150ms 跳到 280ms，告警提前 20 分钟发出来，我们在他投诉之前就换了 IP。
写在最后
「BGP 多线」这四个字，说白了就是机房自己有骨干网或者同时接了三家的线路，让你去程尽量不绕。但回程这一半，取决于运营商当时的调度策略，商家能优化的空间比大多数人想象的要小。所以买这类机器的时候，别只问「是不是 BGP 多线」，要问得更细：回程走的是什么、去程和回程是不是同一套、能不能先试用几小时自己测三网、以及出问题换 IP 快不快。
真遇到「白天快晚上卡」这种问题，也别急着换机器。先把三网分开测、把去程回程分开看、把终端设备和服务器分开看，十次里有八次能定位到具体是哪一段路的问题。剩下的两次，是真的该换供应商了。
喜欢 
顶
难过
囧
围观
无聊
