keepalive设成32为什么仍有上百上游连接，怎样区分闲置缓存与并发上限

upstream keepalive限制的是每个worker缓存的闲置上游连接数，不是总并发上限。把它设为32以后看到更多活跃连接并不矛盾；需要另外规划连接、文件描述符和上游承载。

先区分连接在途与闲置两种状态

连接池里至少要区分正在处理请求的连接与等待复用的闲置连接。keepalive的数字主要约束后者，worker数量又会放大总闲置缓存规模。如果把它当作限流器，突发时仍可能打开大量活跃连接，导致上游或本机资源先触顶。

按worker计算缓存容量

实验将缓存刻意设成2，让假上游通过事件屏障同时保持六个请求活跃；实际峰值为6，随后六个响应都是200。这组小并发已经足以反证“keepalive=2总共只能有两个连接”，没有必要向生产服务发压测。另给四worker乘三十二的闲置预算示例为128。

闲置缓存预算还应考虑多个upstream组各自维护缓存，一个组的keepalive数值不能代表所有后端合计。活跃请求完成以后，哪些连接留下复用受协议与头部影响，因此样例显式使用HTTP1.1并清空Connection头。它观测的是活跃峰值，未宣称精确测出了长期闲置连接总数。

结合FD和上游容量制定预算

这个乘积只是理想化闲置缓存预算，不等于活跃与闲置之和，也不是吞吐预测。实际还取决于上游数量、连接复用、超时和请求持续时间。若要控制并发，应按部署能力选择专门的连接限制或应用侧准入策略，并对拒绝与排队行为单独测试。

适用范围：限定少量回环请求与短超时；不做压力测试，不把keepalive算例推成生产最大吞吐。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

附件只并发六条短回环请求，事件屏障让它们在上游同时活跃，随后统一释放。peak_active应为6，而keepalive_idle_cache为2；statuses全部200才说明请求都完成。这个反例足以说明缓存不是总上限，读者无需增加到几千并发来证明同一语义，也不应以小实验测得的时间外推生产承载。

Linux、Python3.8以上与Nginx1.28.0，设置NGINX_BIN为可执行文件绝对路径；鉴权题还需编译启用http_auth_request_module。程序显式指定新建prefix、配置、pid和日志，所有监听均为回环高端口，绝不向已有master发送控制命令。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对Nginx上游keepalive不是并发限制，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（keepalive限制每worker闲置缓存而非总连接；resolve动态DNS需核版本、共享zone与resolver，开源1.27.3前有商业限制。）。

继续阅读：shell的ulimit很高网关仍报too many open files，怎样核对服务进程实际限制；网关上游域名换了IP仍连旧地址，怎样在Nginx核对动态DNS解析；大模型 API 超时与连接管理。