引言

CDN配了，域名接了，CNAME也指向了——可用户访问的依然是旧内容，缓存命中率低得可怜，回源流量居高不下。这大概是每一个运维工程师都曾遭遇过的至暗时刻。据行业统计，超过六成的CDN性能问题并非源于网络或硬件，而是缓存策略配置失当。缓存不生效，本质上是CDN"不知道该缓存什么、该缓存多久、什么时候该更新"这三个核心问题没有被正确回答。天翼云CDN提供了从Cache Key规则、缓存过期时间到多级刷新机制的完整配置链条，但如果不理解每一层配置背后的逻辑，再强大的工具也只是摆设。本文将从Cache Key配置、缓存策略优化、刷新机制三大维度，逐层拆解天翼云CDN缓存不生效的根因与解法，让你的CDN真正"缓存得住、命中得了、更新得快"。

一、Cache Key配置：缓存的"身份证"决定了一切

1.1 什么是Cache Key？为什么它是缓存的命脉？

CDN节点缓存资源时，需要一个唯一标识来区分不同的文件——这个标识就是Cache Key。默认情况下，天翼云CDN以客户端请求的完整URL（含问号后参数）作为Cache Key。这意味着，哪怕两个URL只差一个参数值，CDN也会视为两份完全不同的资源，分别缓存、分别回源。

举个最典型的场景：用户访问/images/banner.jpg?v=1和/images/banner.jpg?v=2，如果Cache Key包含参数，CDN会缓存两份内容；但实际上这两个请求返回的是同一张图片。结果就是缓存命中率暴跌，回源量飙升。

1.2 四种Cache Key规则，场景各不同

天翼云CDN提供了四种忽略参数的配置模式，适用场景截然不同：

第一种：不忽略参数。 保留URL中所有参数作为Cache Key。适用于参数真正影响返回内容的场景，例如/api/data?version=1和/api/data?version=2返回不同数据，此时必须选择不忽略，否则会出现严重的数据错乱。

第二种：全部忽略。 去掉问号后所有参数，仅以问号前的URL作为Cache Key。最适合音视频点播场景——URL中携带的时间戳签名参数（如?sign=XXXXXX）仅用于访问认证，不影响文件内容本身。全部忽略后，无论签名如何变化，CDN只缓存一份资源，命中率直接拉满。

第三种：保留指定参数。 仅保留对内容有影响的参数作为Cache Key，忽略其余参数。例如/images/1.jpg?version=1&time=1651752741和/images/1.jpg?version=1&time=1651752742，version影响图片内容需保留，time不影响则忽略。配置后，version相同的请求共用一份缓存，time参数的变化不再导致缓存分裂。

第四种：忽略指定参数。 与保留指定参数相反，明确列出需要忽略的参数。适用于参数种类可能动态增加的场景——新增的参数自动被忽略，无需反复修改规则。

1.3 配置路径与注意事项

登录天翼云CDN控制台，进入【域名管理】-【域名列表】，点击目标域名的【编辑】，在【缓存配置】-【缓存参数】模块中增加规则。规则类型可选后缀名、目录、首页、全部文件、全路径文件，内容填写具体的文件后缀或路径。权重数字越大优先级越高，当同一URL命中多条规则时，以权重高的为准。

关键提醒： Cache Key一旦配置生效，不建议轻易变动。变更Cache Key会导致原有缓存全部失效，瞬间产生大量回源，可能直接压垮源站。如确需变更，务必选择业务低峰期操作，并做好回源保护。

二、缓存策略：TTL设置不对，一切白费

2.1 缓存过期时间（TTL）的三大误区

误区一：TTL设置过短。 比如把图片缓存时间设为10秒或1分钟，CDN节点刚缓存完就过期了，每次请求都要回源。看似"不缓存"，实则是缓存频繁失效，既没加速效果，还白白增加源站压力。

误区二：TTL设置过长。 比如把所有文件都设为7天甚至30天，源站内容更新后，CDN节点的旧缓存还没过期，用户持续看到旧内容。这是"改了图片还是显示旧的"最常见的原因。

误区三：忽视源站响应头的优先级。 天翼云CDN默认遵循源站缓存头策略，优先级从高到低依次为：Pragma: no-cache > Cache-Control: no-cache/private/no-store > Cache-Control: max-age=n > Expires。如果源站返回了Cache-Control: no-cache，而你在CDN控制台设置了7天缓存，CDN依然不会缓存——因为源站的指令优先级更高。

