文档目的:总结基于 URL 参数的动态 API 缓存配置标准,以及源站 HTTP 响应头冲突的排障方案。
一、 基础架构与回源避坑(Host 头部透传问题)
场景:
-
CDN 监听公网域名:
api.hahaha.com -
源站(Origin):VPC 内部 ALB,域名为
api.hahaha.internal.com
⚠️ SRE 避坑指南 : 在配置"源请求策略 (Origin Request Policy)"时,强烈建议选择 AllViewerExceptHostHeader(或其他剔除 Host 头的自定义策略)。
- 原因 :如果全量透传(包含 Host),CDN 会把公网域名
api.hahaha.com丢给后端 ALB。由于内网 ALB 配置的证书或路由规则是基于internal.com的,会导致 SSL 握手失败或报 403/404 错误。剔除 Host 头可让 CloudFront 使用源域名与 ALB 进行 SNI 握手。
二、 API 动态缓存核心配置(按参数隔离)
需求 :同一个 API 路径 /public/auth/keys,根据不同的查询参数 ?keyId=xxx 返回并缓存不同的内容。
操作标准:
-
Cache Policy (缓存策略):
-
必须新建策略,在 Query strings (查询字符串) 设置中选择 All (全部)。
-
作用:强制 CDN 将整个 URL(含参数)作为 Cache Key 哈希值,实现不同
keyId的缓存隔离,防止数据串号。
-
-
Behavior (行为优先级):
-
缓存规则必须绑定到具体路径
/public/*,且优先级必须高于默认的*(全站不缓存规则)。 -
方法限制:严格限制为
GET, HEAD,避免 POST 等写操作被错误缓存。
-
三、 缓存不生效排障:源站 Cache-Control 冲突
故障现象 :CDN 配置完美,但多次 curl 请求始终返回 x-cache: Miss from cloudfront。
根因分析 : 后端应用默认返回了强制禁止缓存的 HTTP 响应头: cache-control: no-cache, no-store, max-age=0
- CloudFront 默认严格遵守源站指令。只要源站带有
no-store,无论 CDN 设置了多长的 TTL,CDN 均拒绝对其进行缓存。
解决方案对比:
-
方案 A:修改后端应用(🌟 最佳实践)
-
操作 :要求开发调整此 API 的响应头,输出
cache-control: public, max-age=3600。 -
优势:符合 HTTP 规范,逻辑清晰,不增加边缘架构复杂度。
-
-
方案 B:边缘函数强制覆盖(🛠️ 运维降级/兜底方案)
-
操作 :如果后端无法修改,使用 CloudFront Functions 编写拦截脚本。
-
绑定位置 :在 Behavior 的 Viewer Response(查看器响应) 阶段绑定该函数。
-
代码逻辑:
function handler(event) { var headers = event.response.headers; // 抹除后端的流氓禁止头,强行植入缓存指令 headers['cache-control'] = { value: 'public, max-age=3600' }; delete headers['pragma']; delete headers['expires']; return event.response; } -
优势:无需业务改代码,运维单方面即可破局强行缓存。
-
四、 SRE 结单验证
-
验证 Hit/Miss :连续请求目标 API,观察响应头中的
x-cache状态以及Age参数。 -
节点集群物理特性 :前期出现
Hit和Miss交替属于正常现象(同一 CDN 边缘节点存在多台服务器集群,需时间预热同步)。持续高并发请求后,命中率将趋于 100%。