proxy_cache_use_stale 是在缓存已存在且过期时跳过回源直接返回旧内容，需满足缓存区定义、键稳定、错误响应入缓存三条件，并配合 background_update 和 cache_lock 实现可靠托底。

当后端服务不可用时，proxy_cache_use_stale 不是“兜底重试”，而是授权 Nginx 在缓存已存在且过期的前提下，跳过回源、直接返回旧内容——前提是整个缓存链路已提前配好，否则它什么也做不了。

只对可信的失败信号启用 stale

后端真正崩溃时，最可靠的表现是主动返回 5xx 状态码。应精准匹配这些语义明确的错误：

• 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 配置路径与 keys_zone，location 中显式写 proxy_cache my_cache
• 缓存键稳定：proxy_cache_key "$scheme$host$request_uri";，剔除 $args、时间戳、随机参数、Cookie 等干扰字段
• 错误响应也要进缓存：proxy_cache_valid 500 502 503 504 1m;，否则后端返回 503 时根本不会落盘，后续 stale 就无内容可返

让托底更可靠：后台更新 + 请求锁

返回旧内容只是起点，真正可用的容灾还需自动恢复能力：

• proxy_cache_background_update on;：返回 stale 的同时，Nginx 自动发起低优先级子请求拉取新响应并写入缓存
• proxy_cache_lock on; proxy_cache_lock_timeout 3s;：同一缓存键下，仅首个请求回源或触发更新，其余请求等待最多 3 秒后直接读新缓存或继续走 stale，防止并发击穿

从客户端视角验证是否真生效

停掉 upstream 后，别只看状态码是不是 200，重点确认三件事：

• 响应头中出现 X-Cache: STALE（需提前配置 add_header X-Cache $upstream_cache_status;）
• 响应体（HTML 或 JSON）与故障前完全一致，不是空页、不是 Nginx 默认错误页
• 响应耗时在几十毫秒内（如 40–80ms），远低于 proxy_read_timeout，说明确实绕过了回源