ip_hash是Nginx基于客户端真实IP哈希实现会话粘滞的机制，需配置在upstream块中，不支持权重与其它负载策略共存，依赖real_ip_module还原真实IP，存在NAT下负载不均、IPv6兼容性及节点宕机会话中断等局限。
在 Nginx 中，ip_hash 是一种简单有效的会话粘滞（Session Persistence）机制，适用于 HTTP 负载均衡场景。它通过哈希客户端真实 IP 地址，将同一 IP 的请求始终转发到后端同一台服务器，从而避免用户会话丢失（如登录态、购物车等依赖服务端 session 的场景）。
ip_hash 的基本用法和前提条件
ip_hash 必须配置在 upstream 块中，且不能与 hash、least_conn 等其他负载均衡策略共存。Nginx 会自动忽略后续的 weight 配置（即不支持权重分配），所有服务器默认等权重。
注意：客户端 IP 必须是真实公网或局域网地址。如果 Nginx 前面有 CDN、代理或 SLB（如阿里云 CLB、AWS ALB），则收到的可能是代理 IP（如 10.x.x.x 或 127.0.0.1），此时 ip_hash 失效或导致大量请求被分到同一台后端——需配合 real_ip_module 模块还原真实 IP。
正确配置 ip_hash 的典型示例
以下是一个安全可用的配置片段：
upstream backend_cluster {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
若需启用真实 IP 解析（例如前端有 Nginx 或 LVS 代理），还需添加：
# 在 http 或 server 块中
set_real_ip_from 192.168.1.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
ip_hash 的局限性和替代建议
ip_hash 简单但不够灵活，存在几个常见问题：
- IPv4 地址哈希后仅取前 3 段（如
192.168.1.x→ 视为同一 IP 段），导致 NAT 环境（如企业出口、运营商共享 IP）下大量用户被分到同一台后端，引发负载不均 - 不支持 IPv6 原生哈希（旧版本 Nginx 会截断或报错；1.11.0+ 已支持，但仍需确认版本）
- 后端服务器宕机时，Nginx 会自动剔除该节点，但原哈希映射关系被打乱，部分用户会话中断（无自动迁移能力）
- 无法按业务维度（如用户 ID、Cookie）做更精准的粘滞
进阶场景可考虑：
– 使用 hash $cookie_JSESSIONID consistent; 基于应用层 Cookie 实现更稳定的粘滞
– 后端统一使用 Redis 存储 Session，彻底解耦粘滞依赖
– 采用外部服务发现 + 一致性哈希（如基于 etcd + 自定义 upstream）提升弹性
验证 ip_hash 是否生效的方法
最直接的方式是发起多次请求并观察后端访问日志：
- 从同一客户端（固定公网 IP）用 curl 或浏览器反复请求，检查 access.log 中各后端的访问记录是否只出现在某一台上
- 查看 Nginx 错误日志是否有
ip_hash: no valid servers类警告（说明所有 upstream server 都被标记为 down） - 用
nginx -t确保语法正确，特别注意ip_hash不能和keepalive或least_conn同时存在
