Nginx 缓存层与应用服务的版本发布同步-Nginx-PHP中文网

nginx缓存需通过缓存键设计、响应头控制和主动清理三者协同实现版本同步：用x-app-version或x-content-version注入版本标识到proxy_cache_key；上游设置cache-control明确过期策略；发布时调用purge接口主动清理对应缓存。

nginx 缓存层与应用服务的版本发布同步

Nginx 缓存层本身不感知应用版本，也不会自动响应后端服务的发布动作。要让 Nginx 缓存行为与应用版本发布保持同步，关键不是“等它自动跟上”，而是通过缓存键设计、响应头控制、主动清理机制三者协同，在架构层面把“版本”显式地注入到缓存生命周期中。

当多个应用版本（如 v1.2.0、v1.3.0）共存于同一套域名下时，若所有请求都走相同的 URL（如 /api/config），Nginx 默认会按 $scheme$host$request_uri 缓存，导致新旧版本响应被错误复用。

解决方法是让缓存键携带可区分的版本信号：

前端或网关在请求头中带上 X-App-Version: v1.3.0，Nginx 配置为：
```
proxy_cache_key "$scheme$host$request_uri$is_args$args$http_x_app_version";
```
或由上游服务在响应头中返回 X-Content-Version: v1.3.0，再将其纳入缓存键：
```
proxy_cache_key "$scheme$host$request_uri$http_x_content_version";
```
这样，同一 URL 的不同版本会被存为独立缓存条目，天然隔离。

不要依赖 Nginx 自行猜测过期时间。上游应用在返回响应时，应统一设置标准缓存控制头：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

对静态资源（JS/CSS/图片）且带哈希路径（如 app.a1b2c3.js）：
```
Cache-Control: public, immutable
```
Nginx 可配合禁用 ETag，防止干扰 CDN 判断；

对动态接口（如 /api/user）或无哈希入口页（如 /index.html）：

Cache-Control: no-cache, must-revalidate

并在 Nginx 中显式配置：

proxy_cache_valid 200 302 1m;  # 即使上游没设，也强制短缓存
proxy_cache_valid 404 500 10s;

版本发布完成≠缓存已更新。尤其对配置类、开关类、首页文案等低频但高敏感接口，不能靠 max-age=60 等自然过期。

推荐做法：

启用 ngx_http_proxy_cache_purge 模块，在各 Nginx 实例暴露安全清理接口：

location ~ /purge(/.*) {
    allow 10.10.0.0/16;   # 运维内网段
    deny all;
    proxy_cache_purge my_cache_zone "$scheme$request_uri";
}

发布系统调用该接口，例如：
curl -X PURGE http://edge-north.prd/purge/api/config
curl -X PURGE http://edge-south.prd/purge/index.html
支持通配符（需模块支持）或正则匹配，一次清除多个相关路径。

不复杂但容易忽略。