Nginx在后端故障时返回陈旧缓存需构建可控降级链路：启用proxy_cache_use_stale http_500-504，确保proxy_cache_path、稳定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
：网络抖动、瞬时连接失败可能误触发 stale，反而放大异常影响
如需后台静默更新，可追加
updating
，但必须同步开启
proxy_cache_background_update on
确保缓存基础链路完整
stale 不是独立功能，它只在“缓存存在且已过期”时才生效。常见失效都源于基础配置缺失或不稳定：
必须定义
proxy_cache_path
并在 location 中通过
proxy_cache
引用命名区域
proxy_cache_key
要稳定：推荐
，避免含时间戳、随机参数、Cookie 等易变字段
proxy_cache_valid
必须覆盖 5xx 响应：加一句
，否则错误响应根本不会进缓存，后续无法复用
从客户端视角验证是否真实生效
不能只看 Nginx 日志或返回状态码，要确认用户实际拿到的是旧内容：
停掉上游服务后发起请求，响应头中出现
X-Cache: STALE
（需提前配置
）
响应体与故障前完全一致，不是空页、不是 Nginx 默认 502 页面
响应耗时显著低于
proxy_read_timeout
（例如设为 3s，实测返回在 50ms 内），说明确实绕过了回源
提升体验的配套动作
返回陈旧内容只是第一步，更进一步可做到“用户无感更新”：
开启
proxy_cache_background_update on
：stale 返回的同时，Nginx 自动异步刷新缓存
启用
proxy_cache_lock on
和
proxy_cache_lock_timeout 3s
：防止缓存失效瞬间大量并发请求集体击穿后端
对核心接口，可提供带签名的缓存刷新入口（如
），供运维手动触发更新
"$scheme$host$request_uri"proxy_cache_valid 500 502 503 504 1m;add_header X-Cache $upstream_cache_status;/api/v1/refresh?token=xxx