做运维和前端性能优化的朋友大概都遇到过这种场景源站明明跑得好好的本地测速一二百毫秒结果一到异地用户那边首屏时间直接飙到三四秒图片一张张往下掉。我第一次被这个问题按在地上摩擦是给一个内容型站点做异地访问优化当时天真地以为加个 CDN 域名解析过去就完事了结果上线第三天发现缓存命中率只有六成出头回源带宽不降反升源站 CPU 被打到告警。后来花了两周时间把边缘缓存规则、缓存键、回源配置、预热刷新这一整套东西重新捋了一遍才算把跨地域访问慢这个毛病按下去。这篇就把我踩过的坑和最后落地的配置方案完整写出来从边缘缓存怎么设计到回源怎么配、怎么压回源率、怎么验证效果适合正在做站点加速的初中级同学照着抄也适合已经上了 CDN 但效果不理想的同学对照排查。1. 先搞清楚跨地域访问慢到底慢在哪1.1 物理距离带来的延迟是绕不开的硬成本很多人一上来就怀疑服务器性能不行其实跨地域访问慢第一位的锅是物理距离。光在光纤里的传播速度大约是每毫秒两百公里一个来回下来跨越上千公里的链路单纯 RTT 就要几十毫秒。而一个网页加载往往不是一次请求HTML 拉下来之后还要拉 CSS、JS、字体、图片每一类资源都要重新握手。TCP 三次握手、TLS 握手在长链路加弱网环境下握手阶段就能吃掉两三个 RTT运气不好碰上丢包重传时间还要翻倍。这就是为什么同一份代码本地访问两百毫秒异地用户却要三四秒——不是源站算得慢而是数据在链路上跑得久。再往下拆还有几个容易被忽略的因素。其一是运营商互联质量跨网访问时中间要经过多次跳转和交换链路质量参差不齐高峰期丢包率上升TCP 拥塞控制一触发传输速率直接腰斩。其二是 MTU 和分片问题某些链路上大包会被丢弃导致大量重传。其三是源站出口带宽本身有限几十个并发大文件下载就能把出口打满后面的用户只能排队。所以做加速之前先明确一件事你要解决的是延迟问题、带宽问题还是两者都有。延迟问题靠就近接入和协议优化带宽问题靠边缘缓存分流两者的手段不一样混在一起谈就会像没头苍蝇一样乱改配置。1.2 边缘缓存加回源是这个体系里最基本的两条腿CDN 这套东西说白了就干两件事把内容提前放到离用户近的地方以及在没有缓存的时候替用户去源站取一趟。前者叫边缘缓存后者叫回源。理想状态下热点内容都在边缘用户请求在边缘节点直接返回RTT 从几十上百毫秒降到个位数到十几毫秒只有冷内容、动态内容、首次访问才会触发回源。所以衡量一个加速方案好不好核心就看两个数边缘缓存命中率高不高回源质量和回源量可不可控。我习惯把整个链路画成四段来理解用户到边缘节点这一段比拼的是调度准不准、节点离得近不近边缘节点内部的缓存查找比拼的是缓存键设计合不合理、TTL 配得对不对边缘回源到中间层或源站这一段比拼的是回源链路质量、超时重试、并发合并策略源站自身处理这一段比拼的是后端能力和限流保护。跨地域访问慢通常会在这四段里的某一段或者某几段同时出问题而绝大多数人只盯着上没上 CDN不看这四段的实际数据最后自然改不到点子上。1.3 什么情况下 CDN 帮不上忙得先想清楚有一个认知必须先建立CDN 不是万能药。纯动态接口、强依赖用户会话的内容、每次请求结果都不同的页面边缘缓存基本无能为力只能走动态加速靠优化链路和协议来减少往返次数收益通常在百分之二三十不会像静态资源那样立竿见影。还有一类是内容本身更新极其频繁又要求强一致的场景比如库存、余额这类内容硬缓存只会带来数据错乱宁可让它回源。另外如果源站本身的响应时间就很差比如一个接口要查三秒数据库那 CDN 再优化也只能把这三秒原封不动地传回来。这种情况先做源站性能治理再谈加速。我见过太多案例问题根子在慢 SQL 和没加索引却一直折腾边缘配置最后当然没效果。所以在动手之前先把一个请求的耗时拆开DNS 多久、建连多久、首字节多久、内容传输多久。哪一段占比最大就先治哪一段这个顺序错了后面全是无用功。2. 边缘缓存规则怎么设计才算合理2.1 缓存键的设计直接决定命中率的天花板缓存键是这个体系里最容易被忽视、又最要命的一环。默认情况下缓存键通常由协议、域名、路径三部分组成查询参数是否参与、是否区分大小写、是否带上某些请求头各家平台的默认策略并不一致。问题就出在这里很多前端项目习惯在资源地址后面挂时间戳比如app.js?v1699999999或者营销链接带一堆utm_source、from、share_id参数这些参数一变缓存键就变边缘节点会认为是不同的资源于是同一份文件被缓存了几十份命中率被硬生生打碎。我的处理原则是静态资源要么用文件名带内容哈希的方式做版本管理比如app.3f9a2c.js要么在配置里明确忽略掉无意义的查询参数。前者是最干净的做法文件内容变了文件名就变天然不需要刷新缓存后者是补救手段把utm_*、from、timestamp这类参数加入忽略列表让它们不参与缓存键计算。这里有个坑要注意忽略参数不能一刀切。像?page2、?id100这种真正决定内容差异的参数一旦被忽略用户就会看到别人的内容这是事故级别的问题。所以忽略列表一定是白名单式的精确列举不是模糊匹配更不是全部忽略。还有一个细节是域名。如果同一个站点同时挂了主域名和备用域名或者带 www 和不带 www 都能访问缓存键里包含域名就意味着两套缓存各占一份空间。在 CDN 配置里把这两个域名收敛到同一份缓存能白捡一截命中率。这类调整看着不起眼实测下来对中小站点往往能带来五到十个百分点的命中率提升。2.2 TTL 分层不同资源用完全不同的时间尺度TTL 设置最常见的错误是全站一个值要么全设十分钟导致频繁回源要么全设一天导致发布后用户看到旧内容。合理的做法是按资源类型分层我给一个自己一直在用的参考表资源类型建议 TTL版本策略说明带哈希的 JS/CSS一年文件名哈希内容变则名变无需刷新图片、字体、图标7 到 30 天目录加版本号更新走新路径视频、大文件分片7 天以上路径版本化配合 Range 回源HTML 入口页10 秒到 5 分钟短 TTL保证发布能较快生效公共配置 JSON1 到 5 分钟接口版本号兼顾新鲜度与命中率用户相关接口不缓存无避免串号这张表背后的逻辑很简单TTL 越长命中率越高、回源越少但内容新鲜度越差。破解这个矛盾的办法不是找一个折中的中间值而是把内容变化这件事从时间维度转移到路径维度。文件名带哈希、目录带版本号内容一变更地址就变缓存自然失效此时 TTL 设多长都无所谓设一年反而最优。入口 HTML 因为地址不能变只能靠短 TTL 加主动刷新来控制。把这两类资源分开对待是整套缓存策略的核心分水岭。2.3 缓存头的优先级关系别让源站把 CDN 规则覆盖掉这一条踩坑的人极多。很多平台的缓存规则是有优先级的源站返回的响应头优先级通常高于控制台上配的默认规则而控制台上配的针对特定路径的规则又可能高于全局默认。也就是说你辛辛苦苦在控制台把某个目录设成缓存一天结果源站返回一个Cache-Control: no-cache边缘节点照样不缓存你还在纳闷为什么命中率上不去。几个关键响应头必须记牢。Cache-Control: max-age是给浏览器和共享缓存用的s-maxage专门针对共享缓存CDN 就属于这一类它的优先级高于max-age想给 CDN 单独设更长的缓存时间用这个最合适。private表示只允许浏览器缓存CDN 必须不缓存用户态接口一定要带上。no-store是完全不存连浏览器都不存no-cache容易被误解它其实允许存储只是每次使用前必须回源校验很多人把这两个搞混结果配了no-cache还奇怪为什么还有缓存。Expires是老古董优先级低于Cache-Control两都存在时以后者为准。我的经验是源站只负责声明内容的性质能不能缓存、是不是私有具体缓存多久交给 CDN 控制台的规则去配。这样发布新策略时不用改代码重新发版灵活得多。实操中我一般让后端统一输出Cache-Control: public, max-age0, s-maxagexxx把 CDN 侧的缓存时间完全掌握在运维手里。2.4 Cookie、Vary 和 Range 这三个隐形杀手Cookie 对缓存的影响非常直接绝大多数 CDN 的默认行为是请求里带 Cookie 就不缓存或者把 Cookie 纳入缓存键。前者会让所有登录用户的静态资源请求全部回源后者会让缓存被无限打碎。正确做法是让静态资源域和主站域分离静态资源请求根本不带 Cookie这是最干净的方案如果做不到分离就在 CDN 上配置忽略 Cookie 进行缓存但只对静态资源目录开这个口子接口路径千万别开。Vary 头是第二个隐形杀手。Vary: Accept-Encoding会让同一份资源按压缩与非压缩存两份这还算正常因为客户端确实需要不同格式。但Vary: User-Agent或Vary: Cookie就是灾难前者会把缓存按 UA 打碎成几十份后者直接导致缓存不可用。上线前用curl -I扫一遍响应头看到这两个基本就得让后端改掉。Range 请求影响的是大文件和视频场景。如果 CDN 不支持分片回源用户拖动进度条请求某一段时边缘节点会把整个文件从源站拉一遍源站带宽瞬间爆炸。所以视频、安装包这类大文件一定要确认边缘支持 Range 回源并且回源时按片拉取。这一条我是在一次视频站点优化中血泪学到的当时源站出口被打满查了半天才发现是拖动进度条导致的整文件回源。3. 回源配置把回源率压下去把回源质量提上来3.1 回源 Host、协议和端口这三个参数必须一次配对回源配置里最基础也最容易配错的就是回源 Host。它的作用是告诉源站我这次请求访问的是哪个站点因为一台源站上可能挂了几十个站点靠 Host 区分。常见的坑是CDN 加速域名是static.example.com源站实际站点绑定的是origin.internal.example.com如果回源 Host 没改成后者源站会返回 404 或者跳到默认站点表现就是CDN 上全是 404但源站直接访问正常。这个问题的排查成本不低因为很多人第一反应是怀疑缓存绕一大圈才想到 Host。回源协议要跟源站实际监听保持一致。源站只开了 443你配 80 回源结果就是连接超时或者 301 循环。反过来源站只开 80你配 443 回源握手直接失败。现在比较稳妥的做法是源站同时监听 80 和 443CDN 侧统一用 HTTPS 回源并在回源链路上校验证书。如果源站用的是自签证书或者内部 CA 签发的证书记得把回源校验证书的开关按实际情况处理别一边要求校验一边用自签那必然是握手失败。端口这块相对简单但要注意非标准端口在某些平台上需要在回源配置里显式声明否则默认走 80/443 会连不上。还有一个细节是回源域名解析如果回源地址写的是域名边缘节点需要做 DNS 解析解析结果的稳定性和 TTL 会影响回源成功率。生产环境我更倾向于配多个回源地址做冗余避免单个地址故障导致整体不可用。下面是一段源站侧的参考配置重点是让源站能正确识别 CDN 回源请求、正确输出缓存头、并支持 Rangeserver { listen 443 ssl; server_name origin.internal.example.com; # 回源链路开启长连接减少握手开销 keepalive_timeout 75s; keepalive_requests 1000; # 静态资源允许共享缓存CDN 侧可长缓存 location ~* \.(js|css|png|jpg|jpeg|webp|woff2)$ { add_header Cache-Control public, max-age0, s-maxage2592000; add_header Access-Control-Allow-Origin *; add_header Accept-Ranges bytes; etag on; expires off; } # 入口 HTML短缓存允许协商 location /index.html { add_header Cache-Control public, max-age0, s-maxage60; } # 用户态接口禁止 CDN 缓存 location /api/user/ { add_header Cache-Control private, no-store; } }3.2 回源超时、重试与并发回源合并回源超时的三个参数要分开设置连接超时、首字节超时等待源站开始响应的时间、读超时传输过程中的空闲时间。连接超时一般设短一些三到五秒足够因为跨地域建连如果五秒还没建立基本可以判定链路有问题首字节超时才是关键它直接决定了源站慢的时候用户等多久通常设十到三十秒读超时针对大文件传输可以设长一些六十秒以上都正常。这三个值配小了会导致源站稍微抖一下就被判超时用户看到 5xx配大了会导致源站真挂的时候用户一直转圈直到超时体验更差。我的经验是按业务类型分开配接口类首字节超时短一些八到十秒快速失败让前端走降级页面和静态资源可以放宽到二十秒以上。重试策略要特别注意重试放大问题。边缘节点回源失败后自动重试本身是好事但如果源站已经因为压力过大而变慢重试会让请求量翻倍甚至翻几倍直接把源站压死。所以我一般只对连接失败、5xx 这类明确可重试的错误开重试且重试次数限制在一到两次重试间隔做退避。4xx 一律不重试因为它重试一百次结果也一样。并发回源合并有的平台叫请求折叠是提效利器。同一个资源在同一时刻被一百个用户请求边缘节点只向源站发一次请求其余请求等这一次的结果。这个机制对热点内容首次回源特别有效能把回源峰值削掉一大截。启用它的前提是回源请求必须是幂等的 GET对 POST 一定要关掉否则会出数据错乱。3.3 分片回源与大文件场景的额外处理大文件场景跟小文件完全是两套逻辑。一个几百兆的安装包如果按整文件回源源站出口带宽会被单个请求占满其他用户只能干等。分片回源把文件切成固定大小的块常见是 1MB 或 4MB边缘节点按需拉取用户拖到哪就拉到哪带宽利用率高得多。这里有个前提源站必须支持 Range 请求返回 206 状态码和Content-Range头。如果源站是个纯静态文件服务器通常天然支持如果源站是应用服务器动态输出文件流就要自己实现 Range 逻辑否则 CDN 发来的 Range 请求会被当成普通请求返回整个文件分片就白配了。验证方法很简单用 curl 发一个带 Range 的请求看返回码# 期望返回 206 Partial Content并带 Content-Range curl -I -H Range: bytes0-1023 https://origin.internal.example.com/bigfile.zip # 检查边缘节点是否正确透传 Range curl -I -H Range: bytes0-1023 https://static.example.com/bigfile.zip另外视频场景还有个特殊点拖动进度条时会产生大量随机 Range 请求如果每个都回源源站压力很大。比较稳妥的做法是开预取让边缘在用户播放时提前拉取相邻片段同时把分片时长设短一些减少单次拉取的数据量。3.4 源站保护别让加速把源站拖垮这一条是我认为最应该强调、但讲得最少的。CDN 的一个副作用是它会把流量放大后打到源站尤其是缓存没命中的时候。如果源站没有保护一次缓存集体失效或者一次恶意刷量就能把源站打挂。基本的保护手段有几个层次。第一层是回源限速给单个边缘节点到源站的并发连接数设上限避免瞬间打满第二层是回源鉴权让源站只接受带合法签名的回源请求防止有人绕过 CDN 直接刷源站第三层是源站前面的负载均衡和限流按接口维度限制 QPS第四层是兜底降级源站超负荷时返回一个静态兜底页而不是让请求堆积。回源鉴权这块常见做法是 CDN 在回源时带上一个密钥计算的签名头源站在入口处校验。密钥要定期轮换且不能写死在前端代码里。还有一种是时间戳签名把过期时间编进签名超过时间就拒绝防止重放。这套东西配起来麻烦一点但比源站被打挂之后救火要省事得多。4. 一套完整的落地配置过程4.1 接入前的准备域名规划与源站梳理动手配之前先花半天时间把资产盘清楚能省掉后面大量返工。第一步是域名规划我推荐至少分三个主站域名承载 HTML 和接口静态资源域名专门承载 JS、CSS、图片、字体上传下载域名承载大文件。分开的好处是缓存策略可以完全独立配置静态资源域可以放心开长缓存、忽略 Cookie主站域保持短缓存并允许带 Cookie互不干扰。顺带还能突破浏览器对单域名并发连接数的限制虽然 HTTP/2 之后这个限制弱化了但域名分离在缓存管理上的价值依然很大。第二步是梳理源站。把源站的 IP、端口、监听协议、证书情况、站点绑定关系全部列出来特别是确认源站是否有多个实例、是否有负载均衡层、回源应该指向负载均衡还是直接指向实例。如果源站有 WAF 或者访问控制白名单要提前把 CDN 的回源网段加进去否则回源全部被拦截表现就是全站 403。第三步是确认业务里哪些路径是绝对不能缓存的。用户中心、订单、支付回调、后台管理这些路径要在配置里显式排除。我的做法是先在 CDN 上配一条全局不缓存的兜底规则然后逐条添加允许缓存的路径白名单这样即使漏配最坏结果是命中率低而不是数据串号。这个顺序千万别反过来。4.2 缓存规则配置实录下面这张表是我实际项目里用的规则集按优先级从高到低排列平台之间的字段名可能不同但逻辑是通用的优先级匹配路径缓存行为TTL缓存键处理1/api/user/*不缓存--2/api/order/*不缓存--3/api/public/config缓存60s忽略 utm_* 参数4/static/.js, /static/.css缓存30d忽略全部查询参数5/img/*缓存7d忽略全部查询参数6/upload/*缓存7d保留全部参数7/*.html缓存60s保留全部参数8默认不缓存--第 4 条之所以敢忽略全部查询参数是因为这些文件名本身带内容哈希查询参数纯属历史遗留忽略掉只会提升命中率不会串内容。第 6 条保留全部参数是因为上传目录的图片地址参数可能带尺寸处理指令忽略会导致返回错误尺寸。第 7 条 HTML 保留参数因为分页、筛选都靠参数区分。配套还要配几条响应头处理在边缘统一加上Access-Control-Allow-Origin省得源站每个接口都写一遍把源站返回的Set-Cookie在静态资源路径上剥掉避免污染缓存开启 Brotli 压缩文本类资源能省三到五成带宽注意开了压缩之后缓存键会自动按编码区分这是正常的。4.3 预热与刷新的正确用法预热是把内容主动推到边缘让第一批用户不用等回源。它特别适合两类场景大促或者活动上线前把确定会热的关键页面和图片提前推一遍版本发布后把新的静态资源推到主要节点。预热的坑在于它有速率限制一次推几千个 URL 会被限流而且预热是按 URL 来的如果你的资源地址带随机参数预热基本无效。所以预热清单要精确优先推首页、频道页、核心图片这些真正高热的内容。刷新是让缓存失效分 URL 刷新、目录刷新、正则刷新几种。URL 刷新的额度通常有限发布后动辄几百个文件靠 URL 刷新根本不够用。我的做法是发布流程里把静态资源文件名带上内容哈希这样根本不需要刷新新文件新地址老文件自然淘汰只有入口 HTML 需要刷新数量少用 URL 刷新完全够。目录刷新要慎用因为它会把整个目录下的缓存清空一瞬间全部回源很容易把源站打崩。如果非要清目录配合预热一起做先刷新再预热把回源压力控制在可控范围。4.4 验证怎么确认配置真的生效了配完不验证等于没配。最基础的是用 curl 看响应头重点看三个字段X-Cache类字段各家命名不同表示命中还是回源、Age表示这份缓存在边缘存了多久、Cache-Control。# 第一次请求观察是否 MISS 并触发回源 curl -sI https://static.example.com/static/app.3f9a2c.js | grep -iE x-cache|age|cache-control # 连续请求几次观察是否变成 HIT 且 Age 递增 for i in 1 2 3; do curl -sI https://static.example.com/static/app.3f9a2c.js | grep -iE x-cache|age done除了看头还要做地域维度的验证。用不同区域的探测节点分别请求同一个地址比较首字节时间和下载速度。我更关注的是首字节时间的分布而不是平均值——平均值会被少数好数据拉低掩盖长尾问题。看 P95 和 P99如果某些区域的 P95 明显偏高说明该区域的调度或者节点覆盖有问题这时候要考虑调整调度策略而不是继续改缓存。最后一步是压测。用几十上百并发打同一个热点 URL观察边缘节点的响应时间和源站的回源量。正常情况下边缘响应应该稳定在几十毫秒内源站回源量应该只有一次并发合并生效。如果源站回源量随并发线性增长说明并发合并没开或者没生效这个必须查清楚。5. 动态加速和链路层的优化空间5.1 动态内容加速能做到什么程度动态内容不能缓存但可以优化传输。核心思路有三条一是就近接入用户的请求先到最近的边缘节点再由边缘节点通过优化过的骨干链路回源避免公网绕路二是连接复用边缘节点与源站之间保持长连接省掉每次请求的握手开销三是协议优化用更新的传输协议减少往返次数。这三条加起来的收益实测下来在跨地域场景通常是百分之二十到四十具体取决于原始链路的糟糕程度。链路越差收益越明显如果用户本来就在源站附近收益接近于零。所以动态加速不是必需品要看你的用户分布。如果八成用户集中在源站所在区域优先做静态资源加速就够了如果用户分布很散动态加速的性价比才体现出来。这里要泼一盆冷水动态加速解决的是传输慢解决不了处理慢。一个接口如果后端要算两秒加速之后还是一片哀嚎。上线动态加速之前先把源站的慢接口治理一遍把 P99 压到合理区间再谈链路优化顺序不能乱。5.2 协议层HTTP/2、HTTP/3 与 TLS 优化的实际收益HTTP/2 的多路复用解决了队头阻塞问题同一个连接上可以并行传多个资源对资源数量多的页面提升明显。开启很简单边缘节点基本都支持源站侧如果用的是主流反向代理加一行配置就能开。但要注意HTTP/2 要求 HTTPS而且部分老旧客户端不支持需要保留 HTTP/1.1 的兼容。HTTP/3 基于 UDP在弱网和移动网络下的表现明显更好丢包时不会像 TCP 那样整体降速。代价是部分网络环境对 UDP 有限制需要有回退到 HTTP/2 的机制。现在的做法一般是同时开 HTTP/2 和 HTTP/3让客户端自己协商通过Alt-Svc头告知客户端可以升级。上线后观察两个协议各自的请求占比和错误率如果某个区域 HTTP/3 的失败率明显偏高就在该区域降级。TLS 这块的优化点也不少。开 TLS 1.3 能把握手从两个 RTT 降到一個配合会话复用Session Ticket回访用户几乎不用重新握手。开启 OCSP 装订把证书状态校验的结果缓存在边缘省掉客户端额外去查证书状态的一次请求。证书链要精简只带必要的中间证书多带一级就多一次传输。这些细节单个看起来收益不大叠在一起对首屏时间的改善是实打实的。5.3 调度与容灾让用户总能落到合适的节点调度决定了用户被分配到哪个节点是整套体系里最上游的一环。常见方式有 DNS 调度和 HTTP DNS 调度前者依赖本地 DNS 解析精度受限于 LDNS 的位置后者由客户端直接请求调度接口精度高但需要客户端配合。还有一种方式是任播让同一个 IP 在不同区域都有节点靠路由协议把用户带到最近的一个这种方式对运维透明但故障切换的粒度较粗。不管用哪种调度都要配健康检查。节点故障时调度系统要在几十秒内把它摘掉否则用户会持续访问到坏节点。健康检查的探测点要覆盖真实链路不能只在机房内部探测因为很多故障是局部链路问题机房内部探测一切正常外部用户却完全连不上。我一般会要求探测点分布在不同区域和不同运营商探测间隔控制在十秒以内连续失败三次才摘除避免误判。容灾还要考虑源站故障的情况。边缘缓存里已有的内容在源站挂掉的时候依然可以正常服务这是 CDN 的一个隐性价值。所以对于关键内容可以适当延长 TTL让它在源站故障时多撑一段时间。同时配置好源站故障时的兜底策略比如返回缓存中的旧副本有的平台叫过期缓存兜底宁可给用户看几分钟前的旧数据也好过直接报错。6. 监控指标与问题排查实录6.1 必须盯住的几个核心指标配完只是开始真正的工作在后面的持续观察。我每天会看这几个数缓存命中率、回源率、边缘 5xx 率、首字节时间 P95、下载速度 P95。命中率的计算口径各家略有差异要搞清楚分母是请求数还是流量按请求数算的命中率对静态小文件敏感按流量算的命中率对大文件敏感两个都要看否则容易被单一指标误导。回源率是命中率的另一面但它更能反映问题。命中率下降时回源率会上升同时回源带宽也会上升。如果发现回源率突然抬头先看是哪些 URL 在回源通常能立刻定位到问题。首字节时间和下载速度要分区域看全局平均值参考价值不大。5xx 率是最需要盯的一旦抬头往往意味着源站出问题或者回源配置有误要在几分钟内响应。还有一个容易被忽略的指标是状态码分布里的 4xx 占比。如果 4xx 突然增多可能是有人扫描也可能是缓存键配置错误导致大量请求打到不存在的路径。另外要注意 206 的占比206 占比高说明大文件分片在正常工作如果大文件站点 206 占比接近零那多半是 Range 没生效。6.2 常见问题速查表现象可能原因排查动作处理方式命中率长期低于 70%查询参数打碎缓存键抽样看回源 URL 的参数分布配忽略参数列表或用哈希文件名发布后用户看到旧内容HTML TTL 过长且未刷新检查入口页 TTL 和刷新记录缩短 TTL发布流程加刷新步骤全站 404 但源站正常回源 Host 配错直接访问源站 IP 加 Host 头验证修正回源 Host 为源站绑定域名大面积 502/504回源超时或源站过载看源站负载和回源超时配置放宽超时加限流和重试退避图片偶发串号缓存键忽略了有效参数复现带不同参数的请求恢复该参数的缓存键参与视频拖动卡顿不支持 Range 回源检查 206 响应占比开启分片回源源站支持 Range某些区域访问特别慢调度不准或节点覆盖不足分区域看 P95 首字节调整调度策略补充节点源站带宽被打满缓存集体失效导致回源洪峰看回源带宽曲线和刷新记录错峰刷新配合预热加回源限速6.3 几个反直觉的坑我替你踩过了第一个坑缓存时间设得越长越好吗不是。有一次我把图片 TTL 设成三十天结果运营改了一张 banner 图但没改文件名用户三天后还在看旧图投诉一堆。后来改成图片走带版本号的目录新版放新目录老版本继续缓存两不相干问题才彻底解决。所以长 TTL 的前提是地址可变地址不可变就别贪长。第二个坑开了压缩反而变慢了。早期我在边缘开了全量压缩结果图片也被压了一遍CPU 上去不说压缩后的图片体积反而更大。压缩只能对文本类资源开图片、视频、压缩包这些已经是压缩格式的再压纯属浪费。而且压缩要在边缘做不要回源时让源站压边缘做的效率高得多。第三个坑以为开了 CDN 就万事大吉忽略了 DNS 的 TTL。有次切换加速服务商改了解析结果半天内还有用户解析到老地址访问异常。原因是原来的 DNS 记录 TTL 设了一天。后来所有准备切换的域名提前两天把 TTL 降到五分钟切换完再调回来就再没出过这个问题。第四个坑缓存刷新当成万能药。一有内容不一致就刷缓存刷完源站被打一波洪峰然后又开始限流恶性循环。正确的姿势是尽量用版本化地址从根上避免刷新刷新只作为应急手段且刷新后立刻预热把回源压力提前释放掉。这个习惯养成之后源站告警少了一大半。第五个坑只测首页不测长尾。首页往往是最热的预热也最充分测出来数据很好看。但真正影响用户体感的是那些长尾页面它们冷、没预热、每次都要回源。我现在的做法是专门抽样一批长尾 URL 做定时探测把长尾的首字节时间单独拉一条曲线出来看这条曲线才真实反映大部分用户的体验。最后分享一个我在实际项目里固定下来的习惯每次调整 CDN 配置都在变更记录里写清楚改了哪条规则、预期影响是什么、怎么回滚。这套体系里的配置项太多彼此还有优先级关系隔两个月回头看没人记得当时为什么把某条规则设成六十秒。把决策理由留下来比留下配置本身更有价值。
做运维和前端性能优化的朋友大概都遇到过这种场景源站明明跑得好好的本地测速一二百毫秒结果一到异地用户那边首屏时间直接飙到三四秒图片一张张往下掉。我第一次被这个问题按在地上摩擦是给一个内容型站点做异地访问优化当时天真地以为加个 CDN 域名解析过去就完事了结果上线第三天发现缓存命中率只有六成出头回源带宽不降反升源站 CPU 被打到告警。后来花了两周时间把边缘缓存规则、缓存键、回源配置、预热刷新这一整套东西重新捋了一遍才算把跨地域访问慢这个毛病按下去。这篇就把我踩过的坑和最后落地的配置方案完整写出来从边缘缓存怎么设计到回源怎么配、怎么压回源率、怎么验证效果适合正在做站点加速的初中级同学照着抄也适合已经上了 CDN 但效果不理想的同学对照排查。1. 先搞清楚跨地域访问慢到底慢在哪1.1 物理距离带来的延迟是绕不开的硬成本很多人一上来就怀疑服务器性能不行其实跨地域访问慢第一位的锅是物理距离。光在光纤里的传播速度大约是每毫秒两百公里一个来回下来跨越上千公里的链路单纯 RTT 就要几十毫秒。而一个网页加载往往不是一次请求HTML 拉下来之后还要拉 CSS、JS、字体、图片每一类资源都要重新握手。TCP 三次握手、TLS 握手在长链路加弱网环境下握手阶段就能吃掉两三个 RTT运气不好碰上丢包重传时间还要翻倍。这就是为什么同一份代码本地访问两百毫秒异地用户却要三四秒——不是源站算得慢而是数据在链路上跑得久。再往下拆还有几个容易被忽略的因素。其一是运营商互联质量跨网访问时中间要经过多次跳转和交换链路质量参差不齐高峰期丢包率上升TCP 拥塞控制一触发传输速率直接腰斩。其二是 MTU 和分片问题某些链路上大包会被丢弃导致大量重传。其三是源站出口带宽本身有限几十个并发大文件下载就能把出口打满后面的用户只能排队。所以做加速之前先明确一件事你要解决的是延迟问题、带宽问题还是两者都有。延迟问题靠就近接入和协议优化带宽问题靠边缘缓存分流两者的手段不一样混在一起谈就会像没头苍蝇一样乱改配置。1.2 边缘缓存加回源是这个体系里最基本的两条腿CDN 这套东西说白了就干两件事把内容提前放到离用户近的地方以及在没有缓存的时候替用户去源站取一趟。前者叫边缘缓存后者叫回源。理想状态下热点内容都在边缘用户请求在边缘节点直接返回RTT 从几十上百毫秒降到个位数到十几毫秒只有冷内容、动态内容、首次访问才会触发回源。所以衡量一个加速方案好不好核心就看两个数边缘缓存命中率高不高回源质量和回源量可不可控。我习惯把整个链路画成四段来理解用户到边缘节点这一段比拼的是调度准不准、节点离得近不近边缘节点内部的缓存查找比拼的是缓存键设计合不合理、TTL 配得对不对边缘回源到中间层或源站这一段比拼的是回源链路质量、超时重试、并发合并策略源站自身处理这一段比拼的是后端能力和限流保护。跨地域访问慢通常会在这四段里的某一段或者某几段同时出问题而绝大多数人只盯着上没上 CDN不看这四段的实际数据最后自然改不到点子上。1.3 什么情况下 CDN 帮不上忙得先想清楚有一个认知必须先建立CDN 不是万能药。纯动态接口、强依赖用户会话的内容、每次请求结果都不同的页面边缘缓存基本无能为力只能走动态加速靠优化链路和协议来减少往返次数收益通常在百分之二三十不会像静态资源那样立竿见影。还有一类是内容本身更新极其频繁又要求强一致的场景比如库存、余额这类内容硬缓存只会带来数据错乱宁可让它回源。另外如果源站本身的响应时间就很差比如一个接口要查三秒数据库那 CDN 再优化也只能把这三秒原封不动地传回来。这种情况先做源站性能治理再谈加速。我见过太多案例问题根子在慢 SQL 和没加索引却一直折腾边缘配置最后当然没效果。所以在动手之前先把一个请求的耗时拆开DNS 多久、建连多久、首字节多久、内容传输多久。哪一段占比最大就先治哪一段这个顺序错了后面全是无用功。2. 边缘缓存规则怎么设计才算合理2.1 缓存键的设计直接决定命中率的天花板缓存键是这个体系里最容易被忽视、又最要命的一环。默认情况下缓存键通常由协议、域名、路径三部分组成查询参数是否参与、是否区分大小写、是否带上某些请求头各家平台的默认策略并不一致。问题就出在这里很多前端项目习惯在资源地址后面挂时间戳比如app.js?v1699999999或者营销链接带一堆utm_source、from、share_id参数这些参数一变缓存键就变边缘节点会认为是不同的资源于是同一份文件被缓存了几十份命中率被硬生生打碎。我的处理原则是静态资源要么用文件名带内容哈希的方式做版本管理比如app.3f9a2c.js要么在配置里明确忽略掉无意义的查询参数。前者是最干净的做法文件内容变了文件名就变天然不需要刷新缓存后者是补救手段把utm_*、from、timestamp这类参数加入忽略列表让它们不参与缓存键计算。这里有个坑要注意忽略参数不能一刀切。像?page2、?id100这种真正决定内容差异的参数一旦被忽略用户就会看到别人的内容这是事故级别的问题。所以忽略列表一定是白名单式的精确列举不是模糊匹配更不是全部忽略。还有一个细节是域名。如果同一个站点同时挂了主域名和备用域名或者带 www 和不带 www 都能访问缓存键里包含域名就意味着两套缓存各占一份空间。在 CDN 配置里把这两个域名收敛到同一份缓存能白捡一截命中率。这类调整看着不起眼实测下来对中小站点往往能带来五到十个百分点的命中率提升。2.2 TTL 分层不同资源用完全不同的时间尺度TTL 设置最常见的错误是全站一个值要么全设十分钟导致频繁回源要么全设一天导致发布后用户看到旧内容。合理的做法是按资源类型分层我给一个自己一直在用的参考表资源类型建议 TTL版本策略说明带哈希的 JS/CSS一年文件名哈希内容变则名变无需刷新图片、字体、图标7 到 30 天目录加版本号更新走新路径视频、大文件分片7 天以上路径版本化配合 Range 回源HTML 入口页10 秒到 5 分钟短 TTL保证发布能较快生效公共配置 JSON1 到 5 分钟接口版本号兼顾新鲜度与命中率用户相关接口不缓存无避免串号这张表背后的逻辑很简单TTL 越长命中率越高、回源越少但内容新鲜度越差。破解这个矛盾的办法不是找一个折中的中间值而是把内容变化这件事从时间维度转移到路径维度。文件名带哈希、目录带版本号内容一变更地址就变缓存自然失效此时 TTL 设多长都无所谓设一年反而最优。入口 HTML 因为地址不能变只能靠短 TTL 加主动刷新来控制。把这两类资源分开对待是整套缓存策略的核心分水岭。2.3 缓存头的优先级关系别让源站把 CDN 规则覆盖掉这一条踩坑的人极多。很多平台的缓存规则是有优先级的源站返回的响应头优先级通常高于控制台上配的默认规则而控制台上配的针对特定路径的规则又可能高于全局默认。也就是说你辛辛苦苦在控制台把某个目录设成缓存一天结果源站返回一个Cache-Control: no-cache边缘节点照样不缓存你还在纳闷为什么命中率上不去。几个关键响应头必须记牢。Cache-Control: max-age是给浏览器和共享缓存用的s-maxage专门针对共享缓存CDN 就属于这一类它的优先级高于max-age想给 CDN 单独设更长的缓存时间用这个最合适。private表示只允许浏览器缓存CDN 必须不缓存用户态接口一定要带上。no-store是完全不存连浏览器都不存no-cache容易被误解它其实允许存储只是每次使用前必须回源校验很多人把这两个搞混结果配了no-cache还奇怪为什么还有缓存。Expires是老古董优先级低于Cache-Control两都存在时以后者为准。我的经验是源站只负责声明内容的性质能不能缓存、是不是私有具体缓存多久交给 CDN 控制台的规则去配。这样发布新策略时不用改代码重新发版灵活得多。实操中我一般让后端统一输出Cache-Control: public, max-age0, s-maxagexxx把 CDN 侧的缓存时间完全掌握在运维手里。2.4 Cookie、Vary 和 Range 这三个隐形杀手Cookie 对缓存的影响非常直接绝大多数 CDN 的默认行为是请求里带 Cookie 就不缓存或者把 Cookie 纳入缓存键。前者会让所有登录用户的静态资源请求全部回源后者会让缓存被无限打碎。正确做法是让静态资源域和主站域分离静态资源请求根本不带 Cookie这是最干净的方案如果做不到分离就在 CDN 上配置忽略 Cookie 进行缓存但只对静态资源目录开这个口子接口路径千万别开。Vary 头是第二个隐形杀手。Vary: Accept-Encoding会让同一份资源按压缩与非压缩存两份这还算正常因为客户端确实需要不同格式。但Vary: User-Agent或Vary: Cookie就是灾难前者会把缓存按 UA 打碎成几十份后者直接导致缓存不可用。上线前用curl -I扫一遍响应头看到这两个基本就得让后端改掉。Range 请求影响的是大文件和视频场景。如果 CDN 不支持分片回源用户拖动进度条请求某一段时边缘节点会把整个文件从源站拉一遍源站带宽瞬间爆炸。所以视频、安装包这类大文件一定要确认边缘支持 Range 回源并且回源时按片拉取。这一条我是在一次视频站点优化中血泪学到的当时源站出口被打满查了半天才发现是拖动进度条导致的整文件回源。3. 回源配置把回源率压下去把回源质量提上来3.1 回源 Host、协议和端口这三个参数必须一次配对回源配置里最基础也最容易配错的就是回源 Host。它的作用是告诉源站我这次请求访问的是哪个站点因为一台源站上可能挂了几十个站点靠 Host 区分。常见的坑是CDN 加速域名是static.example.com源站实际站点绑定的是origin.internal.example.com如果回源 Host 没改成后者源站会返回 404 或者跳到默认站点表现就是CDN 上全是 404但源站直接访问正常。这个问题的排查成本不低因为很多人第一反应是怀疑缓存绕一大圈才想到 Host。回源协议要跟源站实际监听保持一致。源站只开了 443你配 80 回源结果就是连接超时或者 301 循环。反过来源站只开 80你配 443 回源握手直接失败。现在比较稳妥的做法是源站同时监听 80 和 443CDN 侧统一用 HTTPS 回源并在回源链路上校验证书。如果源站用的是自签证书或者内部 CA 签发的证书记得把回源校验证书的开关按实际情况处理别一边要求校验一边用自签那必然是握手失败。端口这块相对简单但要注意非标准端口在某些平台上需要在回源配置里显式声明否则默认走 80/443 会连不上。还有一个细节是回源域名解析如果回源地址写的是域名边缘节点需要做 DNS 解析解析结果的稳定性和 TTL 会影响回源成功率。生产环境我更倾向于配多个回源地址做冗余避免单个地址故障导致整体不可用。下面是一段源站侧的参考配置重点是让源站能正确识别 CDN 回源请求、正确输出缓存头、并支持 Rangeserver { listen 443 ssl; server_name origin.internal.example.com; # 回源链路开启长连接减少握手开销 keepalive_timeout 75s; keepalive_requests 1000; # 静态资源允许共享缓存CDN 侧可长缓存 location ~* \.(js|css|png|jpg|jpeg|webp|woff2)$ { add_header Cache-Control public, max-age0, s-maxage2592000; add_header Access-Control-Allow-Origin *; add_header Accept-Ranges bytes; etag on; expires off; } # 入口 HTML短缓存允许协商 location /index.html { add_header Cache-Control public, max-age0, s-maxage60; } # 用户态接口禁止 CDN 缓存 location /api/user/ { add_header Cache-Control private, no-store; } }3.2 回源超时、重试与并发回源合并回源超时的三个参数要分开设置连接超时、首字节超时等待源站开始响应的时间、读超时传输过程中的空闲时间。连接超时一般设短一些三到五秒足够因为跨地域建连如果五秒还没建立基本可以判定链路有问题首字节超时才是关键它直接决定了源站慢的时候用户等多久通常设十到三十秒读超时针对大文件传输可以设长一些六十秒以上都正常。这三个值配小了会导致源站稍微抖一下就被判超时用户看到 5xx配大了会导致源站真挂的时候用户一直转圈直到超时体验更差。我的经验是按业务类型分开配接口类首字节超时短一些八到十秒快速失败让前端走降级页面和静态资源可以放宽到二十秒以上。重试策略要特别注意重试放大问题。边缘节点回源失败后自动重试本身是好事但如果源站已经因为压力过大而变慢重试会让请求量翻倍甚至翻几倍直接把源站压死。所以我一般只对连接失败、5xx 这类明确可重试的错误开重试且重试次数限制在一到两次重试间隔做退避。4xx 一律不重试因为它重试一百次结果也一样。并发回源合并有的平台叫请求折叠是提效利器。同一个资源在同一时刻被一百个用户请求边缘节点只向源站发一次请求其余请求等这一次的结果。这个机制对热点内容首次回源特别有效能把回源峰值削掉一大截。启用它的前提是回源请求必须是幂等的 GET对 POST 一定要关掉否则会出数据错乱。3.3 分片回源与大文件场景的额外处理大文件场景跟小文件完全是两套逻辑。一个几百兆的安装包如果按整文件回源源站出口带宽会被单个请求占满其他用户只能干等。分片回源把文件切成固定大小的块常见是 1MB 或 4MB边缘节点按需拉取用户拖到哪就拉到哪带宽利用率高得多。这里有个前提源站必须支持 Range 请求返回 206 状态码和Content-Range头。如果源站是个纯静态文件服务器通常天然支持如果源站是应用服务器动态输出文件流就要自己实现 Range 逻辑否则 CDN 发来的 Range 请求会被当成普通请求返回整个文件分片就白配了。验证方法很简单用 curl 发一个带 Range 的请求看返回码# 期望返回 206 Partial Content并带 Content-Range curl -I -H Range: bytes0-1023 https://origin.internal.example.com/bigfile.zip # 检查边缘节点是否正确透传 Range curl -I -H Range: bytes0-1023 https://static.example.com/bigfile.zip另外视频场景还有个特殊点拖动进度条时会产生大量随机 Range 请求如果每个都回源源站压力很大。比较稳妥的做法是开预取让边缘在用户播放时提前拉取相邻片段同时把分片时长设短一些减少单次拉取的数据量。3.4 源站保护别让加速把源站拖垮这一条是我认为最应该强调、但讲得最少的。CDN 的一个副作用是它会把流量放大后打到源站尤其是缓存没命中的时候。如果源站没有保护一次缓存集体失效或者一次恶意刷量就能把源站打挂。基本的保护手段有几个层次。第一层是回源限速给单个边缘节点到源站的并发连接数设上限避免瞬间打满第二层是回源鉴权让源站只接受带合法签名的回源请求防止有人绕过 CDN 直接刷源站第三层是源站前面的负载均衡和限流按接口维度限制 QPS第四层是兜底降级源站超负荷时返回一个静态兜底页而不是让请求堆积。回源鉴权这块常见做法是 CDN 在回源时带上一个密钥计算的签名头源站在入口处校验。密钥要定期轮换且不能写死在前端代码里。还有一种是时间戳签名把过期时间编进签名超过时间就拒绝防止重放。这套东西配起来麻烦一点但比源站被打挂之后救火要省事得多。4. 一套完整的落地配置过程4.1 接入前的准备域名规划与源站梳理动手配之前先花半天时间把资产盘清楚能省掉后面大量返工。第一步是域名规划我推荐至少分三个主站域名承载 HTML 和接口静态资源域名专门承载 JS、CSS、图片、字体上传下载域名承载大文件。分开的好处是缓存策略可以完全独立配置静态资源域可以放心开长缓存、忽略 Cookie主站域保持短缓存并允许带 Cookie互不干扰。顺带还能突破浏览器对单域名并发连接数的限制虽然 HTTP/2 之后这个限制弱化了但域名分离在缓存管理上的价值依然很大。第二步是梳理源站。把源站的 IP、端口、监听协议、证书情况、站点绑定关系全部列出来特别是确认源站是否有多个实例、是否有负载均衡层、回源应该指向负载均衡还是直接指向实例。如果源站有 WAF 或者访问控制白名单要提前把 CDN 的回源网段加进去否则回源全部被拦截表现就是全站 403。第三步是确认业务里哪些路径是绝对不能缓存的。用户中心、订单、支付回调、后台管理这些路径要在配置里显式排除。我的做法是先在 CDN 上配一条全局不缓存的兜底规则然后逐条添加允许缓存的路径白名单这样即使漏配最坏结果是命中率低而不是数据串号。这个顺序千万别反过来。4.2 缓存规则配置实录下面这张表是我实际项目里用的规则集按优先级从高到低排列平台之间的字段名可能不同但逻辑是通用的优先级匹配路径缓存行为TTL缓存键处理1/api/user/*不缓存--2/api/order/*不缓存--3/api/public/config缓存60s忽略 utm_* 参数4/static/.js, /static/.css缓存30d忽略全部查询参数5/img/*缓存7d忽略全部查询参数6/upload/*缓存7d保留全部参数7/*.html缓存60s保留全部参数8默认不缓存--第 4 条之所以敢忽略全部查询参数是因为这些文件名本身带内容哈希查询参数纯属历史遗留忽略掉只会提升命中率不会串内容。第 6 条保留全部参数是因为上传目录的图片地址参数可能带尺寸处理指令忽略会导致返回错误尺寸。第 7 条 HTML 保留参数因为分页、筛选都靠参数区分。配套还要配几条响应头处理在边缘统一加上Access-Control-Allow-Origin省得源站每个接口都写一遍把源站返回的Set-Cookie在静态资源路径上剥掉避免污染缓存开启 Brotli 压缩文本类资源能省三到五成带宽注意开了压缩之后缓存键会自动按编码区分这是正常的。4.3 预热与刷新的正确用法预热是把内容主动推到边缘让第一批用户不用等回源。它特别适合两类场景大促或者活动上线前把确定会热的关键页面和图片提前推一遍版本发布后把新的静态资源推到主要节点。预热的坑在于它有速率限制一次推几千个 URL 会被限流而且预热是按 URL 来的如果你的资源地址带随机参数预热基本无效。所以预热清单要精确优先推首页、频道页、核心图片这些真正高热的内容。刷新是让缓存失效分 URL 刷新、目录刷新、正则刷新几种。URL 刷新的额度通常有限发布后动辄几百个文件靠 URL 刷新根本不够用。我的做法是发布流程里把静态资源文件名带上内容哈希这样根本不需要刷新新文件新地址老文件自然淘汰只有入口 HTML 需要刷新数量少用 URL 刷新完全够。目录刷新要慎用因为它会把整个目录下的缓存清空一瞬间全部回源很容易把源站打崩。如果非要清目录配合预热一起做先刷新再预热把回源压力控制在可控范围。4.4 验证怎么确认配置真的生效了配完不验证等于没配。最基础的是用 curl 看响应头重点看三个字段X-Cache类字段各家命名不同表示命中还是回源、Age表示这份缓存在边缘存了多久、Cache-Control。# 第一次请求观察是否 MISS 并触发回源 curl -sI https://static.example.com/static/app.3f9a2c.js | grep -iE x-cache|age|cache-control # 连续请求几次观察是否变成 HIT 且 Age 递增 for i in 1 2 3; do curl -sI https://static.example.com/static/app.3f9a2c.js | grep -iE x-cache|age done除了看头还要做地域维度的验证。用不同区域的探测节点分别请求同一个地址比较首字节时间和下载速度。我更关注的是首字节时间的分布而不是平均值——平均值会被少数好数据拉低掩盖长尾问题。看 P95 和 P99如果某些区域的 P95 明显偏高说明该区域的调度或者节点覆盖有问题这时候要考虑调整调度策略而不是继续改缓存。最后一步是压测。用几十上百并发打同一个热点 URL观察边缘节点的响应时间和源站的回源量。正常情况下边缘响应应该稳定在几十毫秒内源站回源量应该只有一次并发合并生效。如果源站回源量随并发线性增长说明并发合并没开或者没生效这个必须查清楚。5. 动态加速和链路层的优化空间5.1 动态内容加速能做到什么程度动态内容不能缓存但可以优化传输。核心思路有三条一是就近接入用户的请求先到最近的边缘节点再由边缘节点通过优化过的骨干链路回源避免公网绕路二是连接复用边缘节点与源站之间保持长连接省掉每次请求的握手开销三是协议优化用更新的传输协议减少往返次数。这三条加起来的收益实测下来在跨地域场景通常是百分之二十到四十具体取决于原始链路的糟糕程度。链路越差收益越明显如果用户本来就在源站附近收益接近于零。所以动态加速不是必需品要看你的用户分布。如果八成用户集中在源站所在区域优先做静态资源加速就够了如果用户分布很散动态加速的性价比才体现出来。这里要泼一盆冷水动态加速解决的是传输慢解决不了处理慢。一个接口如果后端要算两秒加速之后还是一片哀嚎。上线动态加速之前先把源站的慢接口治理一遍把 P99 压到合理区间再谈链路优化顺序不能乱。5.2 协议层HTTP/2、HTTP/3 与 TLS 优化的实际收益HTTP/2 的多路复用解决了队头阻塞问题同一个连接上可以并行传多个资源对资源数量多的页面提升明显。开启很简单边缘节点基本都支持源站侧如果用的是主流反向代理加一行配置就能开。但要注意HTTP/2 要求 HTTPS而且部分老旧客户端不支持需要保留 HTTP/1.1 的兼容。HTTP/3 基于 UDP在弱网和移动网络下的表现明显更好丢包时不会像 TCP 那样整体降速。代价是部分网络环境对 UDP 有限制需要有回退到 HTTP/2 的机制。现在的做法一般是同时开 HTTP/2 和 HTTP/3让客户端自己协商通过Alt-Svc头告知客户端可以升级。上线后观察两个协议各自的请求占比和错误率如果某个区域 HTTP/3 的失败率明显偏高就在该区域降级。TLS 这块的优化点也不少。开 TLS 1.3 能把握手从两个 RTT 降到一個配合会话复用Session Ticket回访用户几乎不用重新握手。开启 OCSP 装订把证书状态校验的结果缓存在边缘省掉客户端额外去查证书状态的一次请求。证书链要精简只带必要的中间证书多带一级就多一次传输。这些细节单个看起来收益不大叠在一起对首屏时间的改善是实打实的。5.3 调度与容灾让用户总能落到合适的节点调度决定了用户被分配到哪个节点是整套体系里最上游的一环。常见方式有 DNS 调度和 HTTP DNS 调度前者依赖本地 DNS 解析精度受限于 LDNS 的位置后者由客户端直接请求调度接口精度高但需要客户端配合。还有一种方式是任播让同一个 IP 在不同区域都有节点靠路由协议把用户带到最近的一个这种方式对运维透明但故障切换的粒度较粗。不管用哪种调度都要配健康检查。节点故障时调度系统要在几十秒内把它摘掉否则用户会持续访问到坏节点。健康检查的探测点要覆盖真实链路不能只在机房内部探测因为很多故障是局部链路问题机房内部探测一切正常外部用户却完全连不上。我一般会要求探测点分布在不同区域和不同运营商探测间隔控制在十秒以内连续失败三次才摘除避免误判。容灾还要考虑源站故障的情况。边缘缓存里已有的内容在源站挂掉的时候依然可以正常服务这是 CDN 的一个隐性价值。所以对于关键内容可以适当延长 TTL让它在源站故障时多撑一段时间。同时配置好源站故障时的兜底策略比如返回缓存中的旧副本有的平台叫过期缓存兜底宁可给用户看几分钟前的旧数据也好过直接报错。6. 监控指标与问题排查实录6.1 必须盯住的几个核心指标配完只是开始真正的工作在后面的持续观察。我每天会看这几个数缓存命中率、回源率、边缘 5xx 率、首字节时间 P95、下载速度 P95。命中率的计算口径各家略有差异要搞清楚分母是请求数还是流量按请求数算的命中率对静态小文件敏感按流量算的命中率对大文件敏感两个都要看否则容易被单一指标误导。回源率是命中率的另一面但它更能反映问题。命中率下降时回源率会上升同时回源带宽也会上升。如果发现回源率突然抬头先看是哪些 URL 在回源通常能立刻定位到问题。首字节时间和下载速度要分区域看全局平均值参考价值不大。5xx 率是最需要盯的一旦抬头往往意味着源站出问题或者回源配置有误要在几分钟内响应。还有一个容易被忽略的指标是状态码分布里的 4xx 占比。如果 4xx 突然增多可能是有人扫描也可能是缓存键配置错误导致大量请求打到不存在的路径。另外要注意 206 的占比206 占比高说明大文件分片在正常工作如果大文件站点 206 占比接近零那多半是 Range 没生效。6.2 常见问题速查表现象可能原因排查动作处理方式命中率长期低于 70%查询参数打碎缓存键抽样看回源 URL 的参数分布配忽略参数列表或用哈希文件名发布后用户看到旧内容HTML TTL 过长且未刷新检查入口页 TTL 和刷新记录缩短 TTL发布流程加刷新步骤全站 404 但源站正常回源 Host 配错直接访问源站 IP 加 Host 头验证修正回源 Host 为源站绑定域名大面积 502/504回源超时或源站过载看源站负载和回源超时配置放宽超时加限流和重试退避图片偶发串号缓存键忽略了有效参数复现带不同参数的请求恢复该参数的缓存键参与视频拖动卡顿不支持 Range 回源检查 206 响应占比开启分片回源源站支持 Range某些区域访问特别慢调度不准或节点覆盖不足分区域看 P95 首字节调整调度策略补充节点源站带宽被打满缓存集体失效导致回源洪峰看回源带宽曲线和刷新记录错峰刷新配合预热加回源限速6.3 几个反直觉的坑我替你踩过了第一个坑缓存时间设得越长越好吗不是。有一次我把图片 TTL 设成三十天结果运营改了一张 banner 图但没改文件名用户三天后还在看旧图投诉一堆。后来改成图片走带版本号的目录新版放新目录老版本继续缓存两不相干问题才彻底解决。所以长 TTL 的前提是地址可变地址不可变就别贪长。第二个坑开了压缩反而变慢了。早期我在边缘开了全量压缩结果图片也被压了一遍CPU 上去不说压缩后的图片体积反而更大。压缩只能对文本类资源开图片、视频、压缩包这些已经是压缩格式的再压纯属浪费。而且压缩要在边缘做不要回源时让源站压边缘做的效率高得多。第三个坑以为开了 CDN 就万事大吉忽略了 DNS 的 TTL。有次切换加速服务商改了解析结果半天内还有用户解析到老地址访问异常。原因是原来的 DNS 记录 TTL 设了一天。后来所有准备切换的域名提前两天把 TTL 降到五分钟切换完再调回来就再没出过这个问题。第四个坑缓存刷新当成万能药。一有内容不一致就刷缓存刷完源站被打一波洪峰然后又开始限流恶性循环。正确的姿势是尽量用版本化地址从根上避免刷新刷新只作为应急手段且刷新后立刻预热把回源压力提前释放掉。这个习惯养成之后源站告警少了一大半。第五个坑只测首页不测长尾。首页往往是最热的预热也最充分测出来数据很好看。但真正影响用户体感的是那些长尾页面它们冷、没预热、每次都要回源。我现在的做法是专门抽样一批长尾 URL 做定时探测把长尾的首字节时间单独拉一条曲线出来看这条曲线才真实反映大部分用户的体验。最后分享一个我在实际项目里固定下来的习惯每次调整 CDN 配置都在变更记录里写清楚改了哪条规则、预期影响是什么、怎么回滚。这套体系里的配置项太多彼此还有优先级关系隔两个月回头看没人记得当时为什么把某条规则设成六十秒。把决策理由留下来比留下配置本身更有价值。
