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?v=1和/img/a.png?v=2是两份缓存。这个默认行为在小程序、前端构建工具、带时间戳防缓存的场景下会制造大量碎片。

我遇到过一个典型案例：前端为了"保证拿到最新资源"，给每个静态资源请求都拼了一个?t=时间戳。结果是每次请求的URL都不一样，缓存永远不命中，命中率接近于0，所有流量全回源。改法有两种：一是前端改成用文件内容hash作为版本号（?v=a1b2c3），这样版本不变key就不变；二是在CDN侧配置"忽略指定query参数"或"仅按指定参数做key"。前者是治本，后者是兜底，我一般建议两个都做。

TTL（缓存有效期）的设置要按内容类型分档，不能一刀切。我的常用分档是这样的：

这里有个必须说清的风险：带用户身份的内容绝不能进共享缓存。判断标准很简单——响应内容是否随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是放大器，源站健康度是1，CDN是后面的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 必问供应商的八个问题

下面这张表是我每次选型都会逐条问的，问完基本能筛掉一半。

这八个问题里，我最看重的是第六和第七。防护和可观测性属于"平时看不出，出事要人命"的能力，而这两块恰恰最难在选型阶段验证。我的做法是：接入前先申请测试，用真实流量跑一周，同时故意制造一些异常请求（高频访问一个不存在的路径、篡改参数），看看日志能不能定位到、规则能不能生效。测试环境跑不出真实结论，必须用真实链路。

4.3 计费方式怎么选才不踩坑

CDN的计费方式主流有三种：按流量、按带宽峰值（日峰值或月峰值）、按请求数附加。选择逻辑其实很清晰。

流量曲线平稳、可预测的业务，按流量计费最省心，用多少付多少。流量有突发、波峰波谷差异巨大的业务（比如活动型电商、教育直播），按带宽峰值计费更划算——因为按流量计费遇到一次大促，账单会直接翻几倍。而小文件极多、流量却很小的业务（小程序、API网关），要特别关注请求数计费项，这时候请求数成本可能占大头。

还有两个容易被忽略的费用来源。一是回源流量，部分服务商对回源流量单独计费，命中率低的时候这部分会显著放大成本。二是海外和跨境线路，单价通常是国内的好几倍，如果用户分布广，建议把国内和海外拆成两个加速域名、两套计费，别混在一起。

提示：谈价之前先把自己的用量结构摸清楚——日均流量、峰值流量、日请求数、命中率、大文件占比、HTTPS占比。拿着这六个数字去谈，拿到的方案和折扣会完全不一样。

5. 接入实操：从0到上线的一次完整走查

配置这件事，顺序错了会返工。我习惯按"源站体检 → 基础接入 → 缓存与回源 → 灰度切量 → 观察调优"这个顺序走，每一步都有验收动作。

5.1 接入前的源站体检

别急着加域名，先体检源站，这一步能避免一半的上线事故。

第一，确认源站对CDN回源网段放行。有些源站开了IP白名单，CDN回源会被直接拒绝，表现为全站502。做法是先把回源网段配进白名单，再测试。

第二，确认源站能正确处理Host和X-Forwarded-For。很多应用会根据Host做多站点路由，Host配错就串站；需要记录真实客户端IP的地方，要从转发头里取，而不是取连接IP，否则日志里全是CDN节点的IP，排障时完全没法用。

第三，确认源站支持Range请求和正确的缓存头。大文件不支持Range，CDN就没法分片回源，播放器拖动进度条会卡；源站如果自己发了Cache-Control: no-store，CDN通常也会遵守，你以为配了缓存其实没生效。

第四，清理历史暴露。检查是否有子域名直接解析到源站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 问题速查表

最后分享一个我自己的习惯：每次给一个站点接入CDN，我都会在文档里留一页"配置现状快照"——记下当前的缓存规则、TTL分档、回源配置、防护阈值、计费方式，以及改动的日期和原因。看起来是多此一举，但当你半年后回来排一个诡异问题，或者同事接手时，这一页能省掉几个小时的猜测。CDN这东西，配置是活的，人会走，文档得留下。