nginx 在上游返回 502 时启用兜底缓存，需满足缓存有内容、配置允许复用（proxy_cache_use_stale http_502）、链路命中三条件；配合 proxy_cache_valid 502 1m 确保有旧响应可返，并通过 background_update 与 cache_lock 实现边返回边更新。
后端返回 502 时启用兜底缓存，核心不是“自动降级”，而是让 Nginx 在确认上游不可用后，仍能安全、稳定地返回一个可用的旧响应。这需要缓存有内容、配置明确允许复用、链路能命中，三者缺一不可。
只对可信错误启用 stale 复用
502（Bad Gateway）语义清晰：上游服务存在，但无法提供合法 HTTP 响应。它比连接超时或网络中断更适合作为 stale 触发条件，误判率低。
- 配置 proxy_cache_use_stale http_502 —— 最精简、最稳妥的写法
- 不加
error或timeout：这类信号太模糊，容易把本可恢复的请求也降级 - 如需后台静默刷新，追加
updating，但必须同步开启proxy_cache_background_update on
确保 502 场景下有“旧内容”可返
stale 不生成新缓存，只复用已存在的过期条目。如果缓存里压根没存过这个 URL 的响应，就无“旧内容”可返。
- 添加 proxy_cache_valid 502 1m —— 让 502 响应本身也进缓存，哪怕只存 1 分钟
- 配合常规状态码缓存，例如：
proxy_cache_valid 200 301 302 10m - 避免 cache_key 含动态字段（如时间戳、随机数），推荐使用
proxy_cache_key "$scheme$host$request_uri"
验证是否真走 stale 路径
不能只看返回状态码是 200 就认为成功，要确认用户拿到的是真实旧数据。
- 停掉 upstream 后发起请求，响应头中出现
X-Cache: STALE（需提前配add_header X-Cache $upstream_cache_status） - 响应体与故障前完全一致，不是空页、不是默认 502 页面、也不是 JSON 结构错乱
- 响应耗时远低于
proxy_read_timeout（比如设为 5s，实测返回在 30–80ms），说明确实跳过了回源
边服务边更新：避免陈旧缓存长期滞留
返回旧内容只是第一步，真正提升体验的是无缝过渡到新数据。
- 开启 proxy_cache_background_update on —— 返回 stale 的同时，Nginx 自动发起异步子请求拉取新响应
- 搭配 proxy_cache_lock on 和 proxy_cache_lock_timeout 3s —— 防止多个并发请求同时触发回源，刷爆上游
- 二者缺一不可：没有 background_update，updating 条件永不满足；没有 cache_lock，高并发下可能造成上游雪崩
