worker_connections 和 multi_accept 协同提升 Nginx 并发连接处理效率：前者限制单 worker 管理的文件描述符上限，后者在 epoll 下实现批量 accept；需同步调高系统 ulimit、配置 worker_rlimit_nofile、启用 epoll 与 accept_mutex，并匹配内核 somaxconn。
worker_connections 和 multi_accept 一起开启，不是简单叠加效果，而是让 Nginx 更高效地“接住”并发连接——前者定义单个 worker 能管多少连接，后者决定它每次被唤醒时能一口气收下多少新连接。
worker_connections 是连接容量的上限
它表示一个 worker 进程最多能同时管理的文件描述符（fd）数量，包括客户端连接、上游连接、日志句柄、SSL 缓存等。实际可用值受三重限制：
- 系统级 ulimit -n（单进程最大 fd 数），必须 ≥ worker_connections
- Nginx 自身配置的 worker_rlimit_nofile，应 ≥ worker_connections
- 内核总限制 /proc/sys/fs/file-max，建议设为 worker_processes × worker_connections × 1.3～1.5
短连接场景（如 API 上报）可设 16384～65535；长连接或 HTTPS 场景建议不超过 ulimit 的 80%，留出 SSL session、OCSP、证书读取等额外开销。
multi_accept 是连接入口的加速器
它只在使用 epoll 时生效（Linux 2.6+ 默认），控制 worker 在一次事件就绪后是否循环调用 accept() 直到返回 EAGAIN。开启后，Nginx 能一次性从内核 listen backlog 队列中“清空”所有已完成三次握手的连接，避免连接在队列里排队等待下一次 epoll wait。
- 默认关闭：每次只 accept 一个连接，适合低并发或资源敏感环境
- 开启后：显著降低握手延迟，缓解惊群效应，提升突发流量下的吞吐稳定性
- 必须配合 use epoll; 使用，对 select/poll 无效
两者协同的关键配置要点
单独调大 worker_connections 或只开 multi_accept，效果都有限。真正起效需要打通“系统→Nginx→业务”三层：
- 先调高系统限制：修改 /etc/security/limits.conf 和 systemd override，确保 ulimit -n ≥ worker_connections
- 再声明 Nginx 能力：在主配置块设 worker_rlimit_nofile，events 块中设 worker_connections 和 use epoll;
- 最后启用连接收割：events 块中加 multi_accept on;，并确认 accept_mutex on;（默认）防止多个 worker 同时争抢
- 别忘了内核配合：net.core.somaxconn 应 ≥ Nginx listen 指令的 backlog 值（默认 511），建议统一设为 4096 或更高
常见误配与表现
如果只改了 worker_connections 却没调 ulimit，会出现 “too many open files” 错误，新连接静默拒绝；如果开了 multi_accept 但没配 epoll，实际仍走 poll 回退路径，无法批量 accept；如果 worker_processes 设得过大而 CPU 核心少，反而加剧上下文切换开销。
不复杂但容易忽略。
