multi_accept 的作用是让 Nginx 在单次事件就绪后尽可能多地调用 accept() 消费内核 listen 队列中已建立的连接，避免排队等待；需配合 use epoll 和足够大的 worker_connections 才有效。
multi_accept 指令的作用不是“批量接收连接”，而是让 Nginx 在一次 epoll_wait（或 kqueue、select 等）事件就绪后，**尽可能多地调用 accept() 接收已排队的就绪连接**，避免连接在内核 listen 队列中等待下一轮事件循环。
multi_accept 的真实行为
当设置 multi_accept on; 时：
- Nginx 在收到新连接事件通知后，会持续调用
accept()直到返回EAGAIN或EWOULDBLOCK（表示当前没有更多就绪连接）； - 这能更充分地消费内核 backlog 队列中的已建立连接（SYN 已完成、三次握手结束、处于 ESTABLISHED 状态但尚未被应用 accept 的连接）；
- 它不改变 TCP 握手过程，也不“合并”多个连接请求，更不绕过内核协议栈——只是更激进地从内核队列里取连接。
需要配合 use 和 worker_connections 使用
该指令效果依赖于事件驱动模型和工作进程配置：
- 仅在使用
epoll（Linux）、kqueue（FreeBSD/macOS）等支持边缘触发（ET）或高效就绪通知的模型时才有效； - 若用
select或poll，multi_accept 实际无意义； - 必须结合足够大的
worker_connections，否则即使多 accept，也会因连接数超限而失败； - 建议与
use epoll;显式共用，避免自动探测偏差。
典型 events 块配置示例
以下为推荐写法（Linux 环境）：
events {
use epoll;
multi_accept on;
worker_connections 4096;
accept_mutex off; # 配合 multi_accept 更高效（高并发下减少锁争用）
}注意：accept_mutex off 在启用 multi_accept 时通常更合适，因为每个 worker 可独立、快速消费连接队列，无需互斥等待 accept 权限。
实际影响与适用场景
开启后主要改善两类情况：
- 突发大量短连接（如 HTTP/1.0、健康检查、爬虫探测），减少连接在队列中堆积导致的延迟或丢弃；
- 多核 CPU 下，帮助均衡各 worker 进程的连接负载（尤其配合
accept_mutex off）； - 对长连接（如 WebSocket、HTTP/2）影响很小，因连接复用率高，accept 频次低。
不建议在低并发或调试环境强行开启，无明显收益且可能掩盖 backlog 不足等问题（应同步检查 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 内核参数）。
