worker_connections与keepalive_timeout非等价但协同约束：前者为单worker并发连接硬上限（fd数），后者控制连接空闲驻留时长；二者共同决定实际并发能力与内存效率，需配合系统限制、上下游keepalive及keepalive_requests综合调优。
worker_connections 和客户端长连接保持时间（keepalive_timeout）不是直接等价关系，但存在紧密的资源协同约束：前者决定单个 worker 能“同时持有哪些连接”，后者决定“每个连接能持有多久”。两者共同影响并发连接数上限与内存占用效率。
worker_connections 是连接容量的硬上限
它定义每个 worker 进程最多能打开多少个文件描述符（fd），而每个 HTTP 长连接（无论来自客户端还是发往后端）都占用 1 个 fd。例如：
- 若 worker_processes 为 4、worker_connections 为 20480，理论最大并发连接数是 4 × 20480 = 81920；
- 但实际可用数受系统级限制制约，必须确保 worker_rlimit_nofile ≥ worker_connections，否则会报 “Too many open files”；
- 反向代理场景下，一个客户端长连接 + 对应的一个上游连接，就已占用 2 个 fd —— keepalive_timeout 越长，这些 fd 就越可能长期被空闲连接占据。
keepalive_timeout 控制连接“驻留时长”，间接影响连接池压力
该参数设为 60 秒，意味着 Nginx 在响应发完后，会为该客户端连接保留最多 60 秒空闲期，等待下一个请求复用。这带来两个关键影响：
- 超时设得太长（如 300 秒），在高并发下易积累大量空闲连接，快速耗尽 worker_connections 配额；
- 超时设得太短（如 5 秒），客户端频繁重建连接，三次握手和 TLS 开销上升，反而增加 CPU 和网络延迟；
- 建议值通常为 30–75 秒，具体需结合业务平均请求间隔调整：静态资源多、页面加载快的站点可偏短；API 网关或 WebSocket 辅助场景可适当延长，并配合 keepalive_requests 限频。
二者协同优化的关键配置点
要让长连接真正高效，不能只调其中一个参数，需整体对齐：
- 同步调整系统限制：修改 ulimit -n 并在 nginx.conf 中设置 worker_rlimit_nofile，确保不低于 worker_connections；
- 区分两端 keepalive：客户端侧用 keepalive_timeout，上游服务侧用 proxy_keepalive_timeout + upstream keepalive N，避免单边长连导致连接堆积；
- 限制单连接请求数：搭配 keepalive_requests（默认 100），防止个别连接长期霸占 fd 资源，尤其适用于上传大文件或流式响应场景；
- 监控真实连接状态：通过 nginx stub_status 或 ss -s 观察 ESTAB / TIME-WAIT 连接数，验证是否因 timeout 设置不当引发 fd 泄漏或连接抖动。
典型误配场景与表现
以下组合容易引发问题：
- worker_connections 设为 10240，但 keepalive_timeout 设为 300 秒，且并发用户中 30% 每分钟仅发起 1 次请求 → 大量连接在空闲中“挂起”，实际活跃连接不足 3000，却已逼近 fd 上限；
- 未配置 upstream keepalive，仅调大 client 端 keepalive_timeout → 客户端长连有效，但每次请求仍新建到后端的短连接，worker_connections 压力翻倍且后端负载激增；
- keepalive_requests 设为 0（即不限制），配合长 timeout → 某个异常客户端持续复用连接发送无效请求，阻塞 fd 不释放，影响其他用户。
