接入层建议4096–8192，网关层可适度降低并重用连接，应用层侧重I/O而非连接数；需按层级压力模型差异化配置，避免资源浪费与雪崩。
在多级 Nginx 代理架构（例如：接入层 Nginx → 网关层 Nginx → 应用层 Nginx）中，worker_connections 不能简单统一设高，而需按层级角色逐级评估、差异化配置。盲目全局拉高不仅浪费资源，还可能因文件描述符竞争、连接复用失衡或后端反压导致雪崩。
明确各层连接模型与压力来源
不同层级的连接行为差异显著，直接影响 worker_connections 的合理取值：
- 接入层（L7 负载入口）：直面海量客户端，连接数高、单连接生命周期短（尤其未开启 keepalive 或超时较短），且每个连接常需建立 1 个上游连接（反向代理）。实际并发 ≈ 客户端活跃连接数 ×（1 + 后端连接开销系数）。
-
网关层（API 网关/路由层）：连接来自上层 Nginx，数量相对收敛；但需做鉴权、限流、聚合等逻辑，单请求耗时更长，连接复用率高；若启用
keepalive到后端，一个 worker 连接池可服务多个客户端请求。 - 应用层（静态服务/边缘缓存）：通常无下游代理，仅响应本地文件或缓存；连接以读取为主，系统瓶颈常在磁盘 I/O 或内存带宽，而非连接数本身。
逐层配置 worker_connections 的关键原则
不追求“最大”，而追求“够用且留余量”，并确保系统级限制同步跟上：
-
接入层：建议设为 4096–8192，配合
worker_processes auto；若 QPS > 5K 且平均连接持续时间 worker_rlimit_nofile 设为 ≥ 2 ×worker_connections×worker_processes，并确认系统ulimit -n≥ 该值。 -
网关层：通常 2048–4096 即可；重点调优
proxy_http_version 1.1+proxy_set_header Connection ''+proxy_pass_request_headers on，再配proxy_max_temp_file_size 0和足够大的proxy_buffering，让连接池真正复用起来——此时worker_connections可低于接入层。 -
应用层：1024–2048 足够；若纯静态资源且启用了
sendfile on和tcp_nopush on，连接数压力极小，优先保障open_file_cache配置，而非堆高worker_connections。
必须同步调整的配套项
只改 worker_connections 是无效的，以下三项必须联动设置：
-
worker_rlimit_nofile应 ≥worker_connections × worker_processes，且推荐略大 10%～20%，防止日志、临时文件等额外 fd 占用挤占连接空间； - 每层 Nginx 的
ulimit -n（系统级）须 ≥ 对应的worker_rlimit_nofile，否则启动时静默降级或报 “Too many open files”； - 所有层级都应启用
multi_accept on和use epoll（Linux），并在http块中统一设keepalive_timeout 60s、keepalive_requests 100，避免短连接泛滥放大连接需求。
验证是否真正扩容成功
重启后别只看配置，要观察运行态指标：
- 用
ss -s | grep "TCP:"查看全系统 ESTAB 连接总数，对比各层预期比例； - 对每层执行
lsof -p $(cat /var/run/nginx.pid) | wc -l，确认打开 fd 数接近但不超过worker_rlimit_nofile； - 检查 error.log 是否仍有
accept() failed (24: Too many open files)或connect() failed (24: Too many open files)—— 前者是监听层受限，后者是 upstream 层受限，定位问题层级很关键。
