Nginx通过配置Cache-Control、ETag、proxy_cache_key及CDN缓存刷新代理，精准解决按版本发布后旧资源残留问题：对带哈希静态资源设immutable强缓存并禁用ETag，对index.html禁用缓存，通过X-App-Version区分代理缓存键，并代理安全CDN purge请求。
Nginx 本身不直接管理 CDN 节点上的缓存，但作为源站或边缘缓存层，它可以通过精准控制响应头、缓存键和主动清理机制，有效配合 CDN 解决“按版本发布后旧资源残留”问题。核心思路是：让每个版本的资源拥有唯一标识，并确保 CDN 和浏览器只认新版本、不复用旧缓存。
配置 Cache-Control 与 ETag 实现版本感知缓存
前端构建时通常会在静态资源路径中嵌入哈希（如 app.a1b2c3.js），这是解决缓存残留的基础。Nginx 需配合这一实践，避免因配置不当导致 CDN 忽略版本差异：
-
对带哈希的静态文件（
.js,.css,.png,.woff2等），强制设置强缓存 + 不校验location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control "public, immutable"; add_header ETag ""; # 禁用 Nginx 自动生成的 ETag（避免干扰 CDN 的版本判断） }immutable告诉浏览器和 CDN：该资源永不会变，可长期缓存；ETag ""清空默认 ETag，防止 Nginx 基于文件修改时间生成干扰性校验值。立即学习“前端免费学习笔记（深入）”；
-
对无哈希的入口文件（如
index.html），必须禁用缓存或设极短有效期location = /index.html { add_header Cache-Control "no-cache, no-store, must-revalidate"; add_header Pragma "no-cache"; add_header Expires "0"; # 可选：注入构建时间戳到响应头，辅助排查 add_header X-Build-Timestamp $date_gmt; }
使用 proxy_cache_key 区分不同版本资源（适用于反向代理场景）
若 Nginx 充当源站前的缓存层（例如代理构建产物服务），需确保相同 URL 但不同版本的请求不共用缓存：
-
在
proxy_cache_path和location中显式引入版本标识proxy_cache_path /var/cache/nginx/versioned levels=1:2 keys_zone=versioned:10m inactive=7d max_size=1g; upstream build_server { server 127.0.0.1:8080; } location /static/ { proxy_pass http://build_server; proxy_cache versioned; # 关键：将请求头中的版本号（如 X-App-Version）纳入缓存键 proxy_cache_key "$scheme$request_method$host$uri$is_args$args$http_x_app_version"; proxy_cache_valid 200 302 1y; proxy_hide_header X-App-Version; # 避免泄露给客户端 }前端发布时，在请求
/static/app.js时带上X-App-Version: v2.3.1，Nginx 就会为每个版本单独缓存，互不干扰。
主动触发 CDN 缓存刷新（通过 Nginx 透传或代理 purge 请求）
部分 CDN（如 Cloudflare、腾讯云 CDN、阿里云全站加速）支持 API 或路径方式刷新。Nginx 可作为安全网关代理 purge 请求：
-
在 Nginx 上开放受控的
/cdn-purge接口，仅允许内网或带密钥调用location /cdn-purge { allow 10.0.0.0/8; # 内网运维IP段 allow 127.0.0.1; deny all; # 转发 purge 请求到 CDN 提供的刷新接口（以腾讯云为例） proxy_pass https://api.cdn.tencent.com/v2/purge; proxy_method POST; proxy_set_header Content-Type "application/json"; proxy_set_header X-TC-Key "your-secret-key"; proxy_pass_request_body on; }运维脚本或 CI 流程在发布后调用：
curl -X POST http://your-nginx/cdn-purge -d '{"urls":["https://example.com/static/app.v2.3.1.js"]}'
验证缓存行为是否生效
上线后务必验证三处响应头：
- 带哈希资源：
Cache-Control: public, immutable, max-age=31536000 -
index.html：Cache-Control: no-cache, no-store, must-revalidate - 所有响应含
X-Cache: HIT或MISS（可通过add_header X-Cache $upstream_cache_status;添加）
同时检查浏览器开发者工具 Network 标签页中，资源是否显示 from disk cache（预期）或 from memory cache，且 index.html 每次都重新拉取。
不复杂但容易忽略
