Nginx 中 HTTP 代理怎么管理缓存一致性-Nginx-PHP中文网

nginx代理缓存需通过统一cache_key、主动purge失效、静态资源url版本化及一致性哈希回源来保障缓存一致性；禁止使用易变变量，推荐proxy_cache_key "$scheme$host$request_uri"，并剔除跟踪参数。

nginx 中 http 代理怎么管理缓存一致性

Nginx 的 HTTP 代理缓存本身是本地独占的，不支持节点间自动同步。所谓“缓存一致性”，不是让所有机器缓存内容完全一样，而是确保用户看到的数据不陈旧、不冲突、不抖动——靠的是统一规则 + 外部协同 + 架构设计。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

统一缓存键是底线
不同 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 过期不可控，尤其在发布频繁或数据敏感场景下风险高。应建立“发布即清除”机制：

在 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/图片等不变内容，最稳妥的一致性手段是“绕开失效逻辑”，让更新 = 新路径：

配合强缓存策略：

location ~* \.(js|css|png|woff2?)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

多节点回源要绑定一致性哈希
当多台 Nginx 共享同一组后端时，若负载策略导致同一 URI 落到不同节点，每台都可能独立回源缓存，浪费带宽与 CPU。应在 upstream 块中启用一致性哈希：

不复杂但容易忽略