multi_accept 控制 Worker 是否在单次事件循环中持续 accept 直至队列为空；开启后可减少系统调用、降低延迟，需配合 epoll/kqueue 和 accept_mutex 使用，配置于 events 块中。
Nginx 的 multi_accept 指令控制 Worker 进程是否在一次事件循环中尽可能多地接受所有就绪的连接，而不是每次只 accept 一个。开启后，能减少系统调用次数、降低延迟、提升高并发场景下的连接接纳效率。
multi_accept 的作用机制
默认情况下（multi_accept off），Nginx 在 epoll/kqueue 事件就绪后，仅调用一次 accept() 系统调用。若此时有多个连接同时到达并完成三次握手，其余连接会滞留在内核 listen 队列中，需等待下一轮事件循环才能被处理。
启用 multi_accept on 后，Worker 在单次事件循环中会持续调用 accept() 直到返回 EAGAIN（即 listen 队列为空），从而一次性“收完”当前所有已就绪连接。
如何正确配置 multi_accept
该指令必须放在 events 块中，且仅对支持边缘触发（ET）模式的事件驱动模型（如 epoll、kqueue）生效：
- 在
nginx.conf的events块中添加：events {<br> use epoll;<br> multi_accept on;<br> worker_connections 1024;<br>} - 确保
use epoll;显式指定（Linux 下可省略，但显式声明更可靠） - 无需重启整个 Nginx，reload 即可生效：
nginx -s reload
配合 accept_mutex 的协同关系
multi_accept 与 accept_mutex 共同影响连接分发行为：
- 当
accept_mutex on（默认），Nginx 使用互斥锁避免多个 Worker 同时争抢 accept，此时multi_accept on让“获胜”的 Worker 一次性收尽队列中所有连接 - 当
accept_mutex off，多个 Worker 可能同时进入 accept 流程；此时multi_accept on仍有效，但各 Worker 分别清空自己监听到的就绪连接（依赖内核负载均衡策略） - 高并发下建议保持
accept_mutex on+multi_accept on组合，兼顾公平性与吞吐效率
验证 multi_accept 是否生效
直接观测较难，可通过间接方式判断：
- 使用
ss -lnt观察Recv-Q（即 listen 队列积压数），在突发连接请求下，开启multi_accept后该值更接近 0 - 对比开启/关闭时的连接建立延迟（如用
ab或wrk压测），高并发短连接场景下延迟通常下降 5%~15% - 检查 Nginx error 日志是否出现
accept() failed (24: Too many open files)——若频繁出现，说明worker_connections不足，multi_accept反而会加速暴露该瓶颈，需同步调大限制
