单进程最大连接数受限于worker_connections、系统文件描述符限制（ulimit -n）和内核参数net.core.somaxconn三者最小值；需同步调优配置、系统限制与内核参数，并通过ss -s、lsof及日志验证实际效果。
单进程最大连接数不是简单调大就能提升性能，关键在于系统资源限制、Nginx工作模式与内核参数的协同优化。
确认当前实际可用连接数
Nginx单进程能处理多少并发连接，取决于三个硬性上限中的最小值：worker_connections配置值、操作系统对进程打开文件数的限制（nofile）、以及内核参数net.core.somaxconn和net.core.netdev_max_backlog。直接看nginx -V只能看到编译时的默认值，必须结合ulimit -n和sysctl net.core.somaxconn一起查。
调整worker_connections需同步放宽系统限制
在nginx.conf中设置worker_connections 10240;前，必须确保：
- 每个worker进程的文件描述符上限足够：用ulimit -n 10240临时生效，或在/etc/security/limits.conf中为nginx用户添加nginx soft nofile 10240和nginx hard nofile 10240
- systemd服务需显式覆盖：若用systemd管理，需在/etc/systemd/system/nginx.service.d/override.conf中添加LimitNOFILE=10240
- 内核连接队列不成为瓶颈：执行sysctl -w net.core.somaxconn=65535并写入/etc/sysctl.conf
根据工作模式选择合理数值
非阻塞I/O模型下，并发连接数不等于活跃连接数。高并发短连接场景（如API网关）可设为8192–16384；长连接为主（如WebSocket、HTTP/2）建议控制在4096以内，避免内存占用过高。可通过ss -s观察total: 12345 (kernel 23456)中括号内数字，它反映内核实际维护的socket数量，是比netstat更准确的参考依据。
验证与持续监控不可少
修改后必须验证是否真正生效：
- 重启Nginx后运行curl -I http://localhost确认服务正常
- 用lsof -p $(pgrep nginx) | wc -l查看主进程+worker进程实际打开的文件数
- 压测时关注/var/log/nginx/error.log中是否有accept() failed (24: Too many open files)或connect() failed (111: Connection refused)报错
- 长期运行建议接入Prometheus + nginx-module-vts模块，监控active connections、handled requests等指标变化趋势
不复杂但容易忽略的是：worker_processes auto; 与 worker_connections 的乘积才是全局理论上限，而真实瓶颈往往卡在系统层，不是配置层。
