worker_connections 与反向代理缓存是协同关系而非包含关系：它限制每个 worker 进程并发连接数，而缓存操作（查询、写入、回源）均占用连接生命周期资源；配置需联动 proxy_buffering、proxy_buffers、proxy_cache_path 等参数，并依据业务特征（如 Harbor 场景）预留余量，通过 $upstream_cache_status 和 stub_status 验证缓存分担效果。
worker_connections 本身不直接参与缓存逻辑，但它决定了每个 worker 进程能同时处理多少连接——而每个连接背后可能触发一次缓存查询、写入或穿透请求。所以它和反向代理缓存是“协同关系”，不是“包含关系”：连接数撑不住，缓存再快也用不上；缓存没配好，连接数再高也容易堆积阻塞。
连接资源要为缓存行为留出余量
启用 proxy_cache 后，Nginx 在处理请求时会多做几件事：检查缓存键是否存在、读取磁盘/内存缓存、校验过期、回源时维持与后端的连接、写入新缓存等。这些操作都占用连接生命周期内的资源（尤其是文件描述符和内存）。如果 worker_connections 设得太紧，高并发下容易出现：
- 缓存未命中时，大量连接同时回源，压垮 upstream，反过来导致 Nginx 连接堆积
- 缓存写入频繁（如小响应体+高更新率），触发临时文件创建和清理，消耗额外 fd
- keepalive 复用失效，短连接激增，更快耗尽 worker_connections 上限
关键配置需联动调优
不能只改 worker_connections，必须同步调整与缓存强相关的参数：
- proxy_buffering on; —— 开启缓冲后，Nginx 可一次性收完后端响应再决定是否缓存，避免边收边传导致连接长期挂起
- proxy_buffers 8 16k; proxy_busy_buffers_size 32k; —— 缓冲区太小会频繁刷盘，增大 I/O 压力；太大则单连接内存占用高，间接压缩可用连接数
- proxy_cache_path ... max_size=10g inactive=60m; —— 磁盘缓存上限和淘汰策略影响后台清理频率，若清理慢会导致 inotify 或 open_file_cache 压力上升，间接占用更多系统资源
- open_file_cache max=10000 inactive=30s; —— 缓存文件句柄可减少 open() 系统调用开销，配合 proxy_cache 能显著降低 fd 消耗
实际值建议参考业务特征
比如一个 Harbor 镜像仓库场景，平均响应体较大（MB 级）、缓存命中率约 70%、回源延迟 8–15 秒：
- worker_connections 可设为 8192～10240（需 ulimit -n ≥ 65536）
- 每个连接平均缓存操作耗时约 2–5ms（查 key + 读缓存），但回源连接可能持续 10s+，所以连接池要预留至少 30% 余量应对缓存失效风暴
- 若开启 proxy_cache_use_stale error timeout，能允许在回源失败时返回旧缓存，避免连接卡死，此时对 worker_connections 的压力反而更可控
验证时别只看连接数
真正要看的是缓存是否在分担连接压力：
- 通过 stub_status 观察 Active connections 中 Waiting 状态是否明显下降（说明缓存响应更快释放连接）
- 用 ss -tan | grep :443 | wc -l 对比开启缓存前后峰值连接数变化
- 检查 log_format 中添加
$upstream_cache_status，统计 HIT / MISS / EXPIRED 比例，MISS 率过高说明缓存没起作用，worker_connections 再高也只是硬扛
