边缘节点服务器——卡顿的根源不在带宽

页面卡，很多人的第一反应是带宽不够，加钱、升套餐、换更大的管子。可真正把响应时间拖长的，经常是那台离用户最近的边缘节点服务器。它替源站接住了大部分请求，一旦它那儿出了岔子，源站带宽再宽也白搭。

带宽这东西，只有在传大文件的时候才是明显的瓶颈。一个 HTML 页面才几十 KB，一张压过的图一两百 KB，这点数据在现在的线路上跑，差个几十毫秒根本轮不到带宽背锅。真让你觉得“点一下要等半天”的，是首字节迟迟不回来，或者某个关键请求卡在了半路。

边缘节点服务器到底在替你干什么

简单讲，CDN 网络里每个机房摆着的那台机器，就是一台边缘节点服务器。用户请求先落到它这儿，静态的图片、CSS、JS 直接从它本地吐出去，动态的、要查库的，它再回源站取。距离近、链路短、握手少，速度自然上来。所以它既是加速器，也是你网站的第一道前台。

麻烦也就出在这个前台上。它不是你自己的机器，配置、调度、缓存策略都隔着一层，出了毛病你只能看响应头猜。多数人卡在这儿，最后一句“CDN 不行”就撤了，换一家也未必好，同样的坑还在原地等你。

卡顿的几个真凶，带宽排不上号

头一个是回源慢。边缘节点没缓存到，或者缓存刚好过期，它得回源站拿。源站那边一个慢查询、一次锁表，用户在几百公里外就多等好几秒。

第二个是缓存没命中。看着开了 CDN，实际命中率低得可怜，请求几乎全穿透到源站。原因五花八门：URL 上挂了随机参数、Cookie 里塞了用户标识、Cache-Control 写成了 no-cache，或者干脆忘了给静态目录配规则。

第三个是握手和解析。首屏要新建连接，TLS 来回几趟，跨境或者跨运营商的时候尤其明显。DNS 调度还可能把你解析到一个物理上并不近的节点，看着是就近接入，实际绕了一大圈。

再往后才是节点本身的负载。热门资源集中打到同一个节点、同一时刻大量回源，机器出口和磁盘都顶不住，这时候你源站闲得发慌也没用。

先量 TTFB，别急着掏钱加带宽

判断顺序很重要。拿 curl 打一下，盯 time_starttransfer，那个数字就是首字节时间。TTFB 高、下载速度正常，说明问题在计算或回源，不在带宽；TTFB 正常、下载慢，才轮到带宽和链路。

再看响应头。x-cache、via、age、cf-cache-status 这些字段各家写法不太一样，具体含义以服务商官方文档说明为准，但 HIT 和 MISS 的区别是通用的。连着刷几次都是 MISS，命中率这事就得查了。

还得换地区测。本机测出来快不代表全国快，找几个不同省份、不同运营商的线路试一下，差得离谱的地方，多半是调度或者节点覆盖的问题。

命中率上不去，多半是自己的规则在捣乱

缓存这块，规则写错比不写还麻烦。带 query 的 URL 默认不少家是不缓存的，活动页后面加个 ?from=xxx 就直接全穿透了。Cookie 也一样，请求头里带了 Cookie，部分配置下直接绕过缓存。

还有 Vary 头。写了 Vary: User-Agent，等于按 UA 分版本缓存，命中率立刻掉一大截，移动端适配用这个得留神。

静态目录该给长缓存就给长的，文件名带 hash 的资源，Cache-Control 写一年都没问题。HTML 反过来，短缓存或者协商缓存。规则理清楚，命中率能上一大截。

新上的资源还可以预热。不预热的话第一批用户全是 MISS，赶上开抢那种场面，回源瞬间打满，源站先趴下。

节点调度把你分到远处，这事得自己验

就近接入靠的是 DNS 解析和调度系统，但“就近”是按网络拓扑算的，不一定按地理距离。有些地方运营商出口绕，解析出来的节点看着同城，链路却要跨省绕回来。

更麻烦的是多家混用。CNAME 一层套一层，最后落到哪家、哪个节点，自己都说不清。出问题两边互相说是对方的事，排查周期拉得老长。

边缘节点服务器回源那一段，最容易被忽略

这一跳常常没人管。节点到源站之间的链路质量、回源带宽、并发连接数，全是隐形的。源站只开了一个小出口，几十个节点同时回源，连接排着队等，用户那头就是干等。

能做的有几件：回源走长连接、源站前面再垫一层自己的缓存、把动态接口里耗时长的查询优化掉。慢查询这种事，加多少带宽都救不回来。

什么情况下才真的是带宽不够

视频、大文件下载、没压过的图片、没开 gzip 或者 brotli 的接口响应，这些场景带宽确实是硬瓶颈，加钱有用。还有一种是源站出口太小，回源时就堵在那儿，这时候升源站的带宽比升套餐更对症。

顺带提一句，图片不压直接上传，是很多人带宽账单变贵的直接原因。同一张图压一压，体积能差好几倍。

所以排查顺序可以这么定：先量 TTFB，再看缓存命中，接着查回源链路，最后才谈带宽。顺序走反了，钱花出去，卡顿还在，人还容易上头。