Nginx负载均衡下需在proxy_cache_key中加入$upstream_addr（或后端自定义标识）以避免缓存混淆；推荐写法为proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args $upstream_addr"，并配合add_header验证生效。
Nginx 在负载均衡场景下，如果缓存键（proxy_cache_key）未体现后端节点信息，就容易出现「缓存混淆」：同一请求被不同上游服务器处理后，返回内容不同（比如带用户身份、地域逻辑的动态响应），但因缓存键相同，Nginx 把 A 服务器返回的响应缓存后，又错误地返回给本该由 B 服务器处理的后续请求——导致数据错乱或状态不一致。
根本解法是让 proxy_cache_key 区分不同 upstream 节点，而 $upstream_addr 正是 Nginx 在反向代理完成后自动填充的变量，值为实际转发到的后端地址（如 10.0.1.5:8080 或 10.0.1.5:8080, 10.0.1.6:8080，含端口，支持 keepalive 连接复用时的多地址拼接）。
缓存键必须包含 $upstream_addr
默认 proxy_cache_key $scheme$host$request_uri 不含后端标识，所有节点共享同一缓存条目。应显式加入 $upstream_addr，例如：
- 推荐写法（兼容单节点与多节点，且避免因连接重试导致 key 变化）：
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args $upstream_addr";
- 若后端使用 IP+端口且无 TLS，也可简化为：
proxy_cache_key "$uri $upstream_addr";
⚠️ 注意：$upstream_addr 是运行时变量，只能在 location 块中 proxy_cache_key 指令里使用，不能用于 proxy_cache_path 的 keys_zone 名称等静态上下文。
配合 proxy_cache_use_stale 提升容错性
当某台后端短暂不可用，Nginx 可能切换到其他节点，此时若缓存键含 $upstream_addr，新节点的响应会生成新缓存条目，旧节点缓存不会干扰。但需注意：
- 同一请求在不同节点间反复漂移时，可能造成缓存冗余；
- 若业务允许「降级缓存」，可启用：
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
这样即使某节点故障，仍可用已有缓存（来自其他节点）响应，避免全量击穿。
验证是否生效的关键指标
在响应头中添加调试信息，确认缓存行为与后端绑定关系：
add_header X-Cache-Status "$upstream_cache_status"; add_header X-Upstream-Addr "$upstream_addr";
访问时观察：
- 多次请求若命中
HIT且X-Upstream-Addr始终一致 → 缓存已按节点隔离； - 若
X-Upstream-Addr变化但X-Cache-Status仍是MISS→ 缓存键未真正包含该变量（检查语法、作用域、是否被覆盖）； - 若
X-Upstream-Addr含逗号（如10.0.1.5:8080, 10.0.1.6:8080）→ 表示启用了连接池复用，此时建议改用$upstream_http_x_backend_id等自定义响应头更稳定（需后端配合返回唯一标识）。
替代方案：后端主动声明身份（更可控）
当 $upstream_addr 因 NAT、容器网络或 VIP 导致不够唯一时，推荐后端在响应头中返回明确标识，例如：
X-Backend-ID: node-a-prod-v2
Nginx 中即可用：
proxy_cache_key "$scheme$request_method$host$request_uri$is_args$args $upstream_http_x_backend_id";
这种方式解耦网络拓扑，缓存策略更稳定，适合微服务或 K8s 环境。
不复杂但容易忽略
