中转业务CDN接入，动态API接口CDN缓存规则避坑

中转业务接入CDN后，动态API接口如果被默认缓存规则命中，很容易出现用户数据不更新、登录态失效、接口响应异常等问题。
这不是CDN本身有故障，而是没有按动态接口的特性去设置缓存规则。
本文面向把中转服务接入CDN的新手运维，从配置前准备、规则设置、避坑到验证，给出可以直接套用的做法。

接入前先分清哪些请求必须“不缓存”

中转业务的典型路径是 /api/ 开头的动态转发接口，以及前端所需的 js/css/png 等静态资源。
前者每次请求都可能携带不同参数或用户身份信息，一旦被缓存就会造成串数据；
后者内容固定，适合长时间缓存。
所以配置的第一原则是：动态接口一律不缓存，静态资源单独加缓存策略。
建议把业务路径按前缀或后缀区分开，比如将 /api/、/callback 明确设置为不缓存。

在CDN控制台配置动态接口不缓存

登录你的CDN服务商控制台，找到“缓存规则”或“缓存配置”菜单。
添加规则时，路径匹配选择“前缀匹配”，填写 /api/，缓存操作选择“不缓存”或“绕过缓存”；
如果服务商支持类型选择，建议选择“全部”。
然后再添加一条规则用于静态资源，路径填写 *.jpg;*.js;*.css;*.png;*.woff2，缓存时间可设置为30天。
不同服务商的字段名称略有差异，但原理一致：命中不缓存规则的请求，CDN会直接回源访问，不会保存响应结果。

以常见的阿里云CDN/腾讯云CDN为例，操作路径大致如下：

• 阿里云：域名管理 → 缓存配置 → 添加缓存规则
• 腾讯云：域名管理 → 缓存配置 → 新增规则

如果你的中转服务使用了多个动态路径，比如 /v1/、/openapi/，就分别添加多条不缓存规则，避免遗漏导致部分接口被缓存。

避坑：这些细节最容易导致动态接口被缓存

即使添加了“不缓存”规则，实际运行中还是可能踩到下面这几个坑。

• 缓存优先级设置错误：部分CDN平台的“缓存”与“不缓存”规则存在优先级差异，需要把“不缓存”规则的优先级调高，否则会被全站缓存规则覆盖。
• POST请求被意外缓存：多数CDN只会缓存GET请求，但部分平台对带参数的POST也有缓存逻辑。建议规则中明确只放行GET动态请求，或直接对整条动态路径设置不缓存。
• 查询参数影响缓存键：如果接口使用 ?from=app&id=123，CDN默认可能只按基础路径做缓存导致不同用户命中同一份缓存。开启“保留所有参数”或不缓存相关路径可避免此类问题。
• 回源Host不一致：配置CDN后，源站会收到来自CDN节点的回源请求，如果回源Host解析到了错误站点，接口会返回403或404。确认回源地址、回源Host和源站Nginx或应用网关的配置保持一致。

验证缓存规则是否生效

配置完成后先别急着全量上线，建议做两步验证。

第一步，在本地命令行用 curl 查看响应头：

curl -I "https://你的域名/api/user?id=1"

观察返回的 X-Cache 或 Via 字段。
如果是 MISS 或没有 HIT，说明请求回源，没有被缓存；
若显示 HIT，说明规则没生效，需要重新检查优先级和路径匹配。

第二步，用两个不同参数请求同一个接口，例如 /api/user?
id=1 和 /api/user?
id=2，确认两次返回内容都来自源站且数据正确。
同时修改源站对应返回值，再请求一次，看变化是否实时出现。
如果修改后立即生效，说明动态接口没有被CDN缓存。

常见疑问：为什么设置了不缓存还是出现旧数据

这类问题绝大多数是缓存规则没有覆盖完整路径，比如只写了 /api/，而业务实际路径是 /api/v1/getUser；
或者CDN边缘节点上层的浏览器缓存、本地DNS缓存没有刷新。
建议在源站响应头里强制增加 Cache-Control: no-store，并确认CDN在“不缓存”模式下是否透传该字段。
另外，可以关注CDN控制台中的请求命中率，如果命中率异常升高，说明动态接口可能被误缓存，需要再次检查规则配置。

按上面的规则配置后，中转业务的动态接口可以保持直连源站，静态资源也能正常使用CDN加速。
实际操作中，每个CDN平台的界面和参数名会略有差异，建议以你正在使用的CDN控制台当前显示为准。
如果之后遇到回源超时或缓存未生效，优先从规则优先级、路径匹配、回源Host三个方面排查。