Nginx 在后端宕机时能否返回缓存内容，取决于是否预先配置 proxy_cache_use_stale 及其依赖的完整缓存机制，包括 proxy_cache_path、proxy_cache、proxy_cache_key 和 proxy_cache_valid 对 5xx 的覆盖，且需通过 X-Cache: STALE 等指标验证生效。
后端全线宕机时，Nginx 能否继续返回内容，不取决于“有没有缓存”，而取决于是否提前配置了 proxy_cache_use_stale 及其依赖的整套缓存机制。它不是故障发生后才启用的功能，而是必须在服务正常时就部署好的降级能力。
只对明确错误码启用 stale，避免误触发
后端崩溃最可靠的信号是它主动返回的 5xx 状态码。此时应精准启用对应参数：
- 写入
proxy_cache_use_stale http_500 http_502 http_503 http_504—— 这四类响应由后端生成，可信度高 - 不加
error或timeout：网络抖动、瞬时超时可能被误判为“崩溃”，反而让旧缓存被不合时宜地返回 - 如需后台刷新时不阻塞用户，可额外加上
updating，但必须同步开启proxy_cache_background_update on
缓存本身必须存在且能复用
stale 不是魔法开关，它只能复用已存在的缓存条目。以下三点缺一不可：
-
proxy_cache_path已正确定义缓存区（含keys_zone），且磁盘路径可写、权限正确 -
location中启用了proxy_cache my_cache，并设置了稳定的proxy_cache_key，推荐用$scheme$host$request_uri，避免含时间戳、随机 ID 等干扰字段 -
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）与故障前完全一致，不是空页、不是 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），供运维手动触发更新
