前言
我们做独立站的，几乎是经常被客户吐槽页面加载慢，但这个"慢"又是一个很笼统的锅——可能有服务器的原因，也可能有线路的原因。本文就来分享一套排查顺序，先分清慢在哪一段，再决定我们钱往哪花。
访问慢，慢在哪一段
一次页面访问的链路其实很短：用户发起请求，穿过公网线路到达你的服务器，服务器处理后把数据原路送回去。那么慢，无非出在三处——服务器本身扛不住、线路半路堵车、或者前端资源太重。
前端资源（图片压缩、脚本合并）比较复杂，本文暂时按下不表。专聊前两者，为什么要先分清这两者？因为两者的治法完全不同，甚至互相冲突：给一台本来健康的机器升配，治不了线路丢包；反过来，换再好的线路，也救不活一台被并发打满的服务器。
先查服务器：三个信号
登录服务器，几分钟就能把"服务器的嫌疑"过一遍：
uptime
free -h
df -h uptime 里的负载（load average，正在排队等CPU的任务数）长期超过CPU核数，说明算力不够用了；free -h 看内存是不是被吃满；df -h 看磁盘——日志把磁盘写满是独立站服务器的常见病，盘一满，数据库写入卡住，整个站就会跟着慢。
如果三项都健康、并发也没到瓶颈，服务器的嫌疑基本可以排除，转入线路排查。
再查线路：丢包和绕路
线路问题有两个典型症状：丢包和绕路。用路由追踪工具就能看出轮廓：
mtr 你的服务器IP --report mtr（把ping和路由追踪合成一个报告的工具）会告诉你丢包出现在哪一跳——如果是靠近机房的几跳丢包，那就是机房侧的问题，要找商家；如果是公网中段丢包，那就是线路拥堵，高峰期尤其明显。
建议再这样检查一下：一是晚高峰再跑一遍，因为上午十点干干净净的路由，晚上九点可能是另一幅面孔；二是从目标市场的位置测一下——独立站的客户如果在欧美，就从欧美节点测，从自己电脑上测出的延迟意义有限。各条线路的门道，可以参考本站文章《各种VPS常见的网络线路科普》。
最容易误判的两种情况
第一种：升配无效。客户抱怨慢，商家建议升级CPU，升完还是慢——那就是因为病因在线路丢包，CPU再强也轮不到它发力。这也提醒我们，排查一定要先于花钱。
第二种：把"带宽打满"当成服务器慢。带宽占满是少数能靠升级直接解决的问题，但升之前先算账，别凭感觉买，带宽需求可以参考本站文章《独立站服务器带宽应该怎么算？》。
另外提一句CDN：它适合救"线路慢"问题里的静态资源分发，把图片、脚本挪到离客户更近的节点，欧美客户访问独立站的提速效果一般都不错。但CDN救不了服务器本身有病，一定要先治好源站再上CDN。具体可以参考等点博客的文章《VMRack免费CDN分享》。
找到病因后，怎么治
服务器慢——升配置、加缓存、清日志、优化数据库，按体检结果对症下药；
线路慢——换线路类型、上CDN分发静态资源，或者换一个地理位置离客户群更近的服务器。
选服务器的时候，一定要把"线路信息透明"当一条硬标准。举个例子：我现在用的就是知名云厂商VMRack洛杉矶Equinix LA4数据中心自建机房里的机器，机房位置、线路类型、带宽规格全都是明标的。排查线路问题时，敢标细节的商家能让你少排除一层疑点。
总结
访问慢是结果，不是病因。先把链路拆成服务器和线路两段，用我说的三个信号来查服务器，用mtr查丢包和绕路，在高峰期从客户的位置复测——定位准了，升配、换线路、上CDN才不会白花钱。黑五流量洪峰就在眼前，趁现在把这套排查跑一遍，比洪峰来了再手忙脚乱有用得多。
评论区