Nginx的proxy_cache本身不支持分布式缓存共享，各节点必须独立配置本地proxy_cache_path，禁止使用NFS等分布式文件系统；需统一cache_key、生命周期策略，并通过集中purge或外部Redis实现逻辑一致性。
Nginx 的 proxy_cache 本身不支持分布式缓存共享——每个节点的缓存是完全独立、本地落盘的，无法自动同步或共享文件。所谓“分布式缓存集群”，不是靠文件系统共享实现的，而是通过架构协同与协议控制达成逻辑一致。核心思路是：**各节点独立缓存 + 统一策略 + 外部协同**。
各节点独立配置本地 proxy_cache_path
这是前提，也是唯一安全可靠的方式：
- 每个 Nginx 实例（华东、华南、海外等）都使用本地高性能磁盘（如 NVMe SSD），配置独立的
proxy_cache_path，例如：proxy_cache_path /data/cache/huadong levels=1:2 keys_zone=static:512m max_size=100g inactive=1h use_temp_path=off; - 禁止将该路径挂载为 NFS、CephFS 或 GlusterFS 等分布式文件系统——会破坏原子写入（如 rename）、导致 key 冲突、驱逐失效、
proxy_cache_lock失能，甚至静默降级为X-Proxy-Cache: BYPASS - 确保目录已创建、权限正确（如
chown nginx:nginx /data/cache/huadong）、文件系统支持 O_DIRECT 和原子操作
统一缓存键与生命周期策略
让所有节点对同一请求生成相同 key、过期行为一致，是“逻辑共享”的基础：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 显式定义
proxy_cache_key，避免默认值引发碎片，例如：proxy_cache_key "$scheme$host$request_uri$is_args$args$http_x_content_version"; - 用
map清洗干扰参数（如utm_source、_t=），保证语义等价的 URL 映射到同一 key - 上游服务返回标准
Cache-Control和自定义版本头（如X-Content-Version: v20260915），Nginx 通过proxy_cache_valid和 key 中包含该 header，实现版本升级即全量刷新
集中触发缓存清理（逻辑同步）
静态资源更新时，需主动通知所有节点失效对应缓存，而非等待自然过期：
- 编译启用
ngx_cache_purge模块，在每台 Nginx 上开放受控的/purge接口（建议加 IP 白名单和鉴权） - 发布新版本 JS/CSS/HTML 时，调用脚本批量请求各节点的 purge 接口，例如：
curl -X PURGE "http://huadong.example.com/purge//static/app.js" - 也可结合 CI/CD 流程，在对象存储（OSS/S3）文件更新后，自动触发 purge 广播
替代方案：绕过 proxy_cache，用集中式缓存层
若业务强依赖强一致性、高并发读写、跨节点共享，可放弃 proxy_cache，改用外部缓存：
- 所有 Nginx 实例连接同一 Redis 集群，用
lua-resty-redis在 OpenResty 中实现“先查缓存、未命中再回源、结果回填”全流程 - 缓存 key 统一构造（如
cache:$host:$uri:$args），响应体 + 状态码 + headers 序列化存储 - 适合 API 响应、商品页、用户中心等中低频更新、高读取场景；注意设置合理 TTL 和连接池防雪崩
