nginx 1.19.0+原生支持完整ipv6地址哈希，旧版本仅取前64位易致负载倾斜；需升级版本、启用real_ip_module透传真实ipv6地址，并避免ip_hash与weight等参数混用。
Nginx 的 ip_hash 策略原生支持 IPv6 客户端地址，但行为因版本而异：1.19.0 之前只取 IPv6 地址前 64 位哈希；1.19.0 及之后默认使用完整 IPv6 地址参与哈希，更可靠。关键不是“支不支持”，而是配置是否到位、真实地址是否透传、版本是否匹配。
确认 Nginx 版本并升级（必要前提）
低于 1.19.0 的版本对 IPv6 支持有限，建议直接升级：
- 运行
nginx -v查看当前版本，若输出如nginx version: nginx/1.18.0，需升级 - 推荐升级到 1.20.2 或更高稳定版（截至 2026 年 9 月，主流发行版源已同步）
- 升级后验证：
nginx -t && systemctl reload nginx
基础 ip_hash 配置（IPv6 自动生效）
只要版本达标，无需额外开关，ip_hash 对 IPv6 就按完整地址哈希。标准写法如下：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
upstream块首行必须是ip_hash;，且不能缩进 - 后端 server 行只写 IPv6 地址加端口，用方括号包裹：
server [2001:db8::1]:8080; - 不能混用
weight、backup、down等参数，否则启动报错
示例：
upstream backend {ip_hash;
server [2001:db8::101]:8080;
server [2001:db8::102]:8080;
}
确保拿到真实 IPv6 客户端地址
如果前端有 CDN、WAF、SLB 或代理层，$remote_addr 会变成中间设备的 IPv6 地址，导致所有请求哈希到同一台后端——这是 IPv6 下最常见的失效原因。
- 在
http块中启用real_ip_module，明确声明可信代理段：set_real_ip_from 2001:db8::/32;（替换成你实际的代理 IPv6 段）real_ip_header X-Forwarded-For;real_ip_recursive on; - 在
location中透传真实地址：proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 检查 access 日志中
$http_x_forwarded_for字段，应显示类似2001:db8:1::aabb:ccdd的完整 IPv6 地址
更稳的替代方案（推荐用于生产）
即使配置正确，ip_hash 仍存在节点增删导致会话漂移、NAT 共享 IP 负载倾斜等问题。IPv6 环境下建议优先考虑：
- 改用通用
hash指令 +consistent参数：hash $remote_addr consistent;—— 启用一致性哈希，扩容缩容时影响极小 - 基于业务标识哈希，完全规避 IP 问题：
hash $cookie_session_id consistent;或hash $arg_token consistent; - 后端统一存 Session 到 Redis，彻底解耦路由与状态
