worker_connections过小会间接拉长connection start：当全连接队列满而worker无空闲槽位时，已建立连接滞留内核队列，导致客户端重试、超时，浏览器卡在connection start。
worker_connections 本身不直接降低连接建立延迟（Connection Start），但它会显著影响高并发下连接是否能被及时接纳——一旦设得太小，就会把本可快速建立的连接卡在排队队列里，让“Connection Start”从毫秒级拖到秒级甚至超时。
它怎么间接拉长 Connection Start？
当客户端发起 TCP 连接请求（SYN），内核完成三次握手后，把这个已建立的连接放进 全连接队列（accept queue）。Nginx 的 worker 进程需要调用 accept() 把它取出来，分配给一个连接槽位（即占用一个 worker_connections 配额）。
如果所有 worker 进程的连接槽位都满了：
- 新连接无法被
accept()，只能滞留在内核全连接队列中等待 - 队列满后，新 SYN 会被丢弃（或触发重传），浏览器反复重试 → Connection Start 时间飙升
- 浏览器看到的就是“卡在 Connection Start”，尤其在 Chrome/Firefox 等限制同域名 6～8 并发连接的场景下，排队效应更明显
✅ 简单说：
worker_connections不是“建连快慢”的开关，而是“能不能立刻收下已建好的连接”的闸门。闸门太窄，连接就在门口堵着。
哪些情况会让 Connection Start 明显变长？
-
worker_connections × worker_processes 接近或等于当前活跃连接数（可用
ss -s | grep "TCP:"或netstat -ant | wc -l查） - 错误日志出现
accept() failed (24: Too many open files)或worker_connections are not enough -
ss -ltn显示监听端口的Recv-Q持续接近Send-Q（比如1023/1024），说明全连接队列快满了 - 浏览器访问慢、curl 快 —— 典型是浏览器并发受限 + Nginx 接收能力不足双重叠加
怎么配才不拖慢 Connection Start？
确保系统级文件描述符足够
ulimit -n至少 ≥worker_connections × worker_processes × 1.2/etc/security/limits.conf中设nginx soft/hard nofile 65535显式声明进程级上限
在nginx.conf的events块外加：worker_rlimit_nofile 65535;（必须 ≥ 单个worker_connections）-
匹配业务连接模型设值
- 短连接 API（如 H5 接口）：
worker_connections 16384，keepalive_timeout 0 - 长连接服务（WebSocket / HTTP/2）：
worker_connections 8192，keepalive_timeout 30 - 混合云跨机房代理：优先本地 Proxy + 长连接复用，
worker_connections设 32768 更稳妥
- 短连接 API（如 H5 接口）：
-
配套调优不能少
-
use epoll;（Linux 必开） -
multi_accept on;（一次多取，减少排队） -
net.core.somaxconn = 65535（扩大内核全连接队列） -
listen 80 backlog=4096;（让 listen 系统调用有足够缓冲）
-
不复杂但容易忽略
