开启 multi_accept on 能显著加快 nginx 在突发流量下接收连接的速度，其机制是让每个 worker 进程在事件就绪后一次性 accept 所有已建立连接，而非每次仅取一个；需配合 use epoll、足够大的 worker_connections 和 accept_mutex off 才能生效，适用于秒杀、活动页等短连接高并发场景。
开启 multi_accept on 能显著加快 Nginx 在突发流量下接收连接的速度，核心是让每个 worker 进程在一次事件就绪后“清空”内核 listen 队列中所有已建立的连接，而不是每次只取一个。
multi_accept 的真实作用机制
它不改变 TCP 握手过程，也不提升最大连接数，而是优化“取连接”这个动作的效率：
- 当内核 listen 队列里有多个已完成三次握手（ESTABLISHED 状态）的连接时，
multi_accept on会让 worker 持续调用accept()直到返回EAGAIN或EWOULDBLOCK，即一次性收完当前就绪的所有连接； - 默认
off时，每次只 accept 一个，其余连接要等下一轮事件循环，容易在洪峰期堆积、延迟升高甚至被内核丢弃； - 这个行为只在
use epoll（Linux）、kqueue（FreeBSD/macOS）等支持高效就绪通知的模型下生效，select和poll下无实际效果。
必须配套的关键配置
单独开 multi_accept 几乎没用，需和以下三项协同：
-
显式启用
use epoll;：避免 Nginx 自动探测降级为低效模型； -
足够大的
worker_connections（如 8192～65536）：确保能容纳批量 accept 过来的连接，否则会因超限失败； -
合理设置
accept_mutex off;：高并发短连接场景下，关闭互斥锁可让多个 worker 并行消费连接队列，减少争抢延迟；若 worker_processes = 1，此项影响不大。
适用与不适用的典型场景
是否开启，取决于你的流量特征：
- 推荐开启：面向公网的活动页、秒杀接口、健康检查集中触发、微服务网关（小报文+高频建连）；
- 影响有限或无需开启：WebSocket、gRPC 流式通信等长连接为主的服务；开发/测试环境或日均 QPS 很低的后台系统；
-
开启前务必检查系统层限制：确保
net.core.somaxconn（内核 listen 队列长度）≥worker_connections，且ulimit -n足够支撑总文件描述符需求。
一个稳妥的 events 块示例（Linux 环境）
以下配置兼顾突发吞吐与稳定性：
events {use epoll;
multi_accept on;
worker_connections 16384;
accept_mutex off;
}
注意：worker_processes 建议设为 auto，并配合 worker_cpu_affinity auto 绑定 CPU 核心，进一步减少上下文切换开销。
