nginx 不支持多机缓存自动同步，需靠统一缓存键、主动 purge、url 版本化及分层部署保障一致性：所有节点用相同 proxy_cache_key 和 keys_zone；发布时调用 purge 接口清除；静态资源哈希命名+强缓存；边缘缓存静态内容，中间层收敛回源，后端精准控制 cache-control。
直接说结论：Nginx 本身不支持多台服务器之间的缓存同步，所谓“分布式缓存一致性”不是靠它自动同步数据，而是靠统一规则、外部控制和架构设计来让各节点行为一致、失效可控、命中稳定。
统一缓存键与标准化策略
不同 Nginx 实例若用不同 proxy_cache_key，同一请求会生成多个缓存副本，导致部分节点更新了、其他节点还在返回旧内容。必须强制对齐：
- 所有节点使用完全相同的 key，例如：proxy_cache_key "$scheme$host$request_uri"
- 含跟踪参数（如 utm_source、_t）时，先用 map 清洗再参与哈希，避免缓存碎片
- 禁用 $cookie_xxx、$http_authorization 等易变变量，除非业务明确需要按用户隔离
- 所有节点共用相同 keys_zone 名称和大小（如 keys_zone=static_cache:500m），便于后续统一管理
主动失效代替被动等待
等 TTL 到期太慢，尤其在发布频繁的场景下极易出现脏数据。应建立“发布即清除”机制：
- 启用 ngx_http_proxy_cache_purge 模块（编译时加入或通过宝塔插件安装）
- 配置受控的 purge 接口，限制仅内网调用：
location ~ /purge(/.*) { allow 10.0.0.0/8; deny all; proxy_cache_purge static_cache $scheme://$host$1; } - 发布脚本中批量触发：curl -X PURGE http://edge1.example.com/purge/js/app.js
- 建议对 purge 响应做状态校验：只接受 200（成功）或 404（未命中），5xx 需告警并重试
URL 版本化从源头规避陈旧
最彻底的一致性方案是让更新 = 新 URL，旧缓存自然失效，无需 purge：
- 构建阶段为静态资源注入内容哈希，如 app.a1b2c3.js、style.f4d5e6.css
- Nginx 对这类资源设强缓存：expires 1y; add_header Cache-Control "public, immutable";
- 入口 HTML 单独处理，短时效（如 60 秒），确保用户能及时拉取含新链接的新页面
- 该方式对浏览器、CDN、Nginx 缓存全部生效，零运维风险
分层部署与角色收敛
高可用不是堆机器，而是让每层各司其职、故障不扩散：
- 边缘层（各地机房）：开启 proxy_cache，专注静态资源和低频变更 API；禁止缓存带身份、订单、实时数据的接口
- 中间层（统一网关）：收敛回源，所有边缘 Nginx 的 proxy_pass 指向同一高可用源站（如对象存储、MinIO 或轻量静态服务）
- 后端层（应用侧）：配合 Cache-Control 响应头精准控制，如 public, max-age=3600 或 private, max-age=60
- 启用 proxy_cache_use_stale error timeout http_502-504，源站异常时仍可返回旧缓存保底
不复杂但容易忽略。
