ip_hash 负载均衡下，客户端ip哈希值固定映射后端节点；节点下线时nginx按确定性规则重映射而非简单取模，可通过stub_status或vts模块验证路由稳定性，并用curl模拟ip结合日志排查。
当 Nginx 使用 ip_hash 负载均衡时，客户端 IP 的哈希值决定其固定分发到哪个后端节点。一旦某个节点下线（比如在 upstream 中被标记为 down 或因健康检查失败被临时摘除），Nginx 会重新计算哈希并映射到剩余可用节点——但这个“重新分配”**不是简单地把原哈希值模新节点数**，而是有确定性规律的，可排查、可预测。
ip_hash 的哈希逻辑和节点剔除机制
Nginx 的 ip_hash 对客户端 IPv4 地址做哈希：取 IP 的每个字节（共 4 字节），按公式 hash = ((hash 迭代计算（即乘以 33 再加字节值），最终对当前 <strong>可用节点总数取模</strong> 得到索引。关键点在于：
- 哈希计算过程完全确定，与节点配置顺序强相关
- 取模基数是当前 upstream 中标记为 active（非 down、非 fail_timeout 期内）的节点数量
- 节点下线后，Nginx 不会“平移”或“重排”剩余节点序号，而是按原始配置顺序保留索引位置，跳过不可用节点
如何手动模拟和验证重新分配结果
不依赖线上试错，可通过以下方式精准预判某 IP 在节点下线后的归属：
- 写出 upstream 配置中所有 server 的顺序（含注释掉或 down 的），例如：
server 10.0.1.10:8080;
server 10.0.1.11:8080 down;
server 10.0.1.12:8080;
server 10.0.1.13:8080; - 对目标客户端 IP（如
192.168.5.23）计算 33 进制哈希值（可用 Python 快速算）：h = 0<br>for b in map(int, "192.168.5.23".split(".")): h = (h * 33 + b) & 0xffffffff
得到整数哈希值（如3527123456） - 统计当前可用节点数（比如剩下 3 台），计算
h % 3→ 得到模值（如1） - 遍历原始配置顺序，跳过所有
down或失效节点，取第(模值 + 1)个有效节点（从 0 开始计数）
常见误判场景与排查技巧
实际中容易因忽略细节导致分析偏差：
- IPv6 处理不同：ip_hash 对 IPv6 使用前 64 位哈希，且需确认 Nginx 编译时启用了 IPv6 支持；若混用 IPv4/IPv6 客户端，哈希逻辑不一致
-
健康检查影响时效性：节点虽未配
down，但因max_fails/fail_timeout被临时标记为不可用，此时它不参与取模，但不会从配置中消失——需用nginx -T看运行时生效的 upstream 结构 - 哈希碰撞与分布偏斜：小规模集群（如仅 2–3 节点）下，IP 段集中（如企业出口 NAT）会导致大量 IP 哈希后集中在少数余数上，看似“重新分配不均”，实为哈希本身局限
-
确认是否真走 ip_hash：检查是否有
hash $remote_addr consistent;等其他 hash 指令覆盖，或 location 中存在 proxy_pass 指向了错误 upstream
快速定位线上实际分发行为
在生产环境验证而非猜测：
- 开启 Nginx debug 日志（编译需带
--with-debug），在http块加：error_log /var/log/nginx/debug.log debug;
再触发请求，日志中会输出类似：
upstream hash key: "192.168.5.23" -> 3527123456, value: 1 (using 3 servers) - 配合
stub_status或第三方模块（如nginx-module-vts）查看各 upstream server 的实时请求计数，比对同一 IP 多次请求是否稳定落到同一台（上线/下线前后对比） - 用
curl -H "X-Real-IP: 192.168.5.23" http://your-domain/health模拟指定 IP，结合后端 access_log 中$remote_addr或自定义 header 验证路由路径
