Nginx的proxy_cache_path不支持跨机房共享缓存，因其为单机本地磁盘缓存，依赖文件系统原子操作；直接挂载NFS等分布式文件系统会导致写入失败、key冲突、驱逐失效及cache_lock失能；正确方案是各机房独立配置本地proxy_cache_path，结合响应头驱动缓存生命周期、ngx_cache_purge主动清理接口与分层回源保护实现近似一致性。
Nginx 的 proxy_cache_path 本身不支持跨机房共享缓存，因为它设计为单机本地磁盘缓存——所有缓存文件写入本机指定路径，依赖文件系统原子操作（如 rename()），而分布式文件系统（如 NFS、CephFS、GlusterFS）在并发、锁机制、元数据一致性、O_DIRECT 支持等方面存在天然限制，直接挂载共享存储作为 proxy_cache_path 会导致：
- 缓存写入失败或静默降级（
X-Proxy-Cache: BYPASS） - 多节点同时写同一 key 引发冲突或覆盖
-
inactive清理、max_size驱逐逻辑失效（各节点独立扫描，无法协同） -
proxy_cache_lock失效，引发缓存穿透与回源风暴
所以，不能也不应把 proxy_cache_path 直接指向 NFS 或其他分布式文件系统来实现“共享缓存”。真正的跨机房缓存协同，靠的是分层架构 + 协议驱动 + 主动控制，而非文件级共享。
✅ 正确做法：用 proxy_cache_path 配合分布式策略，而非分布式文件系统
1. 各机房独立部署本地缓存，路径指向本地高性能磁盘
每个边缘节点（华东、华南、海外）均配置独立 proxy_cache_path，关闭临时路径、确保本地化落盘：
proxy_cache_path /ssd/cache/edge-huadong levels=1:2 keys_zone=huadong:512m max_size=50g inactive=2h use_temp_path=off;
- ✅ 优势：IO 高效、
HIT稳定、inactive和max_size可控 - ⚠️ 要求：目录已创建、属主正确（如
chown nginx:nginx /ssd/cache/edge-huadong）、文件系统支持原子写入（避免用 NFS 挂载此路径）
2. 用响应头统一控制缓存生命周期（协议层协同）
上游服务返回标准 HTTP 缓存头，让所有机房节点“步调一致”：
Cache-Control: public, max-age=3600 X-Content-Version: v20260526a
对应 Nginx 配置：
proxy_cache_valid 200 302 1h; proxy_cache_key "$scheme$host$request_uri$is_args$args$http_x_content_version";
- 效果：同一版本内容，在所有机房命中相同 key；版本升级即全量刷新，无需文件同步
3. 通过主动清理接口实现“逻辑共享”
编译启用 ngx_cache_purge，在各节点暴露 /purge 接口：
location ~ /purge(/.*) {
allow 10.10.0.0/16; # 仅允许内网控制节点调用
deny all;
proxy_cache_purge huadong "$scheme$request_uri";
}主中心发布更新后，由运维平台或脚本批量调用所有机房的 /purge/xxx，实现秒级逻辑失效。
4. 分层缓存 + 回源保护，降低共享依赖
- 边缘节点：缓存静态资源、低频 API（
proxy_cache huadong） - 中心节点（Origin）：可再启一层
proxy_cache origin_hub，承担二级缓存与预热任务 - 关键防护：
proxy_cache_lock on; # 防止重复回源 proxy_cache_lock_timeout 5s; proxy_cache_use_stale error timeout http_502 http_503 http_504; # 故障时返回旧缓存
❌ 常见误区与风险提示
不要将
proxy_cache_path挂到 NFS / CephFS / NAS
即使挂载成功，也会因rename()跨设备失败、stat()元数据延迟、unlink()不可见等问题导致缓存不可用。不要依赖
proxy_temp_path+ 分布式存储“曲线救国”proxy_temp_path仅用于暂存未缓存响应体，不解决缓存共享问题；且同样面临跨文件系统rename报错（Invalid cross-device link）。不要用
use_temp_path=on并把proxy_temp_path和proxy_cache_path都挂同一 NFS
NFS 对O_DIRECT、原子重命名、高并发open()/write()/close()支持差，极易出现缓存损坏或性能归零。
✅ 替代方案建议（如真需集中缓存）
若业务强要求“一份缓存多处读”，应跳出 Nginx 文件缓存范式，改用：
- Redis + Lua 自定义缓存代理（适合中小规模 JSON/API）
- CDN 服务（如自建 ATS + CacheArray）
- 对象存储 + CDN 回源（如 S3 + CloudFront / 自建 MinIO + Nginx subrequest）
- 专用缓存中间件（如 Varnish Cluster with director + hash）
Nginx 的角色应回归本质：高性能边缘缓存执行器 + 协议协调者，而非分布式存储网关。
