内网微服务网关应设worker_connections为8192～32768，而非照搬公网高配；需结合调用RT低、连接复用率高、HTTPS终结等特征，同步调优keepalive、upstream连接池及系统级文件描述符限制。
内网微服务网关场景下，worker_connections不能照搬公网高并发配置，需结合服务间调用特征、连接复用率、上游响应延迟和资源可控性来设定。它本质是“连接槽位管理”，不是越大越好。
先看真实连接压力来源
内网调用通常具备以下特点：RT 低（10–50ms）、协议统一（HTTP/1.1 或 HTTP/2）、TLS 终结在网关层、后端服务普遍启用 keepalive。这意味着单个连接可复用数十甚至上百次请求，实际活跃 socket 远低于理论并发数。
- 若上游平均 RT 为 20ms，单连接每秒可处理约 50 个请求 → 要支撑 10 万 QPS，仅需约 2000 个长连接
- 若未开启 upstream keepalive，每次请求都新建连接 → 同样 10 万 QPS 可能瞬时产生上万短连接，fd 消耗陡增
- 内网环境无 TCP 拥塞、丢包重传等干扰，连接建立成功率高，但 worker 排队风险集中在后端慢响应或熔断降级时
推荐配置范围与依据
不建议直接设 65535。合理起点应落在 8192～32768 区间，并按实测动态收敛：
-
轻量级网关（4核/8GB，QPS ≤ 3 万）：worker_connections 8192；配合
keepalive_timeout 60s和upstream keepalive 32 -
中型网关（8核/16GB，QPS 3–8 万）：worker_connections 16384；启用
multi_accept on和use epoll，accept_mutex on保持默认 -
高密度网关（16核+/32GB+，QPS ≥ 8 万且多租户）：worker_connections 24576～32768；必须同步配置
worker_rlimit_nofile 65536，并确保系统fs.file-max ≥ 131072
注意：HTTPS 终结会额外占用 fd（SSL session cache、OCSP stapling、证书文件句柄），若全站 HTTPS，建议将 worker_connections 控制在单进程 ulimit 的 75% 以内。
必须同步调整的配套项
只改 worker_connections 几乎无效，以下三项缺一不可：
-
系统级限制：为运行用户（如
www-data）在/etc/security/limits.conf中设soft/hard nofile 65536；若用 systemd，补LimitNOFILE=65536到 service override -
Nginx 主进程声明：在
nginx.conf主块（events 外、http 前）加worker_rlimit_nofile 65536;，值 ≥worker_connections -
upstream 连接池：在
upstream块中显式配置keepalive 32;，并在 location 中配proxy_http_version 1.1;和proxy_set_header Connection '';，否则后端连接无法复用
上线后验证是否真生效
reload 成功 ≠ 配置落地。务必检查：
- 运行中 worker 的实际 fd 上限：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"→ 应显示 65536 - 当前活跃连接数：
ss -s | grep "TCP:"中的estab数，对比worker_processes × worker_connections是否接近但未持续打满 - Nginx 状态页：
stub_status中的Active connections若长期 > 80% 且Waiting> 0，说明连接排队，需调高或加 worker 进程 - 错误日志：
error.log是否出现accept() failed (24: Too many open files)—— 这是系统或进程级限制未对齐的明确信号
