结论：应显式设置ipv6only=on，因ipv6only=off会迫使内核用单socket处理ipv4/ipv6双协议，引发协议识别、地址转换及上下文切换开销，在reuseport下加剧负载不均，云环境还易触发不稳定fallback；而ipv6only=on使ipv4与ipv6监听完全分离，内核可分别优化收包路径，显著降低listenoverflows和listendrops。
直接说结论：在双栈安全网络环境下，应显式设置 ipv6only=on，而非依赖默认或设为 off，才能避免内核级的双重套接字调度损耗。
为什么 ipv6only=off 会引发调度损耗
当 ipv6only=off 时，Nginx 尝试让一个 IPv6 socket 同时接受 IPv4 映射地址（IPv4-mapped IPv6 addresses，如 ::ffff:192.168.1.1）的连接。这要求内核启用双栈 socket 行为——即同一监听描述符需同时处理两类协议报文。但实际中：
- Linux 内核虽支持该模式，但需额外做协议识别、地址转换与上下文切换
- 现代高并发场景下，这种“一拖二”的 socket 会成为调度瓶颈，尤其在
reuseport开启时，worker 进程间负载不均风险上升 - 部分云环境（如阿里云 VPC、AWS EC2）的网络栈对映射地址支持不稳定，易触发 fallback 路径，放大延迟
ipv6only=on 是更干净的双栈实践
设为 on 后，每个 listen 指令严格绑定单一协议族：
-
listen 80;→ 仅 IPv4（等价于listen 0.0.0.0:80;） -
listen [::]:80 ipv6only=on;→ 仅 IPv6，不兼容 IPv4 映射 - 两个独立 socket 并行工作，内核可分别优化其收包路径，无协议混杂开销
配置时的关键细节
不要写成 listen [::]:80 ipv6only=off;，尤其在生产环境：
- 从 Nginx 1.3 起，默认就是
ipv6only=on，显式写出更可靠 - Windows 系统上
ipv6only=off几乎无效，强行使用反而导致监听失败 - 若用
reuseport，必须为 IPv4 和 IPv6 分别启用，例如：listen 80 reuseport;listen [::]:80 ipv6only=on reuseport;
验证是否真正规避了损耗
部署后执行：
-
ss -tln | grep nginx→ 应看到两行：一行0.0.0.0:80，一行[::]:80，无混用 -
cat /proc/net/ipv6_route | wc -l与cat /proc/net/ip_tables_names 2>/dev/null || echo "no iptables"→ 确认无因映射地址触发的额外路由或防火墙链 - 压测时对比
netstat -s | grep -i "TCPExt\|IpExt"中的ListenOverflows和ListenDrops，开启ipv6only=on后应明显下降
