proxy_cache_use_stale 可在源站宕机时返回已过期缓存内容，需精准配置 error/502/503/504，配合 proxy_cache_valid、keys_zone 等确保缓存可用，并通过 X-Cache: STALE 验证降级生效。
当后端源站宕机时，proxy_cache_use_stale 能让 Nginx 在无新鲜响应可取的情况下，主动返回本地已缓存但已过期的内容——这不是“凑合用”，而是有控制、可验证、不中断的降级策略。
只对真正需要的故障类型启用 stale
源站宕机最典型的表现是连接失败（error）或明确返回 5xx（如 502503）。应精准开启对应参数：
proxy_cache_use_stale error http_502 http_503 http_504;- 避免加
timeout或invalid_header，否则网络抖动或响应头异常也会触发 stale，扩大误降级范围 - 若同时希望后台刷新时不阻塞用户，可额外加上
updating，但需配套开启proxy_cache_background_update on
确保缓存本身“存在且可用”
stale 不是魔法开关，它依赖前置缓存链路完整生效：
- 必须定义
proxy_cache_path并在location中引用对应keys_zone -
proxy_cache_key要稳定，避免含时间戳、随机参数等导致缓存键漂移 -
proxy_cache_valid必须覆盖正常响应和错误响应：proxy_cache_valid 200 301 302 10m;proxy_cache_valid 502 503 504 1m;—— 错误响应也要进缓存，后续 stale 才能复用
验证降级是否真实生效
不能只看状态码是否为 200，要从客户端视角确认行为：
- 停掉上游服务（如
systemctl stop app-server），发起请求 - 检查响应头中是否有
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 对比故障前后响应体是否一致，确认返回的是原样旧内容，而非空页或 Nginx 默认错误页
- 响应耗时应在毫秒级（如 proxy_read_timeout（如设为 3s），说明确实绕过了回源
配合后台更新与锁机制提升体验
单纯返回旧内容只是第一步；更进一步，应让用户无感地过渡到新内容：
- 开启
proxy_cache_background_update on;，使 Nginx 在返回 stale 的同时，异步拉取新响应并写入缓存 - 启用
proxy_cache_lock on;和proxy_cache_lock_timeout 3s;，防止缓存失效瞬间大量并发请求集体击穿源站 - 对关键接口，可结合提供手动刷新入口（如带签名的
/cache/refresh?uri=/api/status）