2.2 合理的TTL配置建议

根据天翼云官方推荐与实际运营经验，不同类型资源的TTL应差异化设置：

在CDN控制台的【缓存配置】-【缓存过期时间】模块中，可按文件后缀、目录、首页等维度分别设置规则。缓存规则支持"强制缓存"和"优先遵循源站"两种模式。选择"强制缓存"后，即使源站返回不缓存头，CDN仍按预设规则缓存；选择"不缓存"则无论源站如何响应，CDN节点均不缓存该文件。

2.3 去问号缓存：提升命中率的隐藏开关

天翼云CDN默认开启"去问号缓存"功能。开启后，/1.txt?test1和/1.txt?test2会被视为同一份资源，命中同一份缓存。这对于参数不影响内容的场景（如统计追踪参数、时间戳）效果显著。

但需要注意：如果URL参数确实影响返回内容（如版本号区分不同文件），则必须关闭去问号缓存或选择"不忽略参数"，否则会出现严重的内容混淆。

三、刷新机制：内容更新后，如何让CDN"知道"？

CDN的缓存是"被动更新"——只有缓存过期或主动触发刷新，节点才会回源获取最新内容。源站更新后，如果不主动刷新，用户看到的永远是旧版本。天翼云CDN提供了三种刷新方式，机制各有不同。

3.1 URL刷新：精准打击，立即生效

输入完整URL（如https://www.example.com/images/new-banner.jpg），CDN节点直接删除该URL对应的缓存内容。用户下次请求时，节点回源获取最新文件并重新缓存。

适用场景： 更新了单个或少数几个文件，需要立即生效。

限制： 每账号每日最多10000条URL刷新。注意URL大小写必须与实际访问完全一致，错误的大小写会导致刷新无效。

3.2 目录刷新：批量清除，智能校验

输入目录路径（如https://www.example.com/images/，必须以/结尾），该目录下所有文件的缓存被标记为"过期状态"。用户请求时，CDN节点携带If-Modified-Since或If-None-Match请求头回源校验：源站返回304说明内容未变，节点继续使用旧缓存；返回200或206说明内容已更新，节点拉取新内容并缓存。

适用场景： 更新了整个目录下的多个文件，如全站改版、CSS框架升级。

优势： 相比URL刷新的"一刀切删除"，目录刷新会先校验再决定是否拉取，避免不必要的回源流量。

限制： 每账号每日最多100条目录刷新。根目录刷新（如/）默认不支持，因风险过高，如确需执行须通过工单提交。

3.3 正则刷新：模糊匹配，灵活高效

输入正则表达式（如https://www.example.com/[0-9][a-z].*.png），匹配所有符合规则的URL进行刷新。目前支持四种正则语法：[0-9]、[a-z]、[^/]*、.*。

适用场景： 需要刷新一批符合某种命名规律的文件，如所有a1.png、b2.png这类哈希命名的资源。

限制： 每账号每日最多10条正则刷新（单域名限额）。

3.4 刷新任务的最佳实践

大批量刷新会引发高并发回源，若源站出口带宽较小，建议分多次小批量操作。每条刷新任务一般5-10分钟生效。刷新功能会降低缓存命中率，因此不应作为常态化更新手段，而应作为"源站更新后的补救措施"。

真正的长效方案是配合预取功能——在内容正式发布前，通过URL预取将热门资源提前缓存到CDN节点。用户首次访问时直接命中缓存，既提升命中率，又大幅降低源站压力。预取任务提交路径为CDN控制台【刷新预取】-【URL预取】。

四、缓存不生效的六大隐形杀手与排查清单

即使配置都对了，以下六个问题仍可能让缓存形同虚设：

写在最后

CDN缓存不是"配完就完"的一次性操作，而是一套需要持续调优的动态系统。Cache Key决定了"缓存什么"，TTL决定了"缓存多久"，刷新机制决定了"什么时候更新"——三者缺一不可，任何一环失控，整个缓存体系就会崩盘。

从今天起，打开你的天翼云CDN控制台，逐项检查：Cache Key规则是否与业务场景匹配？TTL设置是否按资源类型做了差异化？源站更新后是否执行了刷新？低频资源是否用了预取保护？这四个问题的答案，决定了你的CDN是"真加速"还是"假缓存"。