Nginx跨服务器缓存一致性需通过统一cache_key、主动purge失效、URL版本化及URI一致性哈希实现，而非依赖内置同步功能；关键包括归一化key、剔除跟踪参数、避免易变变量、内网purge接口、内容哈希路径和upstream哈希路由。
Nginx 本身不支持跨服务器缓存状态自动同步，所有 proxy_cache 都是本地独占、相互隔离的。所谓“跨服务器缓存一致性”，不是让各节点缓存内容完全一样，而是确保业务行为可预期：内容更新后用户不持续看到旧数据，相同请求大概率命中本地缓存，不同节点不返回冲突结果。实现它靠的是架构设计和协同机制，而非 Nginx 内置功能。
统一 cache_key 是前提
所有 Nginx 实例必须使用完全一致的 proxy_cache_key，否则同一 URL 可能生成多个缓存条目，命中率下降且易残留脏数据。
- 推荐写法：
proxy_cache_key "$scheme$host$request_uri";（覆盖协议、域名、完整 URI，含参数） - 若 URL 含跟踪参数（如
utm_source=xxx或_t=1623456789），需先用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/xxx.js - 响应为
200（成功清除）或404（未命中）均属正常；若返回5xx，需告警并重试
用 URL 版本化规避缓存陈旧
对静态资源（JS/CSS/图片等），最稳妥的方式是让新内容走新路径，彻底绕开失效逻辑：
- 构建时嵌入内容哈希：
app.f3a8c2d4.js→ 发布即新 URL，旧缓存自然失效 - 或统一加版本参数：
/style.css?v=2.4.1，发布时更新v值 - 此方式对浏览器、CDN、Nginx 缓存全部生效，零 purge 操作，运维风险最低
多节点回源时绑定 URI 一致性哈希
当多台 Nginx 共享同一组后端时，若负载策略导致同一 URI 落到不同 Nginx，每台都可能独立回源缓存，浪费带宽与 CPU。
- 在 upstream 块中启用一致性哈希：
hash $request_uri consistent;（Nginx 1.7.2+ 原生支持） - 或使用第三方模块：
consistent_hash $request_uri;（需确认已编译with-http_upstream_consistent_hash） - 关键点：
$request_uri比$remote_addr更适合静态资源，因为它按资源粒度固定路由，而非按用户 IP - 若参数含无关字段（如
?_t=xxx），必须先map过滤，否则哈希结果不稳定
不复杂但容易忽略
