ip_hash是Nginx基于客户端IP哈希实现的会话保持策略，确保同一IP请求始终路由至同一后端服务器；其原理是对IPv4全地址或IPv6前64位做确定性哈希后取模，但受代理透传、节点增减、NAT环境及无权重支持等限制。
ip_hash 是 Nginx 提供的一种会话保持型负载均衡策略，核心目标是让同一客户端的请求始终落到同一台后端服务器上，无需依赖外部 Session 共享机制。
IP Hash 的实现逻辑
它不是简单取 IP 最后几位做模运算，而是对客户端真实 IPv4 地址（或 IPv6 的前 64 位）执行一个确定性哈希计算，再对后端服务器数量取模，得到固定索引。这个过程保证：相同 IP → 相同哈希值 → 固定服务器节点。
关键细节：
- 只作用于 客户端原始 IP，若前端有 CDN 或代理，需配合
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For解析，否则 hash 的是代理 IP - 哈希结果与服务器列表顺序强绑定：新增或下线一台 server，整个哈希映射会重排，已建立的会话可能被重新分配
- 不支持权重配置，所有 server 视为等权；也不能和
hash、least_conn等其他调度指令混用 - IPv4 地址直接参与计算；IPv6 默认仅用前 64 位，避免哈希空间过大
适合启用 ip_hash 的典型场景
适用于后端应用自身无法共享会话状态，又必须保障单用户请求连续性的服务。
- 传统 Web 应用登录态维持：比如未接入 Redis 或数据库存 Session 的 PHP/Java 应用，依赖本地内存存储 session_id
- 文件上传中间态衔接：分片上传、断点续传类业务，需同一连接持续访问同一节点以维护临时上下文
- 实时通信网关粘性路由：WebSocket 或长连接服务中，用户信令与数据流需绑定固定后端 worker 实例
- 灰度发布期间的用户分流控制：结合 IP 段规则，把某区域用户固定导向特定版本集群（需配合 geo 模块增强）
使用时必须注意的限制
ip_hash 不是万能方案，实际部署中容易踩坑。
- 运营商 NAT 或校园网环境下，大量用户共用出口 IP，会导致流量严重倾斜到某台后端，甚至压垮单节点
- 移动端频繁切换 Wi-Fi/4G，IP 变更后会话中断，表现为“突然登出”或购物车清空
- 扩容缩容操作会触发哈希重分布，已有连接不受影响，但新请求会重新打散，可能引发短暂会话丢失
- 无法应对 IPv6 大量地址变化场景（如 SLAAC 地址自动更新），稳定性低于 IPv4 环境
基础配置写法与验证要点
配置必须放在 upstream 块最上方，且不能换行或加空格干扰解析：
upstream app_cluster {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
}
验证是否生效：
- 用 curl 或浏览器多次请求，检查响应头中
Set-Cookie是否来自同一台机器（如有） - 查看 Nginx access.log，比对不同请求的
$upstream_addr字段是否稳定 - 禁用一台 server 后观察剩余节点分配是否仍保持粘性（Nginx 会自动剔除故障节点并重算哈希）
