Nginx 实现后端崩溃时返回可用内容，需配置 proxy_cache_use_stale http_500 http_502 http_503 http_504，并确保 proxy_cache_path、稳定 cache_key、proxy_cache_valid 覆盖 5xx 及 X-Cache 头验证生效。
要让 Nginx 在负载均衡后端整体崩溃时仍返回可用内容，关键不是“兜底”，而是提前设计好缓存降级链路。proxy_cache_use_stale 是其中的触发开关，但它必须运行在一套完整、稳定的缓存基础上才能生效。
只启用真正需要的 stale 条件
针对后端崩溃场景，应精准启用对应状态码，避免过度宽松导致误触发：
- 明确写入 http_500 http_502 http_503 http_504 —— 这四类是后端明确返回的故障信号，最可信
- 不加 error 或 timeout：网络抖动、瞬时超时可能误判为“崩溃”，反而放大异常影响
- 如需后台静默刷新，可额外加上 updating，但必须配合 proxy_cache_background_update on
确保缓存本身能存得住、找得着
stale 生效的前提是：缓存条目存在且已过期。常见失效原因都和基础配置有关：
- 必须定义 proxy_cache_path 并在 location 中通过 proxy_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）与故障前完全一致，不是空页或 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），供运维手动触发更新
