worker_connections在长连接场景下限制单worker进程可维持的活跃tcp连接数，需与系统fd限制（file-max）、用户级nofile及worker_rlimit_nofile协同配置，并配合epoll、keepalive_timeout等参数优化。
worker_connections 在长连接场景下，管的是“能维持多少个活跃连接”，不是“能处理多少请求”。它直接决定单个 worker 进程能长期挂起的 TCP 连接数，比如 WebSocket、HTTP-FLV、MQTT 或 HTTP/2 上报通道。真正撑住大规模长连接，靠的不是单独调大这个数字，而是整套资源链协同——从系统文件描述符到 Nginx 事件模型，再到代理超时和内存控制。
必须对齐三层文件描述符限制
每个长连接至少占 1 个文件描述符（fd），而 worker_connections 的值只有在 fd 资源充足时才真正生效。这三者取最小值，任一环节卡住，连接就上不去：
- 系统级总上限：修改 /proc/sys/fs/file-max，建议设为 worker_processes × worker_connections × 1.3～1.5，预留 TIME_WAIT、SSL 缓存、日志等开销
-
用户级限制：在 /etc/security/limits.conf 中为 nginx 用户设置：
nginx soft nofile 65536
nginx hard nofile 65536
若用 systemd，还需在服务文件中加 LimitNOFILE=65536 并执行 systemctl daemon-reload -
Nginx 进程级声明：在 nginx.conf 全局块（events 外）添加：
worker_rlimit_nofile 65536;
该值应 ≥ worker_connections，推荐设为相同或略高（如 1.2 倍）
按长连接类型设合理数值
盲目堆高 worker_connections 会加剧内存压力和上下文切换，还可能触发内核瓶颈。应结合连接生命周期和单连接资源消耗设定：
- WebSocket / HTTP-FLV / RTMP 推拉流：单连接持续数分钟至数小时，fd 占用稳定但总量大。8 核机器常见配置为 worker_processes auto; worker_connections 65535;，理论支撑约 52 万连接，但需后端同步承载
- 高频重连型（如心跳保活客户端）：连接生命周期短但复用频繁，可适当降低至 32768，减少内存碎片
- 单连接内存占用高（如带大 buffer 或自定义 session）：保守设为 16384，并增加 worker_processes 分摊压力
配套 events 和 proxy 参数必须同步调整
只改 worker_connections 几乎无效，必须搭配高效事件机制与连接行为控制：
- use epoll;：Linux 下必须显式指定，避免回退到有 1024 硬限的 select/poll
- multi_accept on;：让一个 worker 在一次事件循环中尽可能多地 accept 新连接，缓解突发流量排队
- keepalive_timeout 65;：保持长连接活性，但不宜超过 90s，防止被中间设备静默断连
- 在 upstream 或 location 块中显式设置：
proxy_read_timeout 86400;
proxy_send_timeout 86400;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
验证是否真正生效，而非仅配置加载
配置 reload 成功不等于连接数提升。要实测确认：
- 用 ss -s | grep "TCP:" 或 netstat -an | grep ESTABLISHED | wc -l 查看当前 ESTABLISHED 连接数
- 启用 stub_status 模块，访问 /nginx_status 查看 Active connections 实时值
- 检查错误日志是否还有 "accept() failed (24: Too many open files)" 或 "worker_connections are not enough"
- 观察内存增长趋势：每万长连接约额外占用 100–300MB（含缓冲、SSL 状态、header 存储等）
