启用reuseport后，每个Nginx worker进程拥有独立监听socket，内核按五元组哈希分发连接，彻底消除惊群效应和accept竞争，显著降低延迟、提升吞吐与CPU利用率均衡性。
直接在 listen 指令后加 reuseport，就能让多个 Nginx worker 进程各自独立监听同一端口，由内核完成连接分发，彻底避开传统模式下的“惊群”和 accept 竞争。这不是锦上添花的调优，而是高并发场景下最值得优先启用的基础能力。
reuseport 解决的核心问题
默认情况下，所有 worker 进程共享一个监听 socket。新连接到达时，内核会唤醒全部 worker，但只有一个能成功 accept，其余空转——这就是“惊群效应”。它造成 CPU 浪费、延迟抖动，尤其在短连接密集（如 API 网关、健康检查、CDN 回源）时尤为明显。
启用 reuseport 后：
- 每个 worker 创建自己的监听 socket，彼此隔离
- 内核按客户端五元组（源IP、源端口、目的IP、目的端口、协议）哈希，把新连接直接路由到指定 worker
- worker 自主调用 accept()，无锁、无唤醒、无竞争
- 相同客户端大概率稳定落到同一 worker，利于连接复用与状态局部性
必须满足的前提条件
reuseport 不是加个参数就自动生效，以下四点缺一不可：
- Linux 内核 ≥ 3.9（生产环境建议 4.4 或更高，如 6.1 已深度优化）
- Nginx ≥ 1.9.1（OpenResty 推荐 ≥ 1.15.8.2），且编译时未禁用 reuseport 支持
-
worker_processes设为auto或明确等于物理 CPU 核心数 - 同一 IP+端口组合的所有
listen行必须统一启用 reuseport —— 比如同时监听80和[::]:80，两条都得写reuseport，混用会导致启动失败
正确配置写法与注意事项
只需在任意 server 块或 http 块中的 listen 指令末尾添加 reuseport 即可，无需值，不支持 reuseport on 这类写法：
示例（HTTP + HTTPS + IPv6 全覆盖）：
server {
listen 80 reuseport;
listen [::]:80 reuseport;
listen 443 ssl http2 reuseport;
listen [::]:443 ssl http2 reuseport;
listen 443 quic reuseport;
listen [::]:443 quic reuseport;
}
关键细节：
- 虚拟主机（server 块）数量不影响配置逻辑，所有共用该端口的 server 都自动受益
- 若绑定多个 IP（如
192.168.1.10:443和192.168.1.11:443），每条 listen 都需单独加 reuseport - 启用后，
accept_mutex自动失效，建议显式关闭：accept_mutex off;（避免冗余锁开销）
配套系统与 Nginx 参数调优
只配 reuseport 效果有限，必须同步放大内核网络队列和资源上限：
-
net.core.somaxconn = 65535（全连接队列上限） -
net.ipv4.tcp_max_syn_backlog = 65535（半连接队列） -
net.core.netdev_max_backlog = 5000（软中断收包队列，防丢包） - Nginx 中对应 listen 显式设
backlog=65535，例如：listen 443 ssl reuseport backlog=65535; -
worker_rlimit_nofile 1048576;，并同步调大系统级fs.file-max和用户级nofile限制 - 启用 CPU 绑定：
worker_cpu_affinity auto;，提升缓存局部性
验证是否真正生效
别只看配置文件，运行态验证才可靠：
-
ss -tlnp | grep ':443'—— 应看到多行输出，每行对应一个 worker 进程 PID（如 16 核应有至少 16 行） -
ps aux | grep 'nginx: worker'—— worker 进程数应与worker_processes一致 - 压测时用
top -H -p $(pgrep nginx)观察各 worker 线程是否在不同 CPU 核上活跃运行 - 观察 error log，确认无
reuseport is not supported或绑定冲突报错
