Nginx代理缓存需通过统一cache_key、主动purge失效、静态资源URL版本化及一致性哈希回源来保障缓存一致性；禁止使用易变变量，推荐proxy_cache_key "$scheme$host$request_uri"，并剔除跟踪参数。
Nginx 的 HTTP 代理缓存本身是本地独占的，不支持节点间自动同步。所谓“缓存一致性”，不是让所有机器缓存内容完全一样，而是确保用户看到的数据不陈旧、不冲突、不抖动——靠的是统一规则 + 外部协同 + 架构设计。
统一缓存键是底线
不同 Nginx 实例若用不同 proxy_cache_key，同一 URL 可能生成多个缓存条目，命中率低且易残留脏数据。必须全局强制对齐：
- 推荐写法：
proxy_cache_key "$scheme$host$request_uri";（覆盖协议、域名、完整 URI，含参数） - 若 URL 含跟踪参数（如
utm_source=xxx或_t=123456789），需用map指令提前归一化剔除，再参与哈希 - 避免引入
$cookie_sessionid、$http_authorization、$http_referer等易变变量，除非业务明确需要按用户隔离
主动失效比等过期更可靠
依赖 proxy_cache_valid 的 TTL 过期不可控，尤其在发布频繁或数据敏感场景下风险高。应建立“发布即清除”机制：
- 编译启用
ngx_http_proxy_cache_purge模块 - 在 location 中开放安全 purge 接口，例如：
location ~/purge(/.*) { allow 10.0.0.0/8; # 仅内网调用 proxy_cache_purge my_cache $1$is_args$args; deny all; } - 源站发布完成后，并发向所有边缘节点执行
curl -X PURGE https://edge1.example.com/purge/path/to/resource - 响应为
200（已清除）或404（未命中）均属正常；5xx需告警并重试
静态资源优先走 URL 版本化
对 JS/CSS/图片等不变内容，最稳妥的一致性手段是“绕开失效逻辑”，让更新 = 新路径：
- 构建时嵌入内容哈希：
app.f3a8c2d4.js→ 发布即新 URL，旧缓存自然失效 - 或统一加版本参数：
/style.css?v=2.4.1，发布时更新v值 - 配合强缓存策略：
location ~* \.(js|css|png|woff2?)$ { expires 1y; add_header Cache-Control "public, immutable"; } - 入口 HTML 单独设短 TTL（如 60s），确保用户能及时拉取含新链接的新页面
多节点回源要绑定一致性哈希
当多台 Nginx 共享同一组后端时，若负载策略导致同一 URI 落到不同节点，每台都可能独立回源缓存，浪费带宽与 CPU。应在 upstream 块中启用一致性哈希：
- 使用原生
hash $request_uri consistent;（Nginx 1.7.2+） - 或第三方模块
consistent_hash $request_uri;（需确认已编译支持） - 注意：不能与
ip_hash或官方hash $uri混用，否则nginx -t报错
不复杂但容易忽略
