ip_hash提供的是确定性映射而非精准调度，即同一客户端ip在后端列表不变时总路由至同一服务器，但受nat、ipv6截断、日志缺失等因素影响稳定性，需通过$upstream_addr日志验证并避免单点失效。
Nginx 的 ip_hash 并不保证“精准调度”，它提供的是确定性映射——同一客户端 IP 在后端列表不变的前提下，总会落到同一台服务器上。这种稳定性常被误认为“精准”，但实际效果受制于网络结构、协议版本和配置细节。
ip_hash 的确定性机制
Nginx 对客户端 IPv4 地址（或 IPv6 前 64 位）做哈希运算，再对当前可用后端数量取模，得出目标 server 索引。只要 upstream 中的 server 列表完全一致（顺序、地址、端口均未变动），映射结果就固定。
- 仅基于源 IP 计算，不考虑请求内容、URL 或 header
- 不支持 weight、backup（除显式声明为 backup 的节点外）、max_fails 自动漂移
- 后端增删一台，所有哈希结果重排，原有会话全部失效
影响“感知精准度”的常见因素
- 用户经 NAT 或代理出口：几十甚至上百人共用一个公网 IP，全被压到同一后端，负载严重不均
- IPv6 地址截断：只取前 64 位哈希，若子网划分较细（如 /128 分配），可能多个不同用户哈希值相同
- 日志未记录 upstream_addr：无法验证实际转发目标，容易误判“没生效”
提升映射可预期性的实操建议
- 在日志格式中加入
$upstream_addr，例如：log_format main '$remote_addr - $upstream_addr - $request'; access_log /var/log/nginx/access.log main;
- 使用真实多 IP 环境测试（避免本地反复刷新），或通过
curl -x指定不同代理 IP 模拟 - 若需容忍节点变更，可搭配 consistent hash 的第三方模块（如
ngx_http_upstream_consistent_hash），但原生 ip_hash 不具备该能力 - 故障时不要依赖自动漂移：ip_hash 下某 server 失效后，其原分配流量不会重分配，而是返回 502；需配合
max_fails=1 fail_timeout=10s快速屏蔽，并人工介入调整 upstream
不复杂但容易忽略。真正上线前，务必在灰度环境验证 IP 分配稳定性与故障转移行为。
