worker_connections受限于系统文件描述符上限，必须同步调高ulimit -n、worker_rlimit_nofile和worker_connections三者，否则即使配置增大也会因fd耗尽导致“accept() failed (24: too many open files)”错误。
worker_connections 不是独立生效的配置项，它直接受系统文件描述符（file descriptor, fd）限制约束——每个 TCP 连接、每个 upstream 连接、每条日志句柄、每个打开的文件，都占用至少 1 个 fd。Nginx 的每个 worker 进程能维持多少并发连接，本质上就是它被允许打开多少个 fd。
worker_connections 必须 ≤ 单进程 ulimit -n
Linux 默认单进程最多打开 1024 个 fd（ulimit -n 输出值）。若你把 worker_connections 设为 8192，但没调高 ulimit，Nginx 启动时可能不报错，运行中却会反复出现 "accept() failed (24: Too many open files)"，新连接被静默拒绝。
- 查看当前 Nginx 进程实际可用 fd 上限：
cat /proc/$(pidof nginx)/limits | grep "Max open files" - 临时调整（仅当前 shell 有效）：
ulimit -n 65536 - 永久生效需同时配置：
/etc/security/limits.conf（对 nginx 用户或 group）、systemd 服务单元中的LimitNOFILE=65536，并确保 nginx 由 systemd 管理且未被覆盖
worker_rlimit_nofile 是 Nginx 的“自我声明”
这个指令写在 main 块里，作用是让 Nginx 主进程在启动时主动调用 setrlimit()，向内核申请提升自身及子进程（即 worker 进程）的 fd 上限。它不是替代 ulimit，而是配合 ulimit 生效的“内部确认”。
- 必须 ≤ 系统级 ulimit -n，否则启动失败
- 建议设为与 ulimit -n 相同（如 65536），或略小（留 1–2 个给主进程自身使用）
- 典型配置：
worker_rlimit_nofile 65536;（放在 events 块外、http 块外的 main 区域）
真实并发上限 = worker_processes × worker_connections，但受 fd 总量硬性卡死
例如 8 核服务器设 worker_processes auto;（即 8 个 worker），worker_connections 8192，理论支持 65536 连接。但这要求：
- 每个 worker 进程的 fd 上限 ≥ 8192（即 ulimit -n ≥ 8192）
- 整个 Nginx 进程组总 fd 需求 ≈ 8 × 8192 = 65536，因此系统 ulimit -n 至少要设为 65536
- 反向代理场景下，一个客户端请求常对应 2 个连接（client + upstream），fd 消耗翻倍，需额外预留余量
- 内核参数
fs.file-max（系统级总句柄数）也应远高于该值，避免全局耗尽
常见误判与验证方式
看到 "worker_connections are not enough" 错误，第一反应不该是加数字，而是查 fd 是否真的够用。错误本质是 fd 耗尽，不是连接池逻辑不足。
- 检查 error.log 中是否混有 "Too many open files" 或 "accept() failed"
- 用
ss -s查看当前 TCP 连接总数，对比nginx -T | grep worker_connections和ps -eo pid,comm,rlimit | grep nginx - 启用 stub_status 模块，观察
Active connections是否长期逼近配置上限，同时 CPU/内存空闲——这是典型的 fd 瓶颈特征
