proxy_cache_background_update 用于缓存过期后仍用旧缓存响应用户，同时后台异步更新；需通过限制并发、缓冲、超时、独立 upstream 及 proxy_cache_lock 等协同控制资源占用。

proxy_cache_background_update 的作用是让 Nginx 在缓存过期后，仍用旧缓存响应用户请求，同时在后台异步拉取新内容更新缓存。它本身不直接提供“优先级控制”参数，但可通过合理配置相关指令，确保后台更新不抢占正常流量资源——关键在于限制后台更新的并发、带宽和超时行为。

控制后台更新的连接与并发量

后台更新本质是 Nginx 主动发起的 upstream 请求，受 proxy_cache_background_update + proxy_cache_use_stale 配合驱动。要避免其影响线上请求，需约束其资源占用：

• 使用 proxy_max_temp_file_size 0 禁用临时文件缓存，防止后台请求堆积大量未读响应体
• 设置 proxy_buffering off（仅对后台更新生效需配合 if 指令或 split_clients，实践中更推荐统一开启 buffering 并调小缓冲区）
• 通过 proxy_buffers 8 64k 和 proxy_busy_buffers_size 128k 控制单次后台请求的内存缓冲上限，避免大响应耗尽 worker 进程内存

限制后台更新的超时与重试行为

后台更新失败或慢速响应会持续占用连接和 worker 资源。应比主请求更激进地设限：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• proxy_connect_timeout 3s：后台更新建立连接不能拖慢整体调度
• proxy_read_timeout 5s：避免上游缓慢流式响应长期占住连接
• proxy_next_upstream error timeout http_500 http_502 http_503 http_504，并搭配 proxy_next_upstream_tries 2 和 proxy_next_upstream_timeout 6s，快速放弃不可靠的后台刷新尝试

隔离后台更新的 upstream 连接池

最有效的资源隔离方式是为后台更新单独配置 upstream，与主流量物理分离：

• 定义两个 upstream：一个用于常规请求（带健康检查、长连接），另一个专供后台更新（精简配置、短连接、独立 keepalive 数）
• 用 map 或 if 判断是否为后台更新（如通过 $upstream_http_x_cache_status 或自定义变量），动态选择 upstream
• 例如：upstream backend_normal { ... keepalive 32; } vs upstream backend_background { ... keepalive 4; }，后者连接数少、复用率低，天然抑制后台更新吞吐

结合 proxy_cache_lock 做请求合并（可选增强）

当多个请求同时触发同一缓存更新时，proxy_cache_lock on 可让首个请求执行回源，其余等待；后台更新启用后，该机制依然有效，且能进一步减少重复回源。注意：

• 必须配 proxy_cache_lock_timeout 5s，防止锁阻塞过久
• 若已启用 proxy_cache_background_update，建议将 lock timeout 设得比 background update timeout 更短，确保锁释放后后台更新继续执行，而非重复抢锁