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：连接拒绝、DNS 超时、读取超时可能是瞬时问题，加了反而会让本可成功的请求被降级
-
如需后台刷新：可追加
updating，但必须同步开启proxy_cache_background_update on;，否则该参数无效
确保缓存“有得用、找得着、过得了期”
stale 不创造缓存，只复用已存在的过期项。以下三点缺一不可：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 缓存区已正确定义并被引用：
proxy_cache_path /var/cache/nginx keys_zone=my_cache:512m inactive=3d use_temp_path=off;，并在location中写proxy_cache my_cache; - 缓存键稳定：
proxy_cache_key "$scheme$host$request_uri";——剔除$args、$cookie_、时间戳等动态字段，避免同一资源被拆成多个 key - 5xx 响应也要进缓存：
proxy_cache_valid 500 502 503 504 1m;——否则错误响应根本不会落盘，后续 stale 就无内容可返
让容灾更可靠：后台更新 + 请求锁
单纯返回旧内容只是起点，真正可用的容灾需要“边服务、边恢复”：
-
后台静默刷新：
proxy_cache_background_update on;——返回 stale 的同时，Nginx 自动发起低优先级子请求拉新内容并写入缓存 -
防止并发击穿：
proxy_cache_lock on; proxy_cache_lock_timeout 3s;——同一缓存键下，首个请求负责回源或触发后台更新，其余请求最多等待 3 秒后直接读新缓存（或继续走 stale）
从客户端视角验证是否真生效
停掉上游服务后，不能只看状态码，重点确认三件事：
- 响应头中出现
X-Cache: STALE（需提前配置add_header X-Cache $upstream_cache_status;） - 响应体与故障前完全一致——不是空页、不是 Nginx 默认 502 页面、也不是结构错乱的 JSON
- 响应耗时在几十毫秒内（比如
proxy_read_timeout 3s，实测返回 40–80ms），说明确实绕过了回源
