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