nginx并发连接上限需系统文件描述符、worker_rlimit_nofile和worker_connections三者对齐，缺一不可；仅调高worker_connections会导致“too many open files”错误。
要真正提升单个 Nginx 节点的并发连接上限，worker_connections 必须和系统资源、Nginx 自身声明、内核参数三者对齐——它不是配置文件里一个孤立数字，而是整套资源链路的“最终标尺”。只改这个值，几乎必然卡在 Too many open files 错误上。
打通系统级文件描述符限制
每个 TCP 连接至少占用 1 个文件描述符（fd），而 Linux 默认单进程最多打开 1024 个 fd。若你设了 worker_connections 8192，但 ulimit -n 仍是 1024，那真实上限就是 1024。
- 永久生效：编辑
/etc/security/limits.conf，添加两行（把nginx替换为实际运行用户，如www-data）：nginx soft nofile 65536nginx hard nofile 65536 - systemd 管理的服务还需在
/etc/systemd/system/nginx.service.d/override.conf中加入：[Service]LimitNOFILE=65536
然后执行systemctl daemon-reload && systemctl restart nginx - 验证是否生效：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出软硬限制都应为你设定的数值（如 65536）
同步设置 Nginx 进程级句柄上限
仅靠系统 limits 不够。Nginx 主配置中必须显式声明它能申请的 fd 上限，否则即使系统允许，Nginx 也会自我限制。
- 在
nginx.conf的主上下文（http块之外）添加：worker_rlimit_nofile 65536; - 该值应 ≥
worker_connections，推荐设为相同值或略高（如 1.2 倍），为日志、上游连接等留余量 - 若
worker_rlimit_nofile超过系统硬限制（ulimit -Hn），Nginx 启动会失败或静默降级
匹配内核网络队列与事件模型
连接还没进 Nginx 就被内核丢弃，调高 worker_connections 也无意义。
- 修改
/etc/sysctl.conf：net.core.somaxconn = 65535net.core.netdev_max_backlog = 25000
执行sysctl -p生效 - 在
events块中强制启用高效模型：use epoll;（Linux 下必须显式指定，避免回退到有 1024 硬限的select/poll）multi_accept on;（让一个 worker 在一次事件循环中尽可能多地 accept 新连接）
结合业务类型设合理值
数值不是越大越好。每个连接占用几 KB 内存，过高会加剧内存压力与上下文切换开销。
- 静态资源或短连接 API：可设 4096–16384
- WebSocket、HTTP/2 或直播流长连接：建议 2048–8192，并配合
keepalive_timeout 15–30控制空闲时长 - 反向代理且后端响应慢：连接会在 Nginx 中等待，此时更需优化
proxy_read_timeout和重试策略，而非盲目提高worker_connections
