reuseport 优化的是多个 Nginx 工作进程对同一端口的监听竞争，通过内核级哈希分发连接避免惊群效应；需 Linux 3.9+、Nginx ≥1.9.1、worker_processes 匹配 CPU 核数，且同端口所有 listen 必须统一启用。
Nginx 的 listen 指令配合 reuseport 参数，确实能显著提升高并发场景下的连接处理能力，但它的作用对象不是“多虚拟主机”，而是“多个 Nginx 工作进程对同一端口的监听竞争”。理解这一点很关键——虚拟主机（server 块）本身不参与端口绑定，真正绑定端口的是 listen 指令；而 reuseport 优化的是内核如何将新连接分发给多个 worker 进程。
reuseport 解决什么问题？
默认情况下，所有 Nginx worker 进程都调用 listen() 监听同一个地址+端口。当新连接到达时，内核通过一种“惊群”（thundering herd）机制唤醒所有 worker，但最终只有一个能成功 accept()，其余空转。这在高并发下造成 CPU 浪费和延迟抖动。
启用 reuseport 后，内核为每个 worker 创建独立的监听 socket，并基于五元组哈希将新连接直接分发到对应 worker，完全避免争抢和唤醒开销。
如何正确配置 reuseport？
只需在 listen 指令末尾添加 reuseport，且必须确保：
- 运行在 Linux 3.9+（推荐 4.4+），并开启
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog等相关参数 - Nginx 版本 ≥ 1.9.1（官方支持）；若使用 OpenResty，建议 ≥ 1.15.8.2
-
worker_processes auto;或明确设为 CPU 核心数，否则无法发挥多 socket 优势 - 同一 IP:Port 组合的所有
listen行必须统一启用或禁用reuseport，混用会报错
示例配置：
server {
listen 80 reuseport;
listen 443 ssl http2 reuseport;
server_name example.com;
# ... 其他配置
}它对虚拟主机有间接好处，但不改变虚拟主机逻辑
多个 server 块共用一个 listen 80 reuseport 是完全可行的，Nginx 仍按 Host 头或 SNI 匹配对应虚拟主机。reuseport 不影响请求路由，只加速连接接入阶段。因此：
- 并发连接数提升明显，尤其短连接密集场景（如 API 网关、健康检查）
- CPU 利用率更均衡，减少单个 worker 过载
- 首包延迟（time to first byte）更稳定，抖动降低
- 对长连接（如 WebSocket、gRPC 流）收益相对小，因连接建立频次低
需注意的限制与排查点
reuseport 不是万能开关，上线前应验证：
- SELinux 或某些容器环境（如旧版 Docker）可能默认禁止该 socket 选项，需调整策略或升级运行时
- 若配置了
bind、deferred、ssl等其他 listen 参数，需确认兼容性（Nginx 1.17+ 对大部分组合已支持） - 可通过
ss -ltnp | grep :80查看是否出现多个监听条目（每行对应一个 worker 的 socket） - 观察
nginx -t是否报错：“reuseport is not supported on this platform” 表示内核或系统不支持
