Windows版Nginx的1024连接限制源于select()函数硬编码上限，无法通过worker_rlimit_nofile等配置参数解决，必须使用基于IOCP重写的优化版二进制程序或迁移到WSL2运行原生Linux版。
破除1024连接限制不是改一个参数就能解决的事，关键在于系统级、Nginx进程级、事件模型三者对齐。Linux上默认1024是ulimit -n的软限制，Windows上则是select()函数的硬编码上限——两类场景要分清路径，但核心逻辑一致：文件描述符（fd）必须够用，且被Nginx真正拿到。
先确认你卡在哪一层
不是所有“1024错误”都一样：
- Linux报 “accept() failed (24: Too many open files)” → 系统 ulimit 或 worker_rlimit_nofile 没跟上
- Windows报 “maximum number of descriptors supported by select() is 1024” → 标准版Nginx在Win下强制用select，无法绕过
- Nginx启动时警告 “worker_connections is not enough” → 配置值超过当前进程允许打开的fd数，自动被截断
Linux环境：三步对齐法
让 worker_processes × worker_connections 真正生效，必须同步满足三个条件：
- 系统级：/etc/security/limits.conf 中对应运行用户（如 www-data）的 soft/hard nofile ≥ 目标总连接数
例如：4核 + worker_connections 8192 → 总需 32768 fd → 设为 65536 更稳妥 - 进程级：nginx.conf 中 worker_rlimit_nofile 必须显式设置，且 ≥ 单个worker所需最大fd（通常 ≥ worker_connections × 1.2）
- 运行时验证：用 cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files" 查worker进程实际生效值，不是看ulimit -n当前shell值
Windows环境：必须换内核，不能只调配置
标准Windows版Nginx无法突破select的1024上限，调ulimit或worker_connections无效。可行路径只有两条：
- 用社区维护的Windows优化版Nginx（基于IOCP重写事件循环），支持10万+并发，无需改代码，替换二进制即可
- 或彻底迁移到WSL2 + 原生Linux版Nginx，复用全部epoll优化能力
- 切勿尝试在注册表里强行增大FD_SETSIZE——它编译期固化，运行时不可改
别让keepalive拖慢吞吐
设了高worker_connections，但keepalive_timeout太长，会导致大量空闲连接长期占槽，新请求排队失败：
- HTTP/1.1服务建议设为 15–30秒，比默认75秒更利于短连接场景回收
- HTTP/2服务中，http2_max_requests（默认1000）往往比timeout更早触发连接关闭，可适当调高
- 实测观察：用 ss -s | grep "timewait" 看TIME-WAIT数量，持续飙升说明连接释放慢，优先调timeout而非堆connections
