ip_hash是nginx原生会话保持方案，需在upstream块首行配置、依赖真实客户端ip、不支持weight/backup，易受代理/nat/后端变动影响，推荐结合real_ip_module与cookie哈希或redis方案升级。
直接在 upstream 块里加 ip_hash; 就能实现客户端 IP 固定分发到同一台后端服务器，这是 Nginx 原生支持、无需额外模块的方案。
ip_hash 的基础配置写法
只需在 upstream 定义中加入一行指令：
- 确保
upstream块内没有其他负载均衡指令（比如least_conn或hash），否则会冲突 -
ip_hash自动启用，不需要参数，也不用指定哈希字段 - Nginx 默认对 IPv4 使用前三个八位字节（如 192.168.1.x → 192.168.1），IPv6 则用完整地址做哈希
示例配置：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
注意客户端 IP 的真实性
如果 Nginx 前面还有 CDN、SLB 或代理（比如阿里云 SLB、腾讯云 CLB），真实客户端 IP 可能被覆盖为代理 IP，导致所有请求哈希到同一台后端。这时必须配合 proxy_set_header X-Real-IP $remote_addr; 和 set_real_ip_from 指令还原真实 IP：
- 在
http或server块中声明可信代理网段，例如：set_real_ip_from 10.0.0.0/8; - 设置
real_ip_header X-Real-IP;或X-Forwarded-For（依上游实际传入头而定） - 否则
ip_hash会基于代理 IP 计算，失去会话粘性意义
它如何应对后端故障
ip_hash 不是“永久绑定”，而是带容错的会话保持：
- 只要后端服务器健康，同一 IP 总是打到同一台
- 若某台 server 被标记为 down（比如主动
down或健康检查失败），Nginx 会将该 IP 的请求重映射到其他可用节点 - 故障恢复后，哈希逻辑自动回归原分配，但不会自动把已有 session 迁移回原服务器——这点需应用层配合处理（如共享 session 存储）
和 cookie 方案的区别与取舍
ip_hash 简单可靠，但有局限：
- 不适用于 NAT 环境（比如公司出口 IP 统一，多个用户被当做一个客户端）
- 移动端 IP 易变（如切换 Wi-Fi/4G），可能导致会话中断
- 无法跨设备保持（用户换手机就换 IP）
- 若更看重用户级粘性而非 IP 级，建议用第三方 sticky cookie 模块（如
nginx-sticky-module）或应用层 session ID 路由（如 jvm_route）
