multi_accept作用是让worker在一次事件循环中循环accept直至EAGAIN，批量取空内核全连接队列；需配合epoll、reuseport、增大somaxconn及关闭accept_mutex才有效。
multi_accept 指令本身并不能让单个 worker “瞬间接收所有新连接请求”，它只是影响 Nginx 在一次事件循环中是否尝试尽可能多地接受（accept）已就绪的连接，前提是底层系统支持并有多个连接等待被 accept。
真正决定“能否快速接收大量新连接”的，是操作系统内核、socket 队列配置、Nginx 工作模型以及整体负载能力的综合结果。multi_accept 只是其中一环，且效果有限、需配合其他设置才可能显现。
multi_accept 的真实作用
默认情况下（multi_accept off），Nginx 在每次收到 EPOLLIN（或 kqueue 等）通知时，只调用一次 accept() 系统调用。即使此时有 10 个连接同时到达并排队在 listen socket 的 全连接队列（accept queue） 中，Nginx 也只取走 1 个，其余继续等待下次事件触发。
开启后（multi_accept on），Nginx 会循环调用 accept() 直到返回 EAGAIN 或 EWOULDBLOCK，从而一次性取出当前队列中所有已建立的连接。
注意：这不等于“抢在其他 worker 前独占所有连接”，也不改变连接分发逻辑；worker 之间仍通过 惊群（thundering herd）机制或 SO_REUSEPORT（推荐） 协同处理监听套接字。
必须配套的关键配置
-
增大内核连接队列长度：调整
net.core.somaxconn（如设为 65535），否则即使 multi_accept 开启，队列满了新连接也会被内核丢弃（RST）或静默丢弃（取决于net.ipv4.tcp_abort_on_overflow） -
启用 SO_REUSEPORT（Linux 3.9+）：在
listen指令后加reuseport，让内核在多个 worker 的监听 socket 间做哈希分发，避免惊群和锁竞争，显著提升连接接入吞吐 -
关闭 accept_mutex（高并发下建议）：设为
accept_mutex off，允许所有 worker 同时尝试 accept；但需确保已启用reuseport，否则可能引发惊群问题 - 足够大的 worker_connections：每个 worker 能维护的并发连接数上限，要远高于预期峰值连接数
典型高效配置示例
以下片段适用于 Linux 环境下的高并发接入场景：
events {
use epoll;
worker_connections 10240;
multi_accept on;
accept_mutex off; # 配合 reuseport 使用
}
<p>http {
server {
listen 80 reuseport;</p><h1>其他配置...</h1><pre class='brush:php;toolbar:false;'>}}
同时，在系统层面执行：
sysctl -w net.core.somaxconn=65535 sysctl -w net.ipv4.tcp_max_syn_backlog=65535
它不能解决什么
- 不能绕过三次握手耗时——multi_accept 处理的是已完成握手的连接，不是 SYN 包
- 不能替代负载均衡——单机 worker 再快也有物理瓶颈，突发流量仍需上游限流或集群分担
- 不能修复应用层处理慢的问题——accept 得快，但后续 read/write/业务逻辑卡住，连接仍会堆积
- 在低并发或非 Linux 环境下效果微乎其微——例如 macOS 不支持 reuseport，Windows 下 multi_accept 无意义
multi_accept 是一个细粒度调优项，适合在压测发现 accept 效率成为瓶颈（如 ss -s 显示大量 estab 但 synrecv 持续堆积）时启用，并始终配合系统参数与 reuseport 使用。单独打开它，几乎看不到“瞬间接收所有连接”的效果。
