缓存是高防CDN在攻击期间保护源站的核心机制之一。缓存命中率越高，回源请求越少，源站承受的压力越小。但缓存规则配置不当会带来两个极端问题：该缓存的内容没有缓存，源站被回源请求压垮；不该缓存的内容被缓存了，用户看到过期数据或敏感信息泄露。
本文拆解高防CDN缓存规则的配置原则，说明哪些资源应该缓存、哪些必须回源。
一、静态资源：默认缓存，设置长TTL
静态资源是高防CDN缓存的首选对象。图片、CSS、JS、字体文件、视频切片这些资源的内容不随用户请求变化，缓存命中率可以做到90%以上。
配置静态资源缓存时，核心是设置合理的TTL（生存时间）。TTL决定了边缘节点缓存内容的有效期。TTL太短，缓存频繁过期，回源压力大；TTL太长，源站更新内容后用户长时间看到旧版本。行业实践中，静态资源的TTL通常设置为7–30天。
对于需要频繁更新的静态资源（如JS、CSS），推荐使用文件名哈希的方式管理版本。每次更新资源时，文件名中的哈希值变化，URL随之变化，边缘节点会将其视为新资源重新缓存。这样既保证了TTL可以设置得很长，又不会出现用户看到旧版本的问题。
二、动态接口：不缓存，但优化回源路径
API接口、用户登录、订单提交、支付回调这类动态请求，内容随用户和请求参数变化，不能被缓存。它们必须回源到源站处理。
但动态请求不缓存，不意味着不能优化。优化重点在于减少每次回源的连接开销。边缘节点与源站之间维护长连接池，动态请求复用已有的连接回源，避免每次请求都新建TCP连接。这与高防CDN动态内容加速中提到的连接复用机制是同一套逻辑。
对于部分可以容忍短暂数据延迟的动态接口，可以采用短TTL缓存。例如商品列表接口，缓存5–10秒可以有效削峰，同时数据延迟在可接受范围内。配置时需要根据业务对数据实时性的要求判断，不能一刀切。
三、敏感数据：禁止缓存，配置例外规则
用户个人信息、订单详情、支付页面、后台管理接口这类敏感数据，必须禁止缓存。一旦被CDN缓存，可能被其他用户访问到，造成数据泄露。
禁止缓存的方式包括：在源站响应头中设置Cache-Control: no-store，或在CDN配置中为特定路径设置不缓存规则。对于同时包含敏感和非敏感内容的页面，可以配置例外规则——整体缓存，但对包含用户信息的接口单独设置不缓存。
需要特别注意的是Cookie和Authorization头。携带这些认证信息的请求，响应内容通常与用户身份相关，不应被缓存。CDN在配置缓存规则时，应当将携带认证信息的请求排除在缓存范围之外。
| 资源类型 | 缓存策略 | TTL建议 | 注意事项 |
|---|---|---|---|
| 静态资源（图片/JS/CSS） | 默认缓存 | 7–30天 | 文件名哈希管理版本 |
| 视频切片 | 默认缓存 | 7–30天 | 大文件，注意存储成本 |
| 动态接口（API） | 不缓存，优化回源 | — | 连接复用、请求合并 |
| 可容忍延迟的接口 | 短TTL缓存 | 5–10秒 | 根据实时性要求判断 |
| 敏感数据（用户/订单） | 禁止缓存 | — | 排除Cookie和认证头 |
四、缓存规则与防护策略的协同
缓存规则和防护策略共享同一条处理链路，配置时需要考虑两者的协同。当CDN收到请求时，先匹配缓存规则，再执行安全校验。缓存命中的请求直接返回，但仍需参与安全基线建模；缓存未命中的请求进入安全校验流程，通过校验后回源。
需要避免的配置冲突包括：防护规则误伤缓存请求（例如CC防护的频率限制把高频缓存请求也拦截了）、缓存绕过安全校验（缓存命中的请求不参与安全基线建模，导致攻击者利用缓存机制绕过防护）。评估时需要确认服务商是否在同一套架构内协同缓存和防护，而不是两个独立模块。
五、结语
缓存规则配置的核心是分类管理：静态资源默认缓存，动态接口优化回源，敏感数据禁止缓存。配置时需要根据业务特征设置合理的TTL，避免缓存过期太频繁或版本更新延迟。缓存规则与防护策略的协同也不容忽视——缓存命中的请求仍需参与安全建模，防护规则不应误伤正常的缓存请求。这些配置细节，比"是否支持缓存"更能说明高防CDN在攻击期间保护源站的实际效果。
相关阅读：如果你想了解连接复用如何降低动态请求的回源开销，高防CDN节点调度与近源清洗中有相关拆解。
