nginx 1.3.2+起ip_hash原生支持ipv6，完整使用128位地址哈希，无需截断；但需确保真实ipv6地址透传、upstream配置纯净、避免动态扩缩容破坏映射一致性。
IPv6 地址默认已完整参与 ip_hash 计算
从 Nginx 1.3.2 版本起，ip_hash 原生支持 IPv6，且默认使用完整的 IPv6 地址（128 位）进行哈希运算，无需额外配置。这与 IPv4 的“取前三个字节”逻辑不同——IPv6 不做截断，天然更精准。
确认 IPv6 地址未被意外简化
某些场景下，真实 IPv6 地址可能被中间设备（如 CDN、WAF 或云负载均衡器）压缩或匿名化，导致 Nginx 收到的 $remote_addr 并非原始地址。需验证并保障传递完整性：
- 检查上游代理是否透传了原始 IPv6 地址（通常通过
X-Forwarded-For头） - 在 Nginx
http块中启用real_ip_module并正确声明可信段：set_real_ip_from 2001:db8::/32;（替换为你的实际可信 IPv6 网段）real_ip_header X-Forwarded-For;real_ip_recursive on; - 用日志验证：
log_format debug '$remote_addr — $http_x_forwarded_for — $time_local';，确认$remote_addr已还原为用户真实 IPv6 地址
避免干扰配置破坏 IPv6 散列稳定性
ip_hash 对 IPv6 的精准性依赖于 upstream 配置的纯净性。以下任一情况都会导致散列失效或降级：
- upstream 块中出现
weight、backup或其他hash指令（如hash $cookie_id），Nginx 将直接禁用 ip_hash - 后端 server 条目动态增减（如自动扩缩容），会触发全量重哈希，原有 IPv6 客户端映射关系全部失效
- 混用 IPv4 和 IPv6 server 地址时，哈希空间仍统一按活跃节点总数取模，不影响 IPv6 精准性，但整体分布可能不均
验证 IPv6 散列是否生效
用固定 IPv6 客户端（如本地启用 IPv6 的终端或 curl -6）多次请求，观察日志中是否始终命中同一台 upstream：
- 定义日志格式：
log_format ipv6_stick '$remote_addr — $upstream_addr — $request_time'; - 确保 access_log 启用该格式
- 对比多条日志：同一 IPv6 地址（如
2001:db8:1::100）对应的$upstream_addr应完全一致
