换了服务器出口带宽，网站还是慢半拍

带宽从 10M 升到 100M，页面打开照样转半圈才出来——这种事儿碰得多了，多数人第一反应是钱白花了，其实更常见的情况是：那条服务器出口带宽本来就不是瓶颈，或者瓶颈在出口之外的另一段路上。先别急着退单，按下面这个顺序自己捋一遍，比跟客服扯半天有用得多。

服务器出口带宽够不够，先问清是独享还是峰值

标称 100M 和 100M 峰值完全不是一回事。峰值型的机器在晚高峰会被同机房其他用户一起挤，你在后台看到的带宽曲线很漂亮，实际业务跑起来断断续续。买之前最好问清楚三件事：这条线路是独享还是共享、有没有月流量上限、超了是限速还是另外计费。销售口头说的不算，以服务商页面或工单里的说明为准，截图存一下，后面扯皮有据。

上行和下行的账，一开始就容易记反

服务器出口带宽说的是从机房往外发的方向。用户打开你的页面、下载你的图片，走的是服务器的上行。可很多人拿本地测速软件跑出来的数字去对比，那是你家的下行，跟服务器没半点关系。云主机一般下行给得大方，上行反而紧，尤其是便宜套餐。所以你上传视频、给人下大文件、做接口回传，先看上行那栏，别被总带宽那个大数字骗了。

一个页面到底吃多少带宽，自己粗估一下就够

算法很土：单页面所有资源加起来的总量，乘上每秒大概多少个请求，就是出口带宽的粗略需求。首屏要是图片没压、字体一堆、JS 一大坨，很容易搞到几 MB。按 2MB 一个请求、每秒 10 个请求算，就是 20MB/s，换成 Mbps 还得乘 8。这个估法不精确，但足够判断数量级对不对——如果你估出来只要几 Mbps，那你还去升带宽，问题当然没解决。

首字节时间要拆开看，别笼统说慢

一条命令能省很多口水：curl -o /dev/null -s -w “%{time_namelookup} %{time_connect} %{time_starttransfer} %{time_total}\n” https://example.com/ 。四个数字分别对应 DNS 解析、TCP 连上、首字节回来、整体结束。哪一段特别大，锅就在哪一段：解析慢多半是 DNS 的问题，连得慢是链路绕路或者跨网，首字节慢往往是后端处理，整体慢才轮到带宽和资源体积。不分段，永远只能猜。

回源那条线，最容易花钱买个寂寞

上了 CDN，用户到边缘节点是快了，可边缘回源还是要走你那服务器出口带宽。缓存命中率一低，等于每个请求都回源，带宽加了也白加。常见原因有几个：缓存规则写得太保守，动态页不敢缓存；静态资源每次带新的版本参数，URL 一变全是新对象；还有 cookie 没清干净，导致边缘节点判定不可缓存。看一眼响应头里的缓存状态，把命中率提上去，往往比加带宽省钱。

本机处理不过来，带宽再宽也堵在门口

带宽只是路宽，车都堵在收费站也没用。CPU 长期贴着高位、PHP-FPM 的进程池排满、MySQL 慢查询一堆、磁盘 IO 等半天，这些都会让首字节时间拖长。top、iostat、慢日志，这几个东西看着枯燥，但比升级套餐更能找到真凶。还有连接数上限，小配置的机器默认值不大，并发一上来新连接直接被拒，表现出来也像“网慢”。

物理层这些不显眼的坑，也真能拖慢

单线机房跨运营商访问，路由绕一大圈，握手就慢，带宽再大也救不了延迟。网卡和交换机端口没协商到千兆，实际跑在百兆上，这种事儿不是段子。MTU 不一致会让大包反复重传，小文件没事，大文件一传就卡。看着玄乎，但排查的时候顺手看一眼，花不了几分钟。

按顺序查，不要东一榔头西一棒子

顺序我一般是这么排：先从本地 ping 和路由追踪看延迟、看有没有绕路；再 curl 分段测首字节；然后把页面资源总量和并发量粗估一遍；接着看 CDN 命中率和回源比例；再看本机 CPU、内存、磁盘、连接数；最后才谈要不要升带宽。升之前务必看一眼现有带宽的峰值利用率，平时只跑到两成，那加钱也是给服务商送业绩。

慢半拍这事儿，多半不是带宽不够，是路没走对。先把测量做出来，再决定掏不掏钱。真要换，也优先换线路质量和独享程度，而不是只看那个标称数字。服务商那边连独享还是峰值、超流量怎么算都说不清的，那换一家可能比加带宽更值。