ip_hash需满足三前提才能生效：必须置于upstream首行、后端至少两台且server行无weight等参数、需通过real_ip_module获取真实客户端IP；其哈希稳定性依赖IP与后端列表不变，增减节点或故障剔除会导致会话漂移。
ip_hash 是 Nginx 原生支持的会话保持方式，它通过客户端真实 IP 地址哈希，让同一 IP 的请求始终转发到同一台后端服务器。但要真正生效，不能只加一行 ip_hash;，必须满足几个关键前提。
基础配置必须规范
ip_hash 必须放在 upstream 块的第一行，且后端至少定义两台 server：
- server 行不能带
weight、backup、max_fails等参数，否则 Nginx 启动会报错 - 每台 server 只写
IP:PORT，例如server 10.0.1.10:8080; - 示例配置：
upstream backend {
ip_hash;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
必须拿到真实的客户端 IP
如果前端有 CDN、WAF、云负载均衡或代理层，$remote_addr 默认是上一跳地址，所有用户会被识别为同一个 IP，导致全部请求打到一台后端——这不是粘性，是雪崩。
- 启用
real_ip_module（Nginx 默认已编译） - 在 http 块中声明可信网段：
set_real_ip_from 192.168.0.0/16;、set_real_ip_from 10.0.0.0/8; - 指定原始 IP 头：
real_ip_header X-Forwarded-For; - 在 location 中透传：
proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
注意它的行为边界
ip_hash 不是“永远不变”的绑定，它的稳定性依赖于两个不变量：客户端 IP 不变 + 后端列表不变。
- IPv4 只取前 3 段哈希（如
192.168.1.x全视为同一 IP），内网 NAT 下容易过载 - 后端增减一台，整个哈希映射会重排，已有用户连接可能“漂移”
- 某台 server 被标记为
down或健康检查失败，Nginx 会自动剔除，对应 IP 请求重新分配到其余节点（会话中断） - 不感知后端实时状态：如果只是响应超时但未触发健康检查失败，请求仍会持续发过去
替代方案更可控（推荐场景）
若业务需要更强的确定性（比如灰度测试、客户专属节点、移动用户频繁换 IP），ip_hash 就不太合适。可改用：
-
Cookie 哈希：
hash $cookie_jsessionid consistent;，不依赖 IP，适合登录态明确的 Web 应用 -
自定义 Header 哈希：
hash $http_x_route_key consistent;，适合微服务间透传路由标识 - map + geo 实现精准绑定：对特定 IP 段或单个 IP 手动映射到指定 server，完全可控
