proxy_cache_use_stale 是容灾开关而非故障补救，仅在后端真实宕机（如连接中断、502/503/504）时安全复用缓存；需配合有效缓存配置、稳定key、5xx缓存策略及后台更新机制，确保用户无感访问并持续刷新。
微服务网关中 Nginx 缓存失效不是故障信号，而是容灾机制启动的起点。关键不在“防止失效”，而在“失效后仍能安全托底并持续更新”。优化核心是让 proxy_cache_use_stale 真正起效，且不依赖人工干预或后端恢复。
精准触发 stale：只响应真实宕机信号
缓存托底必须有明确、可靠的触发依据，避免把瞬时抖动当故障：
-
必开：
error（覆盖连接拒绝、上游重置、DNS 失败等底层中断） -
必开：
http_502 http_503 http_504（标准网关级不可用语义，如上游无响应、服务未就绪、超时） -
慎开：
http_500（多数应用崩溃直接断连，不返回 500；若确认稳定输出 500，再加入） -
不建议开：
timeout（单次读超时可能是网络抖动，非节点宕机）
确保缓存“存得住、找得准、过得了期”
stale 是授权使用旧数据，前提是旧数据真实存在、可命中、未被清理：
- 缓存区已启用：
proxy_cache_path /var/cache/nginx/mycache ... keys_zone=mycache:128m;，且对应location中写了proxy_cache mycache; - cache key 稳定：
proxy_cache_key "$scheme$host$request_uri";，剔除$args、$cookie_、?t=等干扰字段 - 5xx 响应必须进缓存：
proxy_cache_valid 502 503 504 1m;，否则后端返回 503 时根本不会落盘，stale 就无内容可返 - 主响应设合理有效期：
proxy_cache_valid 200 301 302 10m;，避免缓存刚生成就被inactive清理
边服务边恢复：避免静默陈旧
返回 stale 内容只是第一步，重点是在用户无感知前提下完成后台刷新：
- 开启后台更新：
proxy_cache_background_update on;→ 返回 stale 同时，Nginx 自动发起子请求拉新内容 - 防并发击穿：
proxy_cache_lock on;+proxy_cache_lock_timeout 3s;→ 同一 key 下，首个请求负责回源或触发后台更新，其余请求等待或继续走 stale - 暴露状态便于验证：
add_header X-Cache $upstream_cache_status;→ 故障时看到X-Cache: STALE才说明机制生效
验证是否真在容灾，而非假装正常
停掉 upstream 后，从客户端视角确认三件事：
- 响应状态码仍是 200（或原状态），不是 502/503
- 响应头含 X-Cache: STALE
- 响应体内容与故障前完全一致（不是空页、不是默认错误页、不是 JSON 错误结构）
