reuseport启用时accept_mutex自动失效，否则默认生效；用ss、nginx-V、strace三命令可直接验证路径：ss显示多PID监听则reuseport生效，strace见futex调用则accept_mutex工作。
accept_mutex 在现代 Nginx（≥1.9.1）+ Linux（≥3.9）环境中，不是“开不开”的问题，而是“有没有被绕过”的问题——它默认生效，但一旦 reuseport 成功启用，就会静默失效，且你写的 accept_mutex on 或 off 都不生效。
如何快速判断当前走的是 accept_mutex 还是 reuseport 路径
别猜，用三个命令直接看内核和进程行为：
-
ss -tlnp | grep :80：若输出中同一端口（如:80）对应多个不同PID，且状态都是LISTEN，说明reuseport已生效；若只看到一个 PID，则走的是accept_mutex协调路径 -
nginx -V 2>&1 | grep -i reuseport：无输出 → Nginx 编译未启用reuseport支持，listen ... reuseport配置会被忽略 -
strace -p $(pgrep nginx | head -1) -e trace=accept,futex -s 32 2>&1 | grep -E "(accept|futex)"：持续看到futex(FUTEX_WAIT_PRIVATE调用 →accept_mutex正在工作；几乎只有accept且无 futex 等待 → 大概率走reuseport内核分发
为什么显式写 accept_mutex off 却没效果
这不是配置失效，而是机制被覆盖：
- 只要配置了
listen 80 reuseport;且内核支持（≥3.9）、Nginx 编译支持、端口绑定无权限限制（如容器中需net.ipv4.ip_unprivileged_port_start=0），Nginx 启动时会自动禁用accept_mutex，无论你配on还是off - 此时每个 worker 拥有独立监听 socket，
epoll_wait监听的是各自 fd，根本不存在“多个 epoll 实例争抢同一 listen_fd”的前提，accept_mutex失去存在意义 - 错误认知：“我关了 accept_mutex，性能应该更好”——实际若未启用
reuseport却关了它，会退回到原始惊群：所有 worker 被唤醒、accept()失败、频繁EAGAIN，上下文切换暴增
multi_accept 和 ngx_accept_disabled 是怎么配合 accept_mutex 工作的
它们不替代 accept_mutex，而是优化其内部效率与负载分布：
-
multi_accept on：让抢到锁的 worker 尽可能一次收完当前就绪队列里的所有连接（循环accept()直到EAGAIN），减少锁释放/重抢频率；默认off，开启后对短连接吞吐提升明显 -
ngx_accept_disabled是运行时变量，值 =max_connections / 8 - available_connections；当该值 > 0（即当前 worker 已用连接数超过总量的 7/8），它会主动跳过抢锁，把新连接机会让给其他 worker —— 这是 Nginx 内置的轻量级自适应负载倾斜，无需人工干预 - 注意：
ngx_accept_disabled只在accept_mutex生效路径下起作用；reuseport下由内核做初始分发，长连接场景可能出现 worker 间连接数偏差，但不会触发惊群
容易被忽略的降级陷阱
看似正常的配置，可能因环境限制静默回退到高风险模式：
- 容器中启用
reuseport但未设置sysctl -w net.ipv4.ip_unprivileged_port_start=0→ 绑定失败，Nginx 日志无报错，但ss显示仅单 PID 监听，实际走accept_mutex；若你还配了accept_mutex off，就彻底裸奔 - 云平台（如某些 Serverless 环境或托管 Kubernetes）网络策略禁止
SO_REUSEPORT→ 配置被忽略，且不提示，nginx -V显示支持也没用 - 误用
poll或select事件模型（通过use poll;强制指定）→accept_mutex被直接忽略，惊群重现；现代 Nginx 默认用epoll，除非显式覆盖，否则不用管
真正关键的不是记住该开哪个开关，而是每次上线前用 ss 和 strace 看一眼——内核和进程在做什么，比配置文件写了什么更真实。
