Nginx 与 CDN 结合的核心是充当边缘节点的“缓存大脑”，需从缓存层级、键值设计、响应控制三方面对齐：明确角色定位（优先部署于边缘层）、定制 cache_key 避免污染、分级设置缓存时效、协同 CDN 回源行为，并注意缓存路径权限与磁盘水位管理。
把 Nginx 缓存策略和 CDN 节点结合，核心是让 Nginx 充当边缘节点的“缓存大脑”——既控制缓存存什么、存多久、怎么命中，又配合 CDN 的就近分发逻辑，减少回源次数、降低源站压力。不是简单加个 proxy_cache 就行，得从缓存层级、键值设计、响应控制三方面对齐。
明确 Nginx 在 CDN 架构中的角色定位
Nginx 可以是：
– CDN 边缘节点（比如私有 CDN 的各地区服务器）
– 源站前的缓存代理（保护真实后端，统一出口）
– 或两者兼有（多级缓存：浏览器 → CDN 边缘 → Nginx 源站缓存）
实际部署中，优先把 Nginx 放在边缘层做第一道缓存，效果最直接。比如用 3 台 Nginx 分别部署在华东、华北、华南机房，每台都配置独立 cache zone，用户 DNS 解析到最近节点后，由本地 Nginx 完成缓存判断与响应。
定制 cache_key，避免缓存污染和失效错位
CDN 节点常因 URL 参数（如 utm_source、_t=123）或 Cookie 导致同一资源被反复缓存多次。Nginx 必须主动归一化 key：
- 忽略无意义参数：用 proxy_cache_key "$scheme$host$uri$is_args$arg_v$arg_id"; 只保留版本号（v）、资源 ID（id）等关键标识
- 统一 Host 头：若多个域名指向同一服务，用 proxy_cache_key "$scheme$request_method$host$uri"; 并确保 server_name 统一处理
- 跳过 Cookie 和 User-Agent 影响：默认不参与 key 计算，除非业务强依赖（如登录态静态页），此时应改用其他机制（如 ESI 或动态降级）
按响应状态和内容类型分级设置缓存时效
不能所有 200 都缓 1 小时。要依据资源稳定性动态调整：
- 静态资源（JS/CSS/图片）：proxy_cache_valid 200 302 7d；配合后端返回 Cache-Control: public, max-age=604800
- 带版本号的构建产物（如 app.abc123.js）：可设为永久缓存（max_age=31536000），靠文件名变更触发更新
- API 接口类响应（JSON）：proxy_cache_valid 200 302 5m；同时用 proxy_cache_use_stale error timeout updating 应对源站抖动
- 404 页面：proxy_cache_valid 404 1m，防爬虫反复刷不存在路径打垮源站
配合 CDN 回源行为做缓存协同
CDN 边缘节点本身也会缓存，Nginx 作为其上游，需避免“双重缓存冲突”：
- 关掉 Nginx 对某些头的透传：proxy_ignore_headers Cache-Control Expires Set-Cookie；让 Nginx 自主决策，不被源站头干扰
- 主动注入缓存状态标头：add_header X-Cache-Status $upstream_cache_status; 方便排查是 HIT 还是 MISS
- 启用 revalidate：proxy_cache_revalidate on; 当缓存快过期时，自动带 If-None-Match/If-Modified-Since 回源校验，节省带宽且保持一致性
- 允许 stale：proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504; 网络波动时不中断服务
不复杂但容易忽略的是缓存路径权限和磁盘水位。比如 proxy_cache_path 的目录必须由 nginx worker 进程可写，且建议用 SSD + noatime 挂载；max_size 设太大可能挤占系统空间，建议搭配 logrotate 或定时清理脚本做兜底。
