proxy_cache_use_stale 是源站宕机时返回过期缓存实现平滑降级的关键配置，需配合 proxy_cache_path、proxy_cache_key 稳定、proxy_cache_valid 覆盖 5xx 及 X-Cache 头验证共同生效。
当后端源站宕机时，proxy_cache_use_stale 是让 Nginx 继续返回本地已有缓存（哪怕已过期）的关键开关——它不解决“有没有缓存”，而是决定“能不能用过期缓存顶一顶”。要真正生效，必须和缓存基础、错误响应缓存、验证机制协同配置。
只启用关键 stale 触发条件
源站宕机通常表现为连接失败（error）、读取超时（timeout）或明确返回 502/503/504。只需针对性开启这些参数：
proxy_cache_use_stale error timeout http_502 http_503 http_504;- 避免加
updating或invalid_header等非必要项，防止误触发 - 不建议加
http_500，除非你确认源站会在宕机前主动返回 500（多数情况是直接断连）
确保缓存链路完整且能存住错误响应
stale 不是魔法，它依赖“缓存存在 + 已过期”这个前提。常见失效原因包括：
- 没定义
proxy_cache_path或 location 中未用proxy_cache引用缓存区 -
proxy_cache_key包含动态字段（如时间戳、随机参数），导致相同请求无法复用缓存 -
proxy_cache_valid没覆盖 5xx 响应：补上proxy_cache_valid 502 503 504 1m;，确保错误响应也能进缓存，后续才可被 stale 复用 - 缓存有效期太短（如仅 10s），还没等故障发生就已清理，stale 就无内容可返
配合后台更新与锁机制提升可用性
单纯返回旧内容只是第一步。更进一步，要让用户无感地拿到新内容：
- 开启
proxy_cache_background_update on;：Nginx 在返回 stale 的同时，自动发起异步子请求刷新缓存 - 启用
proxy_cache_lock on;和proxy_cache_lock_timeout 3s;：防止大量并发请求在缓存失效瞬间集体击穿源站 - 通过
add_header X-Cache $upstream_cache_status;暴露状态，便于客户端或监控识别是否命中 stale
实操验证是否真起作用
别只看日志，从客户端视角验证三件事：
- 停掉上游服务（如
systemctl stop app-server），发起请求，响应头中出现X-Cache: STALE - 响应体（body）和故障前完全一致，不是空页或默认 502 页面
- 响应耗时明显低于
proxy_read_timeout（比如设为 3s，实际返回在 20–80ms），说明确实绕过了回源
