proxy_cache_use_stale 在后端崩溃时通过预设缓存返回已过期但可用内容，需配置 proxy_cache_use_stale http_500 http_502 http_503 http_504、稳定 cache_key、cache_valid 覆盖 5xx，并验证 X-Cache: STALE 及响应一致性。
后端全线崩溃时，proxy_cache_use_stale 不是“自动兜底”，而是靠提前配置好的缓存链路，在检测到 5xx 错误时主动返回已过期但可用的内容。关键在于让 Nginx 有东西可返、知道何时能返、且用户拿到的是真实旧数据。
只启用真正匹配崩溃场景的 stale 条件
后端整体不可用，通常表现为明确的 5xx 响应（如全部 upstream server 进程退出或被防火墙拦截），此时应精准启用：
-
proxy_cache_use_stale http_500 http_502 http_503 http_504;——这四类是后端主动发出的故障信号，可信度最高 - 不加
error或timeout：网络抖动、瞬时连接失败可能误判为“崩溃”，反而放大异常影响 - 如需后台静默刷新，可额外加
updating，但必须同步开启proxy_cache_background_update on;
确保缓存本身“存得住、找得着、过得了期”
stale 生效的前提是：缓存条目存在、key 稳定、且已过期。常见失效原因都源于基础配置缺失：
- 必须定义
proxy_cache_path并在 location 中通过proxy_cache引用对应区域，例如：proxy_cache my_cache; -
proxy_cache_key要稳定：避免含$time_iso8601、$request_id等动态字段；推荐用$scheme$host$request_uri -
proxy_cache_valid必须覆盖 5xx 响应：加一句proxy_cache_valid 500 502 503 504 1m;，否则错误响应根本不会进缓存，后续无法 stale 复用
从客户端视角验证是否真生效
停掉所有 upstream server 后，不要只看状态码，要确认三件事：
- 响应头中出现
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 响应体（body）与故障前完全一致，不是空页、JSON 错误或 Nginx 默认 502 页面
- 响应耗时远低于
proxy_read_timeout（例如设为 3s，实际返回在 50ms 内），说明确实绕过了回源
提升体验：让降级更平滑、更新更安静
返回旧内容只是起点，进一步可做到用户无感过渡：
- 开启
proxy_cache_background_update on;：stale 返回的同时，Nginx 自动异步向后端发起刷新请求 - 启用
proxy_cache_lock on;和proxy_cache_lock_timeout 3s;：防止缓存失效瞬间大量并发请求集体击穿后端 - 对核心接口，可提供带签名的缓存刷新入口（如
/api/v1/refresh?token=xxx），供运维手动触发更新
