开启proxy_cache_background_update on后，Nginx在返回过期缓存内容的同时后台异步更新，解决缓存失效瞬间并发回源导致的雪崩、响应毛刺及后端压力陡增问题，需配合proxy_cache_valid和proxy_cache_use_stale updating生效。
开启 proxy_cache_background_update on 后，Nginx 会在返回过期缓存内容的同时，悄悄在后台发起新请求去更新缓存。用户几乎感觉不到延迟，后端压力也更平滑——这不是“强行用旧数据”，而是有策略的容灾与体验优化。
它解决什么实际问题
典型场景下，缓存刚过期那一瞬间，大量并发请求涌来，全都卡在等待上游响应上，容易引发雪崩或响应毛刺。
- 用户刷新页面时，发现首页加载突然变慢（缓存失效 + 多人同时触发回源）
- 第三方 API 响应慢或偶发超时，导致前端接口整体延迟飙升
- 报表类接口每分钟刷新一次，整点时刻回源请求扎堆，数据库/后端服务 CPU 瞬间拉满
关键配置必须配套才生效
单独打开 background_update 不起作用，需和以下指令协同：
-
必须定义
proxy_cache_valid：明确告诉 Nginx 哪些状态码缓存多久，否则无法判断“是否过期” - 建议启用
proxy_cache_use_stale updating
-
推荐配合
proxy_cache_lock on：避免多个相同请求同时触发后台更新，只让第一个发起，其余直接复用即将更新的旧缓存
没有 use_stale updating，即使开了 background_update，Nginx 也不会把过期内容返回给客户端——它会等后台更新完再返回，那就失去“静默更新”的意义了。
真实请求流是怎么走的
假设缓存 key 对应资源已过期（比如 proxy_cache_valid 200 60s，当前已过去 65 秒）：
- 第 1 个请求到达：Nginx 立即返回当前缓存内容（命中
$upstream_cache_status = STALE），同时异步发起后台请求回源 - 第 2–10 个并发请求到达：全部立刻返回同一份过期缓存（不排队、不等待），
STALE状态持续可见 - 后台请求完成并写入新缓存后，下一个请求开始命中
HIT，整个过程对用户透明
调试与验证技巧
加这一行头，方便快速确认行为是否生效：
add_header X-Cache-Status $upstream_cache_status;
用 curl 测试时观察响应头：
-
X-Cache-Status: HIT→ 缓存新鲜可用 -
X-Cache-Status: STALE→ 正在用过期内容 + 后台更新中 -
X-Cache-Status: MISS→ 完全没缓存，或被 ignore_headers 干扰
注意：STALE 出现的前提是配置了 proxy_cache_use_stale updating，否则你看到的可能是 MISS 或直接阻塞等待。
