reuseport 作用于内核调度层而非虚拟主机层，通过让多个 worker 进程无竞争地监听同一端口，提升所有共用该端口的虚拟主机连接接入能力，实测连接吞吐可提升约3.8倍。
listen reuseport 并不作用于“虚拟主机层”，它作用于连接接入阶段的内核调度层。理解这一点，是正确配置和获得收益的前提。
很多人误以为 reuseport 是为多个 server 块（即多个域名、多个虚拟主机）设计的优化，其实不是。Nginx 的 server 块本身不监听端口，真正绑定端口的是 listen 指令；而 reuseport 优化的是：多个 worker 进程如何高效、无竞争地监听同一个 IP+端口组合。
所以，“在虚拟主机层提升吞吐”这个说法需要修正——它其实是：通过 reuseport 让同一端口上承载的全部虚拟主机（无论几十个还是上万个），共享更高、更均衡的新连接接入能力。
它怎么间接提升多虚拟主机场景的吞吐？
当你有大量 server 块共用 listen 80 或 listen 443（比如 SaaS 平台托管数百个租户域名），所有请求都先经过连接建立阶段。此时：
- 若未启用
reuseport，所有 worker 进程争抢 accept 同一个 socket，高并发下出现惊群、CPU 空转、延迟抖动； - 启用后，内核按客户端五元组哈希，把新连接直接分发到某个 worker，该 worker 独立完成 accept → SSL 握手 → HTTP 解析 → server_name 匹配 → 路由到对应虚拟主机。
也就是说：
✅ 虚拟主机逻辑完全不变（仍靠 Host 头或 SNI 匹配）
✅ 所有 server 块自动受益于更快、更稳的连接接入
✅ 短连接密集型场景（如 API 网关、健康检查探针、CDN 回源）吞吐提升最明显
实测在 32 核服务器上，连接建立吞吐可提升约 3.8 倍，首包延迟抖动显著降低。
正确配置方式（聚焦虚拟主机场景）
你只需在任意 server 块的 listen 行末尾加上 reuseport，Nginx 会自动让所有同端口的监听实例（包括 IPv4/IPv6、HTTP/HTTPS/QUIC）统一启用：
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_name example.com *.tenant.io;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
location / {
proxy_pass http://backend;
}
}⚠️ 注意：
- 所有监听同一端口的
listen行（含不同 IP、协议、地址族）必须全部带reuseport，混用会启动失败； - 不用给每个
server块单独加——只要有一个server启用了，且端口相同，其他同端口的listen也默认继承行为（Nginx 内部统一管理）； -
reuseport是布尔修饰符，不要写成reuseport on或reuseport=on。
必须同步做的配套调优
单加 reuseport 效果有限，需三方面协同：
1. 内核参数拉满
# 写入 /etc/sysctl.conf 并执行 sysctl -p net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.core.netdev_max_backlog = 5000
2. Nginx 进程与资源对齐
worker_processes auto; # 推荐，自动匹配物理核心数
worker_rlimit_nofile 1048576; # 配合系统级 fs.file-max 和 ulimit
events {
use epoll;
accept_mutex off; # reuseport 已解决争抢，关掉避免冗余锁
multi_accept on;
}
http {
# 显式设置 backlog，匹配 somaxconn
server {
listen 80 reuseport backlog=65535;
# ...
}
}3. 验证是否真正生效
# 应看到多个 nginx worker 各自监听 :80 ss -tlnp | grep ':80' # 查看 worker 数量是否匹配 CPU 核心数 ps aux | grep 'nginx: worker' # 检查 error log 无 "reuseport is not supported" 类报错
它不适合什么场景？
- 纯长连接服务（如 WebSocket 网关、gRPC 流）：连接建立频次低，收益不明显；
- 单核 CPU 或 worker_processes = 1：无多进程竞争，启用无效；
- 内核 ：不支持，配置会被忽略或报错；
- 动态扩缩容频繁的 Serverless 环境：哈希重分布可能导致握手失败（需配合连接平滑迁移策略）。
不复杂但容易忽略。
