ip_hash是Nginx原生会话持久化机制，通过哈希客户端IPv4前三段或IPv6完整地址并取模实现请求固定路由，适用于内网稳定IP等场景，但依赖真实IP识别、后端稳定且不支持weight等参数。
ip_hash 是 Nginx 原生支持的会话持久化机制，它不依赖外部存储或额外模块，靠客户端 IP 地址哈希后固定路由到某台后端服务器，适合内网环境、文件分片上传、断点续传等需要服务端状态连续的场景。但它不是“万能粘性方案”，实际效果高度依赖网络拓扑、IP 分布和后端稳定性。
ip_hash 的核心行为与前提
它对客户端 IPv4 地址取前三个字节（如 192.168.1.x → 视为 192.168.1），IPv6 则使用完整地址（需 Nginx ≥1.19）。哈希结果对当前 upstream 中存活 server 数量取模，决定转发目标。这意味着：
- 只要客户端 IP 不变、后端列表未增删，请求就始终落在同一台 server 上
- 后端节点被标记为 down 时，Nginx 会临时剔除它，剩余节点上的 IP 映射关系保持不变
- 若某台 server 彻底下线（配置中删除），所有哈希取模基数改变，原有映射全部失效，大量用户会话漂移
- 不支持 weight、backup、max_fails 等参数——加了就会启动失败或被忽略
真实 IP 识别是落地前提
在 CDN、NAT 或多层代理后，$remote_addr 往往是中间设备 IP，直接用它做哈希会导致大量用户被误归为同一 IP 段。必须还原真实客户端地址：
- 配置可信代理网段：set_real_ip_from 10.0.0.0/8; set_real_ip_from 192.168.0.0/16;
- 指定原始 IP 来源头：real_ip_header X-Forwarded-For; 或 X-Real-IP（依上游实际传递为准）
- 同时在 proxy_pass 前设置：proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
生产级配套调优不可省略
仅加 ip_hash 远不足以支撑高并发、大流量业务。尤其涉及文件上传或长连接时，需同步调整：
- 关闭响应缓冲：proxy_buffering off;（防止大文件上传内存堆积）
- 延长超时：proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300;
- 放宽体大小限制：client_max_body_size 10G;
- 启用 upstream 连接池：upstream 内加 keepalive 32; 并在 location 中设 proxy_http_version 1.1; proxy_set_header Connection '';
常见失效场景与替代建议
以下情况会让 ip_hash 失效或引发问题：
- 运营商 NAT 或校园网出口：成百上千用户共用一个公网 IP，全被压到同一后端 → 改用 hash $cookie_jsessionid consistent; 更可靠
- 需要权重调度：ip_hash 不支持 weight → 改用 hash $remote_addr consistent; 并配 weight 参数
- 四层（TCP/UDP）负载均衡：ip_hash 仅限 HTTP upstream → stream 模块中改用 hash $remote_addr consistent;
- IPv6 兼容性不足：旧版 Nginx 对 IPv6 处理不一致 → 升级至 1.19+ 并验证日志中 client IP 解析正确
