1. 先把CDN这件事说透它到底是个什么产品这些年被问得最多的一类问题是网站明明服务器配置不低带宽也加过为什么用户还是说慢等到把CDN接进来页面打开了、视频不卡了、源站带宽曲线也降下来了于是很多人对CDN的第一印象就停在加速两个字上。这个理解不算错但太窄了——CDN内容分发网络本质上是一张铺在用户和源站之间的分布式缓存与流量调度网络加速只是它最表层的能力往下还有缓存卸载、协议优化、就近接入、流量清洗、可观测性等一整套东西。如果你只是把它当成买个加速包大概率会买贵、配错、还排不出问题。我经手过的项目里CDN踩坑最集中的不是选型而是接入之后的配置和维护缓存规则随手一填命中率长期卡在30%等于花钱买了个高级代理或者反过来把带用户身份的接口也缓存了出现A用户看到B用户数据的严重事故再或者源站IP早就暴露在外面CDN开了一堆防护却形同虚设。这些问题都不是产品能力问题是对CDN运行机制理解不到位。这篇文章想解决的就是这三件事CDN到底是什么产品、它的防护效果究竟几斤几两、以及面对市面上几十家服务商该怎么选。适合刚接手站点运维的同学、正在做技术选型的后端和架构同学也适合负责成本的产品和市场同学——毕竟CDN账单往往是基础设施里波动最大的那一项。下面的内容尽量讲人话配置示例和参数都会给出推导过程你可以直接拿去对照自己的场景。1.1 从一次打开慢说起CDN真正解决的三个问题先建立一个具体的画面。假设源站部署在某个机房一个外地用户打开你的页面浏览器要发起几十个请求HTML、CSS、JS、字体、图片、接口数据。如果全部直连源站这条链路上会发生三件麻烦事物理距离带来的往返时延、跨运营商互联带来的抖动、以及源站出口带宽被瞬时并发打满。这三件事对应CDN的三个核心价值——就近接入、链路优化、流量卸载。就近接入解决的是路远。用户请求不再千里迢迢跑到源站而是落到离他几十毫秒内的一张边缘节点上节点上有你要的文件就直接返回。链路优化解决的是路差即使必须回源CDN服务商内部通常有专线或优化链路比公网直连稳定得多。流量卸载解决的是源站扛不住命中缓存的请求根本不回源源站只承担未命中的那部分这个比例就是命中率。我习惯用一个类比源站是总仓库边缘节点是城市前置仓。前置仓有的货直接发没有的才回总仓调。总仓的发货压力取决于前置仓的备货准确度——也就是你的缓存策略。备错了前置仓全是滞销品用户要的每次都回总仓那这套前置仓体系就白建了。所以CDN的效果好不好一半看服务商一半看你自己的缓存设计这句话我在后面还会反复提。1.2 一张请求路径图拆开看调度、边缘节点与回源链路完整的一次CDN请求大体经过这么几个环节每一环都有可调参数也都是故障高发区。第一步是调度。你把自己的加速域名用CNAME指向服务商给的域名用户DNS解析时服务商的调度系统会根据用户出口IP的运营商、地理位置、节点健康状态、节点负载返回一个当下最合适的边缘节点IP。这里的差异很大有的调度只看地理距离有的会结合实时探测和节点容量做动态调整还有的做应用层调度把请求在七层再做一次分配。调度精度直接决定了就近是不是真的近。第二步是边缘节点处理。请求到达节点后节点先判断这个URL是否可缓存、缓存是否还在有效期内、缓存key是否匹配。命中则直接返回响应头里一般会带一个缓存状态标识字段名各家不同常见的是类似X-Cache: HIT/MISS这种。未命中则进入回源流程。边缘节点还会做压缩、合并、协议转换比如把HTTP/1.1的回源结果用HTTP/2或HTTP/3返回给浏览器。第三步是回源。节点向源站发起请求这里涉及回源Host、回源协议HTTP还是HTTPS、回源超时、重试次数、是否带原请求的Header。多层缓存架构里还可能先到中间层父层再回源中间层的作用是把大量边缘节点的回源请求收敛成少数几次避免源站被回源风暴打爆。回源拿到内容后节点按缓存规则落盘再返回给用户。三步之外还有一条常被忽略的旁路日志和计量。CDN的计费、命中率统计、防护拦截记录都来自这一层。如果你的业务对成本敏感一定要把这条旁路的数据拉出来看很多钱就是从这儿悄悄跑掉的。1.3 它不是一个插件而是一套分布式缓存系统把CDN当成插件的人通常会犯两个错。第一个错是认为接了CDN就快了结果源站本身慢比如数据库查询要两秒CDN再快也只能把两秒原样转发给用户——CDN只能优化传输不能优化计算。第二个错是认为接了CDN就安全了把CDN当成安全网关后面会专门讲这个边界。正确的认知是CDN是一套分布式缓存系统它的行为由缓存规则、TTL、缓存key、回源策略这几个东西共同决定而这些全是你在控制台里配的。它更像你部署在几百个城市的一层只读代理代理的行为逻辑由你定义。既然是缓存系统那么缓存系统固有的问题它全都有一致性、穿透、雪崩、碎片。一致性指的是源站内容更新后边缘上的旧副本要多久才失效穿透指的是大量请求查询不存在的资源每次都打到源站雪崩指的是某个热点缓存同时过期瞬间全量回源碎片指的是同一个内容因为URL参数不同被缓存成几百份命中率被摊薄。后面的章节会逐个讲怎么处理。2. 决定效果的核心细节缓存、调度与回源接入CDN之后最值得天天盯的指标只有一个缓存命中率。它直接决定了你的源站压力、用户的首字节时间和你的账单。但这个数字很多人看错了或者看对了却不知道该怎么改。2.1 命中率到底怎么算为什么它决定你的账单命中率有两种算法按请求数算和按流量算。按请求数算命中率 边缘命中请求数 / 总请求数按流量算命中率 边缘命中流量 / 总流量。这两个数字经常差得很远原因是大文件和小文件的分布不均匀。举个具体的例子。一个图片站点日均总流量10TB其中95%的流量来自图片但图片请求只占总请求数的20%剩下80%的请求是HTML、JS、接口这类小文件。如果图片缓存做得很好99%命中小文件几乎不缓存那么按流量算命中率可能高达94%按请求数算却只有20%出头。你在控制台看到94%觉得挺好实际上每天有数百万次请求在回源源站的连接数压力一点都不小。反过来更常见一个以接口和HTML为主的站点请求数命中率看着有80%但回源的全是大文件流量命中率只有30%源站出口带宽月月打满。所以这两个指标必须一起看缺一个都会误判。再算一笔钱。假设日均流量10TB、请求数1亿次命中率90%。命中意味着只有10%的流量和请求回源即1TB流量、1000万次回源请求。如果你的业务是大量小文件比如每个页面100个1KB左右的静态资源一天1000万PV就是10亿次请求流量却只有1TB左右10亿 × 1KB ≈ 976GB。这时候你会发现HTTPS请求数的费用可能比流量费还高。很多服务商的计费项里流量、HTTP请求数、HTTPS请求数、静态HTTPS请求数是分开计价的小文件多、请求数大的业务一定要提前测算否则第一个月账单出来会很难受。提示接入前先做一次请求数 × 平均文件大小的粗算判断自己属于流量型还是请求型业务再去看计费项能省下的往往比谈折扣多。2.2 缓存key与TTL的取舍一次真实配置的推演缓存key决定了什么算同一份内容。默认情况下绝大多数CDN把完整URL含query string作为key这意味着/img/a.png?v1和/img/a.png?v2是两份缓存。这个默认行为在小程序、前端构建工具、带时间戳防缓存的场景下会制造大量碎片。我遇到过一个典型案例前端为了保证拿到最新资源给每个静态资源请求都拼了一个?t时间戳。结果是每次请求的URL都不一样缓存永远不命中命中率接近于0所有流量全回源。改法有两种一是前端改成用文件内容hash作为版本号?va1b2c3这样版本不变key就不变二是在CDN侧配置忽略指定query参数或仅按指定参数做key。前者是治本后者是兜底我一般建议两个都做。TTL缓存有效期的设置要按内容类型分档不能一刀切。我的常用分档是这样的内容类型建议TTL理由与配套措施带hash的JS/CSS/图片/字体30天以上内容变更即换文件名长TTL无一致性风险不带hash的图片、附件1到7天配合目录刷新做兜底HTML入口页1到10分钟或协商缓存宁可短避免用户看到旧页面纯静态JSON配置5到30分钟视业务容忍度配置刷新接口用户相关接口不缓存用规则明确排除防串号公共只读接口如城市列表30秒到5分钟必须配按key区分的缓存key这里有个必须说清的风险带用户身份的内容绝不能进共享缓存。判断标准很简单——响应内容是否随Cookie、Authorization、用户ID变化。如果是要么不缓存要么配置按指定Header或Cookie做缓存key让它变成多份隔离缓存。这一条出问题就不是性能问题是数据泄露事故。我在评审配置时第一眼看的永远是缓存排除规则里有没有把登录态接口、订单接口、个人中心接口列进去。还有一个细节TTL不是越长越好。长TTL的代价是内容更新不及时必须靠主动刷新。而刷新是有配额的URL刷新和目录刷新各有次数限制紧急发布时经常不够用。所以长TTL的前提是文件名带版本而不是靠刷新续命。2.3 调度精度与回源链路才是加速体感的分水岭缓存规则配好了用户还是觉得偶尔卡一下问题常常出在调度和回源。调度这块判断标准是同一个用户连续几次解析落到的是不是同一个区域、同一批节点。如果每次落到很远的节点或者频繁在节点间跳变用户体验就是忽快忽慢。测试方法很土但有效在几个不同运营商、不同区域的机器上反复解析你的加速域名看返回的IP归属和往返时延再看是否稳定。更靠谱的做法是看服务商是否提供节点分布和调度策略的说明以及是否支持按运营商、按区域的精细调度。回源链路这块重点看三个配置。第一是回源Host很多源站部署了多个站点Host配错会直接返回404或者串站这是接入首日最常见的故障。第二是回源协议如果源站支持HTTPS建议回源也走HTTPS否则中间链路上是明文。第三是超时和重试连接超时通常设3到5秒读取超时按业务设10到30秒重试次数设1到2次就够——重试次数设太多源站一旦抖动会形成重试风暴把小抖动放大成大故障。另外多层缓存中间层/父层这个能力流量规模上去以后一定要开。它把几百个边缘节点的回源请求收敛成几十次源站看到的并发会下降一个数量级。代价是多一跳首字节时间可能增加几十毫秒对静态资源完全值得对时延敏感的动态接口要单独评估。3. CDN防护效果到底怎么样能挡住什么挡不住什么先给结论CDN的防护是真实有效的但它的有效性高度依赖缓存有没有帮你挡在前面以及你的源站有没有藏好。把它当成万能盾牌一定会失望把它当成第一层过滤网用对了收益很大。3.1 防护的底层逻辑把集中压力摊到分布式边缘CDN能做防护本质上靠两件事分散和过滤。分散是指原本所有流量都砸向源站一个出口现在被摊到几百个节点上。单节点的处理能力和带宽是有限的但整体容量是源站的很多倍。恶意流量打到CDN上先被这张网稀释能在边缘消化掉的就消化掉了不会形成对源站出口的集中冲击。这也是为什么CDN接入后源站带宽曲线会突然变得很平滑。过滤是指边缘节点在七层上能看到每一个请求的URL、Header、参数、频率可以在返回内容之前做判断这个IP一秒发了几百次请求拦掉这个请求的特征明显不像正常浏览器给个人机校验这个URL参数超长或者包含明显的注入特征拒绝这个来源在短时间内扫了大量不存在的路径拉黑一段时间。这些动作都在边缘完成源站根本不感知。所以防护效果好坏取决于两个前提一是流量确实经过CDN源站IP没暴露二是规则确实匹配你的业务不是开了个默认策略就不管。第二点后面单独说。3.2 分层防护的实际做法限速、人机校验、缓存挡刀我把CDN侧的防护配置分成三层按成本从低到高排列。第一层是缓存挡刀成本最低、效果最直接。大量异常请求的特征是重复访问同一个或少数几个URL比如反复请求首页、反复请求某个搜索接口。如果这些URL本身可缓存请求在边缘就被拦下了根本不会形成回源压力。所以把该缓存的缓存好这件事本身就是一个防护动作而且不花钱。反过来说如果你的站点命中率很低防护成本会成倍上升——因为每个异常请求都要消耗回源资源。第二层是频率限制。按IP、按URL、按Header维度设置阈值比如单IP对同一URL的请求超过每秒20次就限速或返回一个挑战页。这里的难点是阈值怎么定。我的做法是先跑一周观察把正常用户的P99峰值拉出来阈值设在P99的3到5倍留足余量。阈值设太低会误伤正常用户尤其是共用出口IP的企业网络和移动网络NAT场景设太高等于没设。另外要注意限速规则要能按URL路径差异化登录、下单这类关键接口阈值要严图片、静态资源可以宽。第三层是人机校验和精细化规则。对疑似异常的会话弹一个轻量的JS挑战正常浏览器能自动通过脚本化的请求过不去。再加上地理位置、User-Agent特征、Referer校验这些规则做组合判断。这一层的能力各家差异最大也是选型时最该实际测试的部分。配置顺序上我建议先开观察模式只看不拦把一周的拦截日志拉出来逐条核对确认误伤率可接受再切到拦截模式。直接开拦截然后被业务方投诉用户登不上是每年都要上演的戏码。注意源站IP必须藏住。如果源站IP曾经在历史DNS记录、证书透明度日志、邮件头、第三方监控里暴露过攻击者完全可以绕过CDN直连源站你的所有防护配置瞬间归零。接入CDN后要做的事包括源站只放行CDN回源网段的访问、换掉历史解析记录、检查代码里有没有硬编码源站IP或直连域名。3.3 效果的边界这几种情况CDN帮不了你有些问题CDN确实解决不了提前认清能省很多沟通成本。第一业务逻辑漏洞。比如优惠券可以无限领、积分可以刷、短信接口被拿来当免费网关。这些请求在HTTP层面完全合法频率也不高CDN的规则看不出来。这类问题要靠业务侧的风控设备指纹、行为序列、限流幂等解决CDN只能做粗粒度的频率兜底。第二缓存不命中时的性能问题。CDN的防护能力在命中路径上最强在回源路径上会打折。如果一个接口本身不能缓存所有请求都要穿透到源站那CDN能做的只有频率限制和连接数控制源站该扛的压力还是得扛。所以提升命中率和增强防护是同一件事的两面。第三源站自身的代码缺陷和慢查询。数据库没索引、循环里发RPC、内存泄漏这些CDN看不见也管不了。我曾见过一个站点接了三家CDN做冗余用户还是打不开最后定位是源站一个同步任务把连接池占满了。CDN是放大器源站健康度是1CDN是后面的0。第四超出协议层的攻击形态。CDN主要处理HTTP/HTTPS层的流量对更底层的流量形态需要配合其他网络层的能力这部分通常要单独和服务商确认能力边界和接入方式不能默认CDN全包。第五CDN自身的可用性风险。任何一张网都可能有局部故障。做过高可用的人一般会配置多源或多CDN但要注意多CDN会带来缓存不一致、日志割裂、配置漂移的问题不是接了就行得有一套统一切换和校验机制。4. 如何选择CDN一份可打分的选型清单市面上的CDN服务商多到让人眼花有大型云平台自带的、有专注分发的独立服务商、有做海外线路的、也有做垂直场景如点播、下载、直播的。选型不是选最强是选最匹配所以我一般先定业务类型再定权重。4.1 按业务类型定权重四类场景四种打法静态资源型站点官网、后台、文档站、H5页面。核心诉求是节点覆盖广、首字节时间稳定、缓存规则灵活。这类业务流量不大但对体验敏感重点看是否支持细粒度缓存规则、是否支持忽略query参数、是否支持HTTP/2和HTTP/3、证书管理是否方便自动续期、批量部署、控制台是否好用。价格敏感度中等。点播与大文件分发音视频、安装包、素材库。核心诉求是带宽成本和大文件回源效率。重点看大文件分片回源能力、Range请求支持、预热能力能否提前把热点文件推到边缘、预付费流量包的价格阶梯、峰值带宽计费是否可选。这类业务单价谈得好不好对总成本影响巨大我通常建议拿两三家做实际比价用量级真实数据压价。动态接口型业务电商、社交、SaaS。核心诉求是回源链路质量和动态加速能力。重点看是否有独立于公网的回源链路、是否支持协议优化长连接复用、TLS握手优化、是否支持四层/七层混合加速、边缘能否做简单的逻辑处理如Header改写、鉴权校验、A/B分流。这类业务命中率天然偏低别指望缓存省钱要指望链路省时间。强防护诉求业务有公开接口、易被刷、竞争激烈。核心诉求是防护规则的可配置性和误伤可控性。重点看频率控制维度是否够细、是否支持自定义规则表达式、是否有观察模式和拦截日志回溯、清洗能力的触发方式自动还是手动、误拦截后的申诉与白名单机制。这类场景最忌讳黑盒防护你必须能看到拦了什么、为什么拦。4.2 必问供应商的八个问题下面这张表是我每次选型都会逐条问的问完基本能筛掉一半。问题关注点不达标的表现节点覆盖和分布如何你的用户集中在哪节点是否覆盖只有几个大区节点小运营商用户绕路调度策略是什么是否动态调度、是否按运营商细化只说智能调度讲不清依据缓存规则能配多细支持按路径、后缀、参数、Header只能配后缀改规则要提工单刷新预热配额多少URL、目录、预热分开算配额极低紧急发布依赖人工回源链路是否独立是否走专线/优化链路完全走公网和直连没区别防护能力有哪些频率控制、人机校验、自定义规则只有基础的黑名单无日志日志和监控给到什么粒度是否支持实时日志、原始日志下载只有汇总图表排障时抓瞎计费项有哪些流量、请求数、HTTPS、回源流量只报流量价其他项上线后才说这八个问题里我最看重的是第六和第七。防护和可观测性属于平时看不出出事要人命的能力而这两块恰恰最难在选型阶段验证。我的做法是接入前先申请测试用真实流量跑一周同时故意制造一些异常请求高频访问一个不存在的路径、篡改参数看看日志能不能定位到、规则能不能生效。测试环境跑不出真实结论必须用真实链路。4.3 计费方式怎么选才不踩坑CDN的计费方式主流有三种按流量、按带宽峰值日峰值或月峰值、按请求数附加。选择逻辑其实很清晰。流量曲线平稳、可预测的业务按流量计费最省心用多少付多少。流量有突发、波峰波谷差异巨大的业务比如活动型电商、教育直播按带宽峰值计费更划算——因为按流量计费遇到一次大促账单会直接翻几倍。而小文件极多、流量却很小的业务小程序、API网关要特别关注请求数计费项这时候请求数成本可能占大头。还有两个容易被忽略的费用来源。一是回源流量部分服务商对回源流量单独计费命中率低的时候这部分会显著放大成本。二是海外和跨境线路单价通常是国内的好几倍如果用户分布广建议把国内和海外拆成两个加速域名、两套计费别混在一起。提示谈价之前先把自己的用量结构摸清楚——日均流量、峰值流量、日请求数、命中率、大文件占比、HTTPS占比。拿着这六个数字去谈拿到的方案和折扣会完全不一样。5. 接入实操从0到上线的一次完整走查配置这件事顺序错了会返工。我习惯按源站体检 → 基础接入 → 缓存与回源 → 灰度切量 → 观察调优这个顺序走每一步都有验收动作。5.1 接入前的源站体检别急着加域名先体检源站这一步能避免一半的上线事故。第一确认源站对CDN回源网段放行。有些源站开了IP白名单CDN回源会被直接拒绝表现为全站502。做法是先把回源网段配进白名单再测试。第二确认源站能正确处理Host和X-Forwarded-For。很多应用会根据Host做多站点路由Host配错就串站需要记录真实客户端IP的地方要从转发头里取而不是取连接IP否则日志里全是CDN节点的IP排障时完全没法用。第三确认源站支持Range请求和正确的缓存头。大文件不支持RangeCDN就没法分片回源播放器拖动进度条会卡源站如果自己发了Cache-Control: no-storeCDN通常也会遵守你以为配了缓存其实没生效。第四清理历史暴露。检查是否有子域名直接解析到源站IP、是否有第三方服务回调写死了源站地址、是否有邮件或监控平台泄露过源站信息。这一步做完再谈防护。5.2 配置顺序与灰度切量基础接入的配置顺序我建议这样先加加速域名并完成归属验证再上传或托管证书然后配回源回源地址、回源Host、回源协议、超时与重试接着配缓存规则先配排除规则再配分档TTL最后配防护规则先观察模式。顺序反过来做很容易出现缓存把错误页面缓存了这种事。验证环节不要用浏览器直接点点点了事用命令行更准# 看响应头和缓存状态字段名各家不同常见是 X-Cache 之类 curl -I https://static.example.com/app.js # 连续请求两次看第二次是否命中 curl -s -o /dev/null -w %{http_code} %{time_starttransfer}\n https://static.example.com/app.js灰度切量这一步千万别跳。做法是先用一个测试子域名指向CDN验证通过后再按DNS权重把主域名的解析逐步切过去10%、50%、100%每一档观察至少30分钟重点看5xx比例、首字节时间、回源带宽、命中率四条曲线。有条件的话按地域切先切一个用户量小的区域出问题影响面可控。回滚预案要提前写好DNS的TTL在切量前临时调小比如60秒出问题能快速切回CDN侧保留一份直连源站的备用域名关键业务准备一个静态降级页。5.3 上线后必须盯的四条曲线上线不是结束是开始。我每天必看的四个指标缓存命中率请求数和流量两个口径都要看。低于预期就先查缓存key是否被参数污染再查排除规则是否误伤了该缓存的内容。回源率与回源带宽。回源带宽突然上涨常见原因是某类内容TTL到期集中失效、或者源站发了不缓存的头、或者有异常请求在扫不存在的路径。5xx比例。CDN侧的5xx和源站的5xx要分开看前者可能是节点或配置问题后者是源站问题。混在一起看会浪费大量定位时间。首字节时间TTFB的P95和P99。平均值好看没用要盯长尾。长尾变差通常意味着某些区域的调度或回源链路出了问题。这四条曲线配合原始日志一起看基本能覆盖80%的日常问题。我把它们做成一个固定看板值班同学每天早上扫一眼比出事后救火划算得多。6. 常见问题排查实录下面这些是我这些年真实踩过或者帮忙定位过的问题按出现频率排序每条都给排查路径。6.1 命中率上不去、内容不更新、502/504命中率长期偏低。排查顺序先看请求URL是否带随机参数时间戳、随机数、session id这是头号原因再看缓存规则是否只对特定后缀生效导致JS、字体、接口全落空然后看源站响应头是否带no-cache、no-store、private最后看是否开了回源带Cookie很多CDN默认回源透传Cookie而带Cookie的请求通常不参与共享缓存。这一条改动往往能让命中率直接翻倍但很少有人第一时间想到。源站更新了用户看到的还是旧的。先确认TTL是不是设得太长再确认刷新操作是否覆盖到所有节点刷新通常有生效延迟几十秒到几分钟不等。如果文件名带hash最稳的做法是发版换文件名别依赖刷新。另外要检查浏览器本地缓存有时候CDN已经更新了是用户浏览器还存着旧的这就要靠HTML入口页短TTL加文件名版本号来解决。全站502。九成是回源配置问题回源Host错、回源端口错、源站防火墙没放行回源网段、源站证书过期回源走HTTPS时。排查方法是在源站机器上直接curl -H Host: 你的域名访问一次能通说明源站没问题问题在CDN配置不能通说明源站自身有问题。偶发504。通常是源站处理慢超过了CDN的读取超时。先看源站慢在哪慢查询、外部依赖、GC再考虑适度调大读取超时。不要用调大超时来掩盖源站性能问题那只会让雪崩来得更晚更猛。跨域报错。静态资源走CDN后域名变了跨域头必须由源站或CDN侧正确返回。注意Access-Control-Allow-Origin不能用通配符配合凭证请求也别把跨域头和缓存规则搞混——带Vary: Origin的响应要按Origin区分缓存。缓存了不该缓存的内容。这是最危险的一类。表现是用户看到别人的信息或者登录后看到未登录状态。处理方式是立刻刷新相关URL、临时关闭该路径的缓存然后回头检查缓存排除规则和缓存key配置。这类问题我建议在接入清单里做成强制项所有涉及身份、订单、支付的路径必须在接入时就列入不缓存名单并由两个人交叉复核。6.2 问题速查表现象最可能原因快速验证处理动作命中率低于50%URL带随机参数 / 回源带Cookie抽样看原始URL和请求头规范参数、关闭回源透传Cookie内容更新不及时TTL过长 / 刷新未生效对比源站与边缘响应时间戳缩短TTL、发版换文件名全站502回源Host或端口错、白名单未放行源站本地curl带Host测试修正回源配置、加白名单偶发504源站处理超时看源站慢日志和耗时分布优化源站、适度调超时大文件播放卡顿不支持Range / 分片回源未开检查响应是否206开启Range与分片回源用户串号身份相关接口被缓存检查缓存排除规则立即刷新、加排除规则防护规则误伤阈值过低 / 共用出口IP看拦截日志的来源分布调阈值、加白名单、开观察模式账单异常上涨请求数计费项 / 回源流量拆分流量与请求数账单优化命中率、调整计费方式最后分享一个我自己的习惯每次给一个站点接入CDN我都会在文档里留一页配置现状快照——记下当前的缓存规则、TTL分档、回源配置、防护阈值、计费方式以及改动的日期和原因。看起来是多此一举但当你半年后回来排一个诡异问题或者同事接手时这一页能省掉几个小时的猜测。CDN这东西配置是活的人会走文档得留下。 
长河君 · 2026/10/31 7:54:01 · 阅读 1.2k CDN实战：缓存命中率、回源链路与防护选型指南
1. 先把CDN这件事说透它到底是个什么产品这些年被问得最多的一类问题是网站明明服务器配置不低带宽也加过为什么用户还是说慢等到把CDN接进来页面打开了、视频不卡了、源站带宽曲线也降下来了于是很多人对CDN的第一印象就停在加速两个字上。这个理解不算错但太窄了——CDN内容分发网络本质上是一张铺在用户和源站之间的分布式缓存与流量调度网络加速只是它最表层的能力往下还有缓存卸载、协议优化、就近接入、流量清洗、可观测性等一整套东西。如果你只是把它当成买个加速包大概率会买贵、配错、还排不出问题。我经手过的项目里CDN踩坑最集中的不是选型而是接入之后的配置和维护缓存规则随手一填命中率长期卡在30%等于花钱买了个高级代理或者反过来把带用户身份的接口也缓存了出现A用户看到B用户数据的严重事故再或者源站IP早就暴露在外面CDN开了一堆防护却形同虚设。这些问题都不是产品能力问题是对CDN运行机制理解不到位。这篇文章想解决的就是这三件事CDN到底是什么产品、它的防护效果究竟几斤几两、以及面对市面上几十家服务商该怎么选。适合刚接手站点运维的同学、正在做技术选型的后端和架构同学也适合负责成本的产品和市场同学——毕竟CDN账单往往是基础设施里波动最大的那一项。下面的内容尽量讲人话配置示例和参数都会给出推导过程你可以直接拿去对照自己的场景。1.1 从一次打开慢说起CDN真正解决的三个问题先建立一个具体的画面。假设源站部署在某个机房一个外地用户打开你的页面浏览器要发起几十个请求HTML、CSS、JS、字体、图片、接口数据。如果全部直连源站这条链路上会发生三件麻烦事物理距离带来的往返时延、跨运营商互联带来的抖动、以及源站出口带宽被瞬时并发打满。这三件事对应CDN的三个核心价值——就近接入、链路优化、流量卸载。就近接入解决的是路远。用户请求不再千里迢迢跑到源站而是落到离他几十毫秒内的一张边缘节点上节点上有你要的文件就直接返回。链路优化解决的是路差即使必须回源CDN服务商内部通常有专线或优化链路比公网直连稳定得多。流量卸载解决的是源站扛不住命中缓存的请求根本不回源源站只承担未命中的那部分这个比例就是命中率。我习惯用一个类比源站是总仓库边缘节点是城市前置仓。前置仓有的货直接发没有的才回总仓调。总仓的发货压力取决于前置仓的备货准确度——也就是你的缓存策略。备错了前置仓全是滞销品用户要的每次都回总仓那这套前置仓体系就白建了。所以CDN的效果好不好一半看服务商一半看你自己的缓存设计这句话我在后面还会反复提。1.2 一张请求路径图拆开看调度、边缘节点与回源链路完整的一次CDN请求大体经过这么几个环节每一环都有可调参数也都是故障高发区。第一步是调度。你把自己的加速域名用CNAME指向服务商给的域名用户DNS解析时服务商的调度系统会根据用户出口IP的运营商、地理位置、节点健康状态、节点负载返回一个当下最合适的边缘节点IP。这里的差异很大有的调度只看地理距离有的会结合实时探测和节点容量做动态调整还有的做应用层调度把请求在七层再做一次分配。调度精度直接决定了就近是不是真的近。第二步是边缘节点处理。请求到达节点后节点先判断这个URL是否可缓存、缓存是否还在有效期内、缓存key是否匹配。命中则直接返回响应头里一般会带一个缓存状态标识字段名各家不同常见的是类似X-Cache: HIT/MISS这种。未命中则进入回源流程。边缘节点还会做压缩、合并、协议转换比如把HTTP/1.1的回源结果用HTTP/2或HTTP/3返回给浏览器。第三步是回源。节点向源站发起请求这里涉及回源Host、回源协议HTTP还是HTTPS、回源超时、重试次数、是否带原请求的Header。多层缓存架构里还可能先到中间层父层再回源中间层的作用是把大量边缘节点的回源请求收敛成少数几次避免源站被回源风暴打爆。回源拿到内容后节点按缓存规则落盘再返回给用户。三步之外还有一条常被忽略的旁路日志和计量。CDN的计费、命中率统计、防护拦截记录都来自这一层。如果你的业务对成本敏感一定要把这条旁路的数据拉出来看很多钱就是从这儿悄悄跑掉的。1.3 它不是一个插件而是一套分布式缓存系统把CDN当成插件的人通常会犯两个错。第一个错是认为接了CDN就快了结果源站本身慢比如数据库查询要两秒CDN再快也只能把两秒原样转发给用户——CDN只能优化传输不能优化计算。第二个错是认为接了CDN就安全了把CDN当成安全网关后面会专门讲这个边界。正确的认知是CDN是一套分布式缓存系统它的行为由缓存规则、TTL、缓存key、回源策略这几个东西共同决定而这些全是你在控制台里配的。它更像你部署在几百个城市的一层只读代理代理的行为逻辑由你定义。既然是缓存系统那么缓存系统固有的问题它全都有一致性、穿透、雪崩、碎片。一致性指的是源站内容更新后边缘上的旧副本要多久才失效穿透指的是大量请求查询不存在的资源每次都打到源站雪崩指的是某个热点缓存同时过期瞬间全量回源碎片指的是同一个内容因为URL参数不同被缓存成几百份命中率被摊薄。后面的章节会逐个讲怎么处理。2. 决定效果的核心细节缓存、调度与回源接入CDN之后最值得天天盯的指标只有一个缓存命中率。它直接决定了你的源站压力、用户的首字节时间和你的账单。但这个数字很多人看错了或者看对了却不知道该怎么改。2.1 命中率到底怎么算为什么它决定你的账单命中率有两种算法按请求数算和按流量算。按请求数算命中率 边缘命中请求数 / 总请求数按流量算命中率 边缘命中流量 / 总流量。这两个数字经常差得很远原因是大文件和小文件的分布不均匀。举个具体的例子。一个图片站点日均总流量10TB其中95%的流量来自图片但图片请求只占总请求数的20%剩下80%的请求是HTML、JS、接口这类小文件。如果图片缓存做得很好99%命中小文件几乎不缓存那么按流量算命中率可能高达94%按请求数算却只有20%出头。你在控制台看到94%觉得挺好实际上每天有数百万次请求在回源源站的连接数压力一点都不小。反过来更常见一个以接口和HTML为主的站点请求数命中率看着有80%但回源的全是大文件流量命中率只有30%源站出口带宽月月打满。所以这两个指标必须一起看缺一个都会误判。再算一笔钱。假设日均流量10TB、请求数1亿次命中率90%。命中意味着只有10%的流量和请求回源即1TB流量、1000万次回源请求。如果你的业务是大量小文件比如每个页面100个1KB左右的静态资源一天1000万PV就是10亿次请求流量却只有1TB左右10亿 × 1KB ≈ 976GB。这时候你会发现HTTPS请求数的费用可能比流量费还高。很多服务商的计费项里流量、HTTP请求数、HTTPS请求数、静态HTTPS请求数是分开计价的小文件多、请求数大的业务一定要提前测算否则第一个月账单出来会很难受。提示接入前先做一次请求数 × 平均文件大小的粗算判断自己属于流量型还是请求型业务再去看计费项能省下的往往比谈折扣多。2.2 缓存key与TTL的取舍一次真实配置的推演缓存key决定了什么算同一份内容。默认情况下绝大多数CDN把完整URL含query string作为key这意味着/img/a.png?v1和/img/a.png?v2是两份缓存。这个默认行为在小程序、前端构建工具、带时间戳防缓存的场景下会制造大量碎片。我遇到过一个典型案例前端为了保证拿到最新资源给每个静态资源请求都拼了一个?t时间戳。结果是每次请求的URL都不一样缓存永远不命中命中率接近于0所有流量全回源。改法有两种一是前端改成用文件内容hash作为版本号?va1b2c3这样版本不变key就不变二是在CDN侧配置忽略指定query参数或仅按指定参数做key。前者是治本后者是兜底我一般建议两个都做。TTL缓存有效期的设置要按内容类型分档不能一刀切。我的常用分档是这样的内容类型建议TTL理由与配套措施带hash的JS/CSS/图片/字体30天以上内容变更即换文件名长TTL无一致性风险不带hash的图片、附件1到7天配合目录刷新做兜底HTML入口页1到10分钟或协商缓存宁可短避免用户看到旧页面纯静态JSON配置5到30分钟视业务容忍度配置刷新接口用户相关接口不缓存用规则明确排除防串号公共只读接口如城市列表30秒到5分钟必须配按key区分的缓存key这里有个必须说清的风险带用户身份的内容绝不能进共享缓存。判断标准很简单——响应内容是否随Cookie、Authorization、用户ID变化。如果是要么不缓存要么配置按指定Header或Cookie做缓存key让它变成多份隔离缓存。这一条出问题就不是性能问题是数据泄露事故。我在评审配置时第一眼看的永远是缓存排除规则里有没有把登录态接口、订单接口、个人中心接口列进去。还有一个细节TTL不是越长越好。长TTL的代价是内容更新不及时必须靠主动刷新。而刷新是有配额的URL刷新和目录刷新各有次数限制紧急发布时经常不够用。所以长TTL的前提是文件名带版本而不是靠刷新续命。2.3 调度精度与回源链路才是加速体感的分水岭缓存规则配好了用户还是觉得偶尔卡一下问题常常出在调度和回源。调度这块判断标准是同一个用户连续几次解析落到的是不是同一个区域、同一批节点。如果每次落到很远的节点或者频繁在节点间跳变用户体验就是忽快忽慢。测试方法很土但有效在几个不同运营商、不同区域的机器上反复解析你的加速域名看返回的IP归属和往返时延再看是否稳定。更靠谱的做法是看服务商是否提供节点分布和调度策略的说明以及是否支持按运营商、按区域的精细调度。回源链路这块重点看三个配置。第一是回源Host很多源站部署了多个站点Host配错会直接返回404或者串站这是接入首日最常见的故障。第二是回源协议如果源站支持HTTPS建议回源也走HTTPS否则中间链路上是明文。第三是超时和重试连接超时通常设3到5秒读取超时按业务设10到30秒重试次数设1到2次就够——重试次数设太多源站一旦抖动会形成重试风暴把小抖动放大成大故障。另外多层缓存中间层/父层这个能力流量规模上去以后一定要开。它把几百个边缘节点的回源请求收敛成几十次源站看到的并发会下降一个数量级。代价是多一跳首字节时间可能增加几十毫秒对静态资源完全值得对时延敏感的动态接口要单独评估。3. CDN防护效果到底怎么样能挡住什么挡不住什么先给结论CDN的防护是真实有效的但它的有效性高度依赖缓存有没有帮你挡在前面以及你的源站有没有藏好。把它当成万能盾牌一定会失望把它当成第一层过滤网用对了收益很大。3.1 防护的底层逻辑把集中压力摊到分布式边缘CDN能做防护本质上靠两件事分散和过滤。分散是指原本所有流量都砸向源站一个出口现在被摊到几百个节点上。单节点的处理能力和带宽是有限的但整体容量是源站的很多倍。恶意流量打到CDN上先被这张网稀释能在边缘消化掉的就消化掉了不会形成对源站出口的集中冲击。这也是为什么CDN接入后源站带宽曲线会突然变得很平滑。过滤是指边缘节点在七层上能看到每一个请求的URL、Header、参数、频率可以在返回内容之前做判断这个IP一秒发了几百次请求拦掉这个请求的特征明显不像正常浏览器给个人机校验这个URL参数超长或者包含明显的注入特征拒绝这个来源在短时间内扫了大量不存在的路径拉黑一段时间。这些动作都在边缘完成源站根本不感知。所以防护效果好坏取决于两个前提一是流量确实经过CDN源站IP没暴露二是规则确实匹配你的业务不是开了个默认策略就不管。第二点后面单独说。3.2 分层防护的实际做法限速、人机校验、缓存挡刀我把CDN侧的防护配置分成三层按成本从低到高排列。第一层是缓存挡刀成本最低、效果最直接。大量异常请求的特征是重复访问同一个或少数几个URL比如反复请求首页、反复请求某个搜索接口。如果这些URL本身可缓存请求在边缘就被拦下了根本不会形成回源压力。所以把该缓存的缓存好这件事本身就是一个防护动作而且不花钱。反过来说如果你的站点命中率很低防护成本会成倍上升——因为每个异常请求都要消耗回源资源。第二层是频率限制。按IP、按URL、按Header维度设置阈值比如单IP对同一URL的请求超过每秒20次就限速或返回一个挑战页。这里的难点是阈值怎么定。我的做法是先跑一周观察把正常用户的P99峰值拉出来阈值设在P99的3到5倍留足余量。阈值设太低会误伤正常用户尤其是共用出口IP的企业网络和移动网络NAT场景设太高等于没设。另外要注意限速规则要能按URL路径差异化登录、下单这类关键接口阈值要严图片、静态资源可以宽。第三层是人机校验和精细化规则。对疑似异常的会话弹一个轻量的JS挑战正常浏览器能自动通过脚本化的请求过不去。再加上地理位置、User-Agent特征、Referer校验这些规则做组合判断。这一层的能力各家差异最大也是选型时最该实际测试的部分。配置顺序上我建议先开观察模式只看不拦把一周的拦截日志拉出来逐条核对确认误伤率可接受再切到拦截模式。直接开拦截然后被业务方投诉用户登不上是每年都要上演的戏码。注意源站IP必须藏住。如果源站IP曾经在历史DNS记录、证书透明度日志、邮件头、第三方监控里暴露过攻击者完全可以绕过CDN直连源站你的所有防护配置瞬间归零。接入CDN后要做的事包括源站只放行CDN回源网段的访问、换掉历史解析记录、检查代码里有没有硬编码源站IP或直连域名。3.3 效果的边界这几种情况CDN帮不了你有些问题CDN确实解决不了提前认清能省很多沟通成本。第一业务逻辑漏洞。比如优惠券可以无限领、积分可以刷、短信接口被拿来当免费网关。这些请求在HTTP层面完全合法频率也不高CDN的规则看不出来。这类问题要靠业务侧的风控设备指纹、行为序列、限流幂等解决CDN只能做粗粒度的频率兜底。第二缓存不命中时的性能问题。CDN的防护能力在命中路径上最强在回源路径上会打折。如果一个接口本身不能缓存所有请求都要穿透到源站那CDN能做的只有频率限制和连接数控制源站该扛的压力还是得扛。所以提升命中率和增强防护是同一件事的两面。第三源站自身的代码缺陷和慢查询。数据库没索引、循环里发RPC、内存泄漏这些CDN看不见也管不了。我曾见过一个站点接了三家CDN做冗余用户还是打不开最后定位是源站一个同步任务把连接池占满了。CDN是放大器源站健康度是1CDN是后面的0。第四超出协议层的攻击形态。CDN主要处理HTTP/HTTPS层的流量对更底层的流量形态需要配合其他网络层的能力这部分通常要单独和服务商确认能力边界和接入方式不能默认CDN全包。第五CDN自身的可用性风险。任何一张网都可能有局部故障。做过高可用的人一般会配置多源或多CDN但要注意多CDN会带来缓存不一致、日志割裂、配置漂移的问题不是接了就行得有一套统一切换和校验机制。4. 如何选择CDN一份可打分的选型清单市面上的CDN服务商多到让人眼花有大型云平台自带的、有专注分发的独立服务商、有做海外线路的、也有做垂直场景如点播、下载、直播的。选型不是选最强是选最匹配所以我一般先定业务类型再定权重。4.1 按业务类型定权重四类场景四种打法静态资源型站点官网、后台、文档站、H5页面。核心诉求是节点覆盖广、首字节时间稳定、缓存规则灵活。这类业务流量不大但对体验敏感重点看是否支持细粒度缓存规则、是否支持忽略query参数、是否支持HTTP/2和HTTP/3、证书管理是否方便自动续期、批量部署、控制台是否好用。价格敏感度中等。点播与大文件分发音视频、安装包、素材库。核心诉求是带宽成本和大文件回源效率。重点看大文件分片回源能力、Range请求支持、预热能力能否提前把热点文件推到边缘、预付费流量包的价格阶梯、峰值带宽计费是否可选。这类业务单价谈得好不好对总成本影响巨大我通常建议拿两三家做实际比价用量级真实数据压价。动态接口型业务电商、社交、SaaS。核心诉求是回源链路质量和动态加速能力。重点看是否有独立于公网的回源链路、是否支持协议优化长连接复用、TLS握手优化、是否支持四层/七层混合加速、边缘能否做简单的逻辑处理如Header改写、鉴权校验、A/B分流。这类业务命中率天然偏低别指望缓存省钱要指望链路省时间。强防护诉求业务有公开接口、易被刷、竞争激烈。核心诉求是防护规则的可配置性和误伤可控性。重点看频率控制维度是否够细、是否支持自定义规则表达式、是否有观察模式和拦截日志回溯、清洗能力的触发方式自动还是手动、误拦截后的申诉与白名单机制。这类场景最忌讳黑盒防护你必须能看到拦了什么、为什么拦。4.2 必问供应商的八个问题下面这张表是我每次选型都会逐条问的问完基本能筛掉一半。问题关注点不达标的表现节点覆盖和分布如何你的用户集中在哪节点是否覆盖只有几个大区节点小运营商用户绕路调度策略是什么是否动态调度、是否按运营商细化只说智能调度讲不清依据缓存规则能配多细支持按路径、后缀、参数、Header只能配后缀改规则要提工单刷新预热配额多少URL、目录、预热分开算配额极低紧急发布依赖人工回源链路是否独立是否走专线/优化链路完全走公网和直连没区别防护能力有哪些频率控制、人机校验、自定义规则只有基础的黑名单无日志日志和监控给到什么粒度是否支持实时日志、原始日志下载只有汇总图表排障时抓瞎计费项有哪些流量、请求数、HTTPS、回源流量只报流量价其他项上线后才说这八个问题里我最看重的是第六和第七。防护和可观测性属于平时看不出出事要人命的能力而这两块恰恰最难在选型阶段验证。我的做法是接入前先申请测试用真实流量跑一周同时故意制造一些异常请求高频访问一个不存在的路径、篡改参数看看日志能不能定位到、规则能不能生效。测试环境跑不出真实结论必须用真实链路。4.3 计费方式怎么选才不踩坑CDN的计费方式主流有三种按流量、按带宽峰值日峰值或月峰值、按请求数附加。选择逻辑其实很清晰。流量曲线平稳、可预测的业务按流量计费最省心用多少付多少。流量有突发、波峰波谷差异巨大的业务比如活动型电商、教育直播按带宽峰值计费更划算——因为按流量计费遇到一次大促账单会直接翻几倍。而小文件极多、流量却很小的业务小程序、API网关要特别关注请求数计费项这时候请求数成本可能占大头。还有两个容易被忽略的费用来源。一是回源流量部分服务商对回源流量单独计费命中率低的时候这部分会显著放大成本。二是海外和跨境线路单价通常是国内的好几倍如果用户分布广建议把国内和海外拆成两个加速域名、两套计费别混在一起。提示谈价之前先把自己的用量结构摸清楚——日均流量、峰值流量、日请求数、命中率、大文件占比、HTTPS占比。拿着这六个数字去谈拿到的方案和折扣会完全不一样。5. 接入实操从0到上线的一次完整走查配置这件事顺序错了会返工。我习惯按源站体检 → 基础接入 → 缓存与回源 → 灰度切量 → 观察调优这个顺序走每一步都有验收动作。5.1 接入前的源站体检别急着加域名先体检源站这一步能避免一半的上线事故。第一确认源站对CDN回源网段放行。有些源站开了IP白名单CDN回源会被直接拒绝表现为全站502。做法是先把回源网段配进白名单再测试。第二确认源站能正确处理Host和X-Forwarded-For。很多应用会根据Host做多站点路由Host配错就串站需要记录真实客户端IP的地方要从转发头里取而不是取连接IP否则日志里全是CDN节点的IP排障时完全没法用。第三确认源站支持Range请求和正确的缓存头。大文件不支持RangeCDN就没法分片回源播放器拖动进度条会卡源站如果自己发了Cache-Control: no-storeCDN通常也会遵守你以为配了缓存其实没生效。第四清理历史暴露。检查是否有子域名直接解析到源站IP、是否有第三方服务回调写死了源站地址、是否有邮件或监控平台泄露过源站信息。这一步做完再谈防护。5.2 配置顺序与灰度切量基础接入的配置顺序我建议这样先加加速域名并完成归属验证再上传或托管证书然后配回源回源地址、回源Host、回源协议、超时与重试接着配缓存规则先配排除规则再配分档TTL最后配防护规则先观察模式。顺序反过来做很容易出现缓存把错误页面缓存了这种事。验证环节不要用浏览器直接点点点了事用命令行更准# 看响应头和缓存状态字段名各家不同常见是 X-Cache 之类 curl -I https://static.example.com/app.js # 连续请求两次看第二次是否命中 curl -s -o /dev/null -w %{http_code} %{time_starttransfer}\n https://static.example.com/app.js灰度切量这一步千万别跳。做法是先用一个测试子域名指向CDN验证通过后再按DNS权重把主域名的解析逐步切过去10%、50%、100%每一档观察至少30分钟重点看5xx比例、首字节时间、回源带宽、命中率四条曲线。有条件的话按地域切先切一个用户量小的区域出问题影响面可控。回滚预案要提前写好DNS的TTL在切量前临时调小比如60秒出问题能快速切回CDN侧保留一份直连源站的备用域名关键业务准备一个静态降级页。5.3 上线后必须盯的四条曲线上线不是结束是开始。我每天必看的四个指标缓存命中率请求数和流量两个口径都要看。低于预期就先查缓存key是否被参数污染再查排除规则是否误伤了该缓存的内容。回源率与回源带宽。回源带宽突然上涨常见原因是某类内容TTL到期集中失效、或者源站发了不缓存的头、或者有异常请求在扫不存在的路径。5xx比例。CDN侧的5xx和源站的5xx要分开看前者可能是节点或配置问题后者是源站问题。混在一起看会浪费大量定位时间。首字节时间TTFB的P95和P99。平均值好看没用要盯长尾。长尾变差通常意味着某些区域的调度或回源链路出了问题。这四条曲线配合原始日志一起看基本能覆盖80%的日常问题。我把它们做成一个固定看板值班同学每天早上扫一眼比出事后救火划算得多。6. 常见问题排查实录下面这些是我这些年真实踩过或者帮忙定位过的问题按出现频率排序每条都给排查路径。6.1 命中率上不去、内容不更新、502/504命中率长期偏低。排查顺序先看请求URL是否带随机参数时间戳、随机数、session id这是头号原因再看缓存规则是否只对特定后缀生效导致JS、字体、接口全落空然后看源站响应头是否带no-cache、no-store、private最后看是否开了回源带Cookie很多CDN默认回源透传Cookie而带Cookie的请求通常不参与共享缓存。这一条改动往往能让命中率直接翻倍但很少有人第一时间想到。源站更新了用户看到的还是旧的。先确认TTL是不是设得太长再确认刷新操作是否覆盖到所有节点刷新通常有生效延迟几十秒到几分钟不等。如果文件名带hash最稳的做法是发版换文件名别依赖刷新。另外要检查浏览器本地缓存有时候CDN已经更新了是用户浏览器还存着旧的这就要靠HTML入口页短TTL加文件名版本号来解决。全站502。九成是回源配置问题回源Host错、回源端口错、源站防火墙没放行回源网段、源站证书过期回源走HTTPS时。排查方法是在源站机器上直接curl -H Host: 你的域名访问一次能通说明源站没问题问题在CDN配置不能通说明源站自身有问题。偶发504。通常是源站处理慢超过了CDN的读取超时。先看源站慢在哪慢查询、外部依赖、GC再考虑适度调大读取超时。不要用调大超时来掩盖源站性能问题那只会让雪崩来得更晚更猛。跨域报错。静态资源走CDN后域名变了跨域头必须由源站或CDN侧正确返回。注意Access-Control-Allow-Origin不能用通配符配合凭证请求也别把跨域头和缓存规则搞混——带Vary: Origin的响应要按Origin区分缓存。缓存了不该缓存的内容。这是最危险的一类。表现是用户看到别人的信息或者登录后看到未登录状态。处理方式是立刻刷新相关URL、临时关闭该路径的缓存然后回头检查缓存排除规则和缓存key配置。这类问题我建议在接入清单里做成强制项所有涉及身份、订单、支付的路径必须在接入时就列入不缓存名单并由两个人交叉复核。6.2 问题速查表现象最可能原因快速验证处理动作命中率低于50%URL带随机参数 / 回源带Cookie抽样看原始URL和请求头规范参数、关闭回源透传Cookie内容更新不及时TTL过长 / 刷新未生效对比源站与边缘响应时间戳缩短TTL、发版换文件名全站502回源Host或端口错、白名单未放行源站本地curl带Host测试修正回源配置、加白名单偶发504源站处理超时看源站慢日志和耗时分布优化源站、适度调超时大文件播放卡顿不支持Range / 分片回源未开检查响应是否206开启Range与分片回源用户串号身份相关接口被缓存检查缓存排除规则立即刷新、加排除规则防护规则误伤阈值过低 / 共用出口IP看拦截日志的来源分布调阈值、加白名单、开观察模式账单异常上涨请求数计费项 / 回源流量拆分流量与请求数账单优化命中率、调整计费方式最后分享一个我自己的习惯每次给一个站点接入CDN我都会在文档里留一页配置现状快照——记下当前的缓存规则、TTL分档、回源配置、防护阈值、计费方式以及改动的日期和原因。看起来是多此一举但当你半年后回来排一个诡异问题或者同事接手时这一页能省掉几个小时的猜测。CDN这东西配置是活的人会走文档得留下。