accept_mutex在Nginx 1.9.1+默认开启，仅对epoll/kqueue生效，启用reuseport时自动失效；需搭配multi_accept on提升吞吐，并受ngx_accept_disabled动态调节影响。
accept_mutex 在现代 Nginx（1.9.1+）中默认开启，它不解决“请求分配绝对均匀”，而是防止多个 worker 同时被唤醒抢 accept 导致的 CPU 浪费和调度抖动；真正影响连接分发均衡度的，是它是否被 reuseport 绕过、是否搭配 multi_accept、以及 ngx_accept_disabled 的动态调节是否起效。
accept_mutex 什么时候起作用、什么时候自动失效
它只在 epoll/kqueue 事件模型下生效，对 select/poll 完全忽略；更重要的是：只要配置了 listen 80 reuseport; 且内核 ≥ 3.9，Nginx 就会静默禁用 accept_mutex——无论你写 accept_mutex on; 还是 accept_mutex off;，它都不参与调度。此时连接由内核直接分发到各 worker 的独立监听 socket 上，完全绕过用户态锁。验证方式很简单：ss -tlnp | grep :80 若看到同一端口对应多个 PID，说明 reuseport 已生效，accept_mutex 不再运行。
multi_accept on 是 accept_mutex 的必要搭档
单独开启 accept_mutex on; 只保证“一次只让一个 worker 去 accept”，但若该 worker 只调用一次 accept() 就释放锁，高并发下会频繁争锁、徒增上下文切换。启用 multi_accept on; 后，抢到锁的 worker 会循环调用 accept() 直到返回 EAGAIN，把当前就绪队列里的连接全收完。这显著降低锁轮转频率，尤其适合短连接洪峰场景。注意：它依赖监听 socket 为非阻塞模式（Nginx 默认满足），否则可能阻塞事件循环。
ngx_accept_disabled 是隐式负载倾斜的关键变量
这个内部变量不是配置项，而是 Nginx 自动计算的软性调节器：ngx_accept_disabled = (worker_connections / 8) - available_connections。当结果 > 0，当前 worker 会主动跳过抢锁，把 accept 机会让给连接更少的兄弟进程。它不依赖外部干预，随每个 worker 实时连接水位自动升降。常见误操作是盲目调大 worker_connections 却未同步提升系统 ulimit -n，导致 available_connections 持续偏低，ngx_accept_disabled 长期为正，部分 worker 彻底“躺平”不抢锁，反而加剧不均。
验证 accept_mutex 是否真正在工作
别信配置文件里有没有那行，用可观测手段确认行为：strace -p $(pgrep nginx | head -1) -e trace=accept,futex -s 32 2>&1 | grep futex —— 如果高频出现 futex(FUTEX_WAIT_PRIVATE)，说明进程在等锁，accept_mutex 正在运行；如果只有 accept() 调用且几乎不触发 futex，大概率走的是 reuseport 内核路径。再配合 pidstat -w -p $(pgrep nginx | head -n 3) 看上下文切换：若某 worker 的 cswch/s 持续高出其他 worker 5 倍以上，说明调度仍不均，需检查是否误配了 poll 模型或 reuseport 绑定失败却无报错。
最易被忽略的一点：容器环境中，即使写了 reuseport，若宿主机未设 net.ipv4.ip_unprivileged_port_start=0，Nginx 会在绑定阶段静默降级回 mutex 模式，且日志里通常不报错——必须用 ss 或 strace 主动验证，不能只看配置。
