multi_accept on 是让每个 worker 进程在事件就绪时批量调用 accept() 取尽内核 listen 队列中的已建立连接，需配合 use epoll;、accept_mutex off、足够大的 worker_connections、内核 somaxconn 与 listen backlog 一致，以及 reuseport（推荐）协同生效。

multi_accept on 并不是让 Nginx “同时接受所有新连接”，而是让每个 worker 进程在一次事件就绪时，尽可能多地调用 accept() 系统调用，把内核 listen 队列里已建立（ESTABLISHED）的连接一次性取完。它本质是减少事件循环和系统调用次数，尤其在短连接洪峰下效果明显。

要让它真正生效，不能只写一行 multi_accept on，必须配合多个关键配置协同工作。

必须放在 events 块中，且顺序不能错

multi_accept 是 events 指令，只能出现在 events { ... } 内部，并且 use epoll;（Linux）或 use kqueue;（FreeBSD/macOS）必须写在它前面：

events {
    use epoll;           # 必须显式指定，select/poll 下 multi_accept 无效
    multi_accept on;    # 放在 use 后面才起作用
    worker_connections 8192;
}

worker_connections 要足够大

如果 worker_connections 设置太小（比如默认 1024），批量 accept() 时超出上限会失败，部分连接被丢弃或返回错误。建议设为 8192 或 16384，并确保系统级文件描述符限制匹配：

ulimit -n 65536  # 启动前设置，或在 systemd service 中配置 LimitNOFILE

关闭 accept_mutex 更适合高并发短连接场景

accept_mutex on 会让多个 worker 争抢一把 accept 锁，反而造成排队；而 accept_mutex off 允许每个 worker 独立、无锁地消费内核 listen 队列——这正是 multi_accept 发挥作用的前提：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

events {
    use epoll;
    multi_accept on;
    accept_mutex off;      # 推荐关闭，避免“惊群”+锁竞争
    worker_connections 16384;
}

内核参数和 listen 指令必须同步调大

multi_accept 能否批量取连接，取决于内核 listen 队列里有没有多个就绪连接。否则“想多取，但没得取”。需三处一致：

• 系统全局：net.core.somaxconn = 65535
• Nginx listen：listen 80 backlog=65535;
• （可选但推荐）半连接队列：net.ipv4.tcp_max_syn_backlog = 65535

注意：backlog 值不能超过 somaxconn，否则以较小值为准。

加上 reuseport 效果更显著

如果你用的是 Nginx 1.9.1+ 和 Linux 3.9+，强烈建议在 listen 后加 reuseport：

server {
    listen 80 reuseport backlog=65535;
    # ...
}

reuseport 让内核在多个 worker 间直接分发新连接，避免单个 listen 队列成为瓶颈；multi_accept 则让每个 worker 把分到的队列“捞干净”。二者一前一后，才是释放多核性能的关键组合。

不复杂但容易忽略