ip_hash原生不支持IPv6，对IPv6地址哈希整个字符串导致会话漂移；应改用hash $remote_addr consistent;或归一化IPv6前缀后哈希。
ip_hash 在 IPv6 环境下出现子网掩码匹配错乱，本质不是 IPv6 地址本身的问题，而是 Nginx 的 ip_hash 指令**原生不支持 IPv6 地址哈希**，它只识别 IPv4 地址的前三个八位组（即 /24 子网），对 IPv6 地址会退化为哈希整个字符串——而这个字符串包含动态生成的接口标识符（如随机后缀、隐私扩展地址）、%zone_id 后缀（如 %eth0），甚至可能含临时地址变化。结果就是同一客户端每次请求的哈希值不同，导致会话漂移、负载不均、连接中断。
确认是否真由 ip_hash 引发
先验证问题根源，避免误判：
- 用
curl -6 -v http://your-domain/多次请求，观察响应头中Set-Cookie或后端日志中的客户端 IP 字段是否稳定； - 检查 Nginx error log，搜索
ip_hash: invalid IPv6 address或类似警告（较新版本可能有提示）； - 对比 IPv4 请求是否稳定（
curl -4），若 IPv4 正常而 IPv6 异常，基本可锁定为ip_hash兼容性问题。
替换为兼容 IPv6 的会话保持方案
Nginx 官方明确说明 ip_hash 不适用于 IPv6。应改用以下任一方式：
- hash $remote_addr consistent;：Nginx 1.7.2+ 支持，对 IPv4 和 IPv6 地址统一做哈希，且启用 consistent 参数可提升一致性哈希的稳定性，适合后端节点动态伸缩场景；
-
hash $http_x_forwarded_for consistent;（需上游透传真实 IPv6）：仅在反向代理链路中可信且已正确设置
X-Forwarded-For时可用，注意防御伪造； -
使用 cookie 保持（sticky cookie）：如
sticky cookie srv_id expires=1h domain=.example.com path=/;（需 nginx-plus 或开源版配合第三方模块如nginx-sticky-module-ng）； - 更稳妥的做法是弃用客户端 IP 哈希，改由业务层发放 token 或 session ID，并通过
hash $cookie_session_id;维持粘性。
若必须保留 IP 级哈希，需预处理 IPv6 地址
可通过 map 指令将 IPv6 地址“归一化”为固定前缀（例如取 /64 网络前缀），再参与哈希：
map $remote_addr $ipv6_prefix {
~^([0-9a-fA-F:]+:[0-9a-fA-F:]+): .+$ $1;
default $remote_addr;
}
upstream backend {
hash $ipv6_prefix consistent;
server 192.168.1.10;
server 192.168.1.11;
}
注意：~^([0-9a-fA-F:]+:[0-9a-fA-F:]+) 是简化匹配，实际建议用更严谨正则（如匹配前 4 组十六进制段），并确保所有 IPv6 地址都经 SLAAC/DHCPv6 分配且使用标准 /64 前缀；否则仍可能因前缀不一致导致哈希分散。
检查上游网络配置是否加剧问题
某些故障表象源于底层网络，而非 Nginx 本身：
- 确认客户端获取的是**稳定全球单播地址**（2000::/3），而非频繁变化的临时地址（privacy extensions）或链路本地地址（fe80::/10）；
- 检查路由器是否正确发送 RA（Router Advertisement）消息，含
managed flag和other-config-flag，确保 DHCPv6 IA_PD 或 SLAAC 前缀分配一致； - 若使用云厂商 LB（如阿里云、AWS ALB），确认其 IPv6 转发模式是否透传真实源地址——部分服务默认做 NAT64 或地址转换，导致 Nginx 收到的
$remote_addr并非原始客户端 IPv6。
