IDC站点最怕的不是带宽｜是出口绕路

带宽买得再大，出口绕路一样白搭。这话我在不同场合说过好几遍，但每次都还是有人上来就问「100M够不够」。够不够得看数据怎么走，光看那个数字意义有限。idc站点有个特点，访问的人散在好几个运营商，用户点开一个页面，请求要穿过好几张网才落到你机器上，中间哪一段绕了远路，握手就多几个来回，首屏自然就慢。你盯监控看带宽跑满没跑满，永远看不出这个毛病。

idc站点被出口绕路拖住时的几个典型症状

不是所有慢都叫绕路，但绕路的表现确实有点特征。一个是 ping 值不算高，打开网页却一顿一顿，尤其是首次访问和后台登录这种要来回握手的动作。另一个是投诉集中在某几个省份或者某个运营商，别的地方用户说挺好。还有一个是下载速度忽高忽低，白天还凑合，晚上高峰期直接掉地上——这往往是出口的互联带宽被挤了，不是你自己那根线不够粗。这些症状叠在一起，基本可以怀疑路由的问题了。

去程和回程压根不是一条路

很多人测速只测「我能不能连上」，但网络的去程和回程是两套路由，各走各的。你的请求发出去可能很顺，服务器返回的数据包却绕了一大圈才回来，用户体感差在回程上。这种不对称在跨网访问里特别常见，尤其是从机房到某些运营商的方向。所以测试不能只在自己电脑上敲一下完事,得从多个地方、两个方向分别看。有条件的话让外地朋友帮忙跑一下，或者用第三方的多点探测，比自己一个人瞎猜强。

查绕路其实就那几个命令

Linux 上 traceroute 和 mtr 够用了，mtr -r -c 100 目标IP 能出一份带丢包率的报告，比单次 traceroute 靠谱得多，因为路由会抖，一次的结果不能当结论。Windows 用 tracert，也能看个大概。重点看三样东西：跳数有没有明显变多、某一跳之后延迟是不是突然抬起来、以及每一跳对应的 AS 号是不是换得很乱。如果数据从你的机房出去，先在国内绕了两三个省再出海，那基本就是绕了。不会看 AS 号也没事，把结果贴出来问服务商，让他们解释每一段是怎么回事，这招比什么都直接。

单线、双线、BGP 多线，差就差在出口

单线的机器便宜，接一家运营商，同网用户飞快，跨网就惨了，这是物理现实，不是配置能救的。双线是接两家，各自有路由，通常靠智能 DNS 按访问者来源分 IP，用户解析到哪个就访问哪个，本质上还是两张网。BGP 多线是把同一段 IP 宣告到多个上游，让对方的网络自己选路进来，这个体验通常最稳，成本也最高。要留个心眼：市面上有些写着 BGP 的方案，实际是双线加调度，宣传口径和实现方式不一定对得上。具体怎么接的、上游是哪几家，以服务商或官方页面说明为准，别只看销售页上那几个大词。

国际方向的绕路更隐蔽

做外贸或者面向海外用户的站，绕路问题会更明显。国内到海外，数据可能先绕到香港、日本、新加坡再落地，跳数看着不多，实际单程延迟就不低了。有的线路标称直连，实际高峰期会切到别的地方走，这种事只能靠长期监测发现，测一次说明不了什么。选这类线路的时候，问清楚回程怎么走比问带宽重要得多，最好要到测试 IP，自己连续跑几天 mtr 看看稳不稳。

问服务商哪几句不容易被糊弄

几个实用的问题：你们出口走哪几家上游，有没有自己的 AS 号；回程路由能不能给一份看看；有没有测试 IP 可以让我自己跑 mtr；超量之后是限速还是另算钱，限到多少。这几句问下来，靠谱的服务商会直接给资料，含糊其辞的基本就有数了。另外最好把沟通记录留个截图，后面真出问题扯皮的时候用得上。

先加 CDN 还是先换线路

这得看你的站是什么类型。图片、CSS、JS 这些静态资源占大头的，先上 CDN 性价比最高，用户就近取，绕路那一段直接被跳过去。但如果你的站主要是动态接口、登录、查询这类必须回源的请求，CDN 帮不上太多忙，该绕还是绕，这时候就得从线路下手。还有个折中办法：按访客来源分线路，多台机器分别接不同的网，用调度把人分到最近的那台。麻烦是麻烦，成本比整体升 BGP 低一些。

最后给个能直接照着做的顺序：先拿测试 IP 跑三天 mtr，记录不同时段的丢包和跳数；再让外地或者异网的朋友帮忙从反方向测一遍；把结果整理成一张表，拿去问服务商每一段是怎么走的；确认是线路问题而不是自己机器或者程序的问题之后，再谈换不换。别一上来就升级带宽，钱花了问题还在，那种憋屈感我见得太多了。