关键不是自动降级，而是确保缓存有旧内容、nginx明确允许复用502/504、链路稳定命中；需配置proxy_cache_use_stale http_502 http_504、proxy_cache_valid 502 504 1m、稳定cache_key，并配合background_update与cache_lock。
后端超时（502/504）时返回旧缓存，关键不是“自动降级”，而是确保缓存有内容、Nginx 明确允许复用、且请求能稳定命中。配置必须闭环，缺一不可。
只对可信错误启用 stale
502 和 504 是网关层明确返回的失败信号，语义清晰、误判率低。应精准启用：
-
必须写：
proxy_cache_use_stale http_502 http_504; -
不建议加
error或timeout：连接中断或读超时可能是瞬时抖动，盲目启用容易把本可恢复的请求也降级 - 如需后台刷新，可追加
updating，但必须同步开启proxy_cache_background_update on;
让错误响应也能进缓存
stale 不生成缓存，只复用已存在的过期条目。如果 502/504 根本没被缓存过，后续就无“旧内容”可返：
-
必须加：
proxy_cache_valid 502 504 1m;——确保这类响应也会落盘，哪怕只存 1 分钟 - 配合常规状态码缓存，例如：
proxy_cache_valid 200 301 302 10m; - 避免 404 占位：
proxy_cache_valid 404 10s;防止无效响应长期挤占空间
保证缓存键稳定、区域可用
同一资源必须始终映射到同一个缓存 key，否则旧内容再全也找不到：
-
推荐 cache_key：
proxy_cache_key "$scheme$host$request_uri"; - 禁用动态字段：如
$args、$cookie_、时间戳、随机参数等 -
必须定义缓存区：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:512m inactive=3d use_temp_path=off; -
必须在 location 中启用：
proxy_cache my_cache;（仅配proxy_cache_valid不生效）
验证是否真走 stale 路径
不能只看返回状态码是 200，要从客户端视角确认三件事：
- 停掉 upstream 后发起请求，响应头中出现 X-Cache: STALE（需提前配
add_header X-Cache $upstream_cache_status;） - 响应体与故障前完全一致：不是空页、不是 Nginx 默认 502 页面、也不是 JSON 结构错乱
- 响应耗时远低于
proxy_read_timeout（比如设为 5s，实测返回在 30–80ms），说明确实跳过了回源
