ip_hash 是 Nginx 基于客户端 IP 哈希实现会话保持的机制，确保同一 IP 请求始终路由至同一后端服务器；它取 IPv4 前三段或完整 IPv6 地址哈希，不支持 weight、backup，易受 NAT、IP 变更及后端伸缩影响。
在 Nginx 中使用 ip_hash 是实现简单会话保持（Session Persistence）的常用方式，它通过客户端 IP 地址的哈希值决定将请求转发到哪个后端服务器，确保同一 IP 的请求始终落在同一台上游节点上。
ip_hash 的基本用法
只需在 upstream 块中添加 ip_hash; 指令即可启用该机制：
<pre>
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
注意：ip_hash 会自动禁用 weight 配置，所有服务器视为等权重；同时不支持 backup 服务器（即不能标记某台为备用节点）。
ip_hash 的工作原理和限制
Nginx 对客户端 IPv4 地址取前三个字节（如 192.168.1.x → 192.168.1），IPv6 取整个地址，计算哈希值并映射到后端服务器。这意味着：
- 同一局域网出口（如 NAT 网关后）的所有用户会被视为同一个 IP，可能集中到一台后端，造成负载不均
- 客户端 IP 变更（如移动网络切换、DHCP 重分配）会导致会话“漂移”，原有 session 失效
- 后端服务器增减会改变哈希结果，导致大量连接重新分配（不满足一致性哈希的平滑伸缩）
替代方案与增强建议
若业务对会话一致性要求更高，可考虑以下方式：
- 改用
hash $remote_addr consistent;（需 Nginx 1.7.2+），基于一致性哈希减少节点变动影响 - 使用
sticky cookie（需 nginx-plus 或第三方模块如nginx-sticky-module），按浏览器 Cookie 绑定会话，更精准且不受网络拓扑影响 - 后端统一存储 session（如 Redis），前端不做绑定，彻底解耦会话保持逻辑
验证 ip_hash 是否生效
可通过日志或临时调试确认：在 upstream 中为每台 server 添加 down 或注释部分节点，观察同一 IP 的多次请求是否始终访问固定 server；也可开启 Nginx 的 log_format 记录 $upstream_addr，检查日志中目标地址是否稳定。
