proxy_cache_background_update的作用是缓存过期时返回旧内容并后台异步刷新，避免用户延迟；但需通过proxy_cache_use_stale、inactive、upstream连接复用等机制限制并发，防止打垮后端。

proxy_cache_background_update 的作用是：当缓存条目过期但仍有请求到达时，Nginx 会立即把旧缓存返回给客户端，同时在后台异步发起一次新的上游请求来刷新缓存。这能显著降低用户感知延迟，但若不加约束，可能引发大量并发后台更新，尤其在热点 URL 突然失效或批量缓存集体过期时，容易打垮上游服务或耗尽连接资源。

后台更新不是无限制并发的

它本身不直接控制并发数，而是依赖 Nginx 的内部机制做节流：

• 每个缓存 key 对应一个后台更新任务，同一 key 在后台更新进行中时，后续请求不会重复触发新更新（即“去重”）；
• 更新任务共享 worker 进程的事件循环，实际并发度受 worker_connections 和当前活跃连接数影响；
• 没有独立的队列长度或速率限制参数，因此需靠其他配置间接约束。

关键控制手段：用 proxy_cache_use_stale + inactive 组合降频

真正影响后台更新频率的，是缓存条目的“是否被认为过期”以及“是否允许用陈旧响应”。合理设置这两个参数，能大幅减少不必要的后台刷新：

• proxy_cache_valid 200 5m; —— 正常响应只缓存 5 分钟，避免长期 stale 导致频繁更新；
• proxy_cache_use_stale error timeout updating http_502 http_503; —— 明确允许在后台更新中返回旧内容，让客户端不感知；
• proxy_cache_path ... inactive=10m; —— 设定“10 分钟内无访问即清理”，比 proxy_cache_valid 更宽松，防止冷 key 占用空间，也间接减少无效更新压力。

配合 upstream 连接管理防打垮后端

后台更新本质仍是向 upstream 发起新请求，所以必须限制其对后端的冲击：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 在 upstream 块中启用连接复用：keepalive 32;，并配 proxy_http_version 1.1; 和 proxy_set_header Connection '';；
• 设置超时与重试：proxy_next_upstream error timeout http_502; 避免单点故障引发重试风暴；
• 必要时加限流：用 limit_req 限制每秒后台更新请求数（需结合 map 定义仅针对 updating 场景的变量，较复杂但可行）。

验证与观察建议

上线后重点关注两个指标：

• Nginx 日志中 $upstream_cache_status 字段出现 UPDATING 的频率是否陡增（说明大量 key 同时进入后台刷新）；
• 上游服务监控中 499/5xx、连接数、RT 是否在缓存批量失效时刻出现尖峰；
• 用 curl -I 检查响应头是否稳定带 X-Cache: HIT 或 STALE，确认后台更新逻辑按预期工作。

不复杂但容易忽略。核心是让缓存“活得久一点、更新得稳一点”，而不是靠后台更新硬扛流量。