proxy_cache_use_stale updating 单独无效，必须配合 proxy_cache_background_update on 才能触发后台更新并返回过期缓存；否则请求将超时或返回502/504。
能实现，但“零感”不等于“零延迟”，关键在 proxy_cache_use_stale + proxy_cache_background_update 的组合是否真正触发并稳定运行。
为什么 proxy_cache_use_stale updating 单独无效
很多人配了 proxy_cache_use_stale updating 就以为万事大吉，结果后端一挂，请求直接超时或返回 502。这是因为：updating 不是自动触发的状态，它只在缓存已过期、且 Nginx 正在后台更新该缓存项时才生效——而默认情况下，Nginx 根本不会主动后台更新。
必须显式开启：proxy_cache_background_update on;。否则所谓 “updating” 永远不会出现，proxy_cache_use_stale 就像没写一样。
常见错误现象：
- 后端停掉后，所有请求卡在
proxy_read_timeout（比如 3s），最终返回 504 - 响应头里始终没有
X-Cache: STALE或X-Cache-Status: STALE - 日志里查不到
UPDATING或STALE相关记录
proxy_cache_background_update 的真实行为边界
它不是“定时刷新”，也不是“智能预热”，而是严格遵循一个条件：当前请求命中了一个已过期的缓存项（EXPIRED），且该缓存项满足 proxy_cache_valid 定义的“可被 stale 使用”的前提（比如你写了 proxy_cache_valid 200 302 30s，那 31 秒后就进入 EXPIRED 状态）。
此时，Nginx 才会：
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
- 立即用旧缓存响应当前请求（用户无感知延迟）
- 同时异步发起一个后台子请求去 upstream 拉新内容
- 若后台请求成功，新内容写入缓存；失败则旧缓存继续留着，等待下次触发
注意：后台更新失败不会影响当前响应，也不会导致后续请求降级失败——只要 proxy_cache_use_stale 配了 error timeout http_500...，它依然能兜底。
必须同步配置的三个硬性前提
缺一不可，否则整个链路断在第一步：
-
proxy_cache_path中必须定义keys_zone（如my_cache:10m），这是锁和后台更新共享内存的基础 -
proxy_cache_valid必须明确设置（例如proxy_cache_valid 200 302 30s;），没有这个，“过期”概念不存在，updating和stale都无从谈起 -
proxy_cache_key必须稳定（推荐proxy_cache_key "$scheme$host$request_uri";），避免因$args或$cookie导致同一资源被拆成多个 key，后台更新只刷其中一个，其余 key 仍卡在 EXPIRED 等待手动触发
如何验证是否真正在“平滑降级”
别看配置，直接观测真实行为：
- 加响应头：
add_header X-Cache-Status $upstream_cache_status;，正常流程应依次看到HIT→EXPIRED→STALE（后台更新中）→ 再次HIT（更新成功） - 制造故障：停掉 upstream，用
curl -I /api/data连续请求，观察响应时间是否始终 ≤ 5ms（说明走的是本地缓存），且X-Cache-Status为STALE - 查 Nginx error 日志：后台更新失败时会记
upstream timed out或no live upstreams，但主请求日志里不应有对应错误
最容易被忽略的一点：后台更新本身也受 proxy_next_upstream 和超时控制。如果没配 proxy_connect_timeout 2s、proxy_read_timeout 3s，它可能卡住 worker 进程数秒，反而拖慢其他请求——这会让“平滑”变成“间歇卡顿”。
