ip_hash是最简单直接的session保持方案，需在upstream块首行配置，基于客户端ip哈希绑定后端，但依赖真实ip、不支持weight/backup，易受代理/nat及后端变动影响。
在 Nginx 反向代理中，用 upstream 的 ip_hash 是最简单直接的 Session 保持方案——它让同一客户端 IP 的请求始终转发到同一个后端服务器。
ip_hash 的基本配置方式
只需在 upstream 块中加入 ip_hash; 指令，Nginx 就会基于客户端 IPv4 地址的前三个字节（或整个 IPv6 地址）做哈希，自动绑定到某台后端节点：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
注意：ip_hash 会自动禁用 down 状态的服务器，但不会跳过不可用节点（除非显式标记为 down），且不支持权重（weight）和 backup 参数。
ip_hash 的适用前提和限制
这个方法依赖客户端真实 IP。如果用户经过多层代理（比如 CDN、负载均衡器或公司出口 NAT），Nginx 收到的就不是原始 IP，而是中间代理的地址，导致 hash 失效或大量请求集中到同一台后端。
- 确保
$remote_addr是真实用户 IP；否则需配合real_ip_header和set_real_ip_from解析X-Forwarded-For - IPv6 客户端默认可用，无需额外配置
- 后端服务器数量变动（如增删节点）会导致大部分哈希结果重分布，可能引发短期 session 丢失
替代方案对比（何时不该用 ip_hash）
当业务要求高可用性或后端动态扩缩容频繁时，ip_hash 不够灵活。可考虑：
- Session 外置：把 session 存到 Redis 或数据库，所有后端共享，彻底解耦
-
Cookie-based sticky session：用
sticky cookie（Nginx Plus 功能）或第三方模块如nginx-sticky-module - 基于 token 的无状态设计：JWT 等方案让 session 信息由客户端携带，后端无需存储
验证是否生效的小技巧
可通过日志确认请求是否被稳定路由：
- 开启 Nginx access log，记录
$upstream_addr，观察同一 IP 的请求是否总打到相同后端地址 - 临时加一个响应头
add_header X-Upstream $upstream_addr;，用 curl 或浏览器开发者工具查看 - 注意：本地测试时若走 localhost 或 Docker 网络，多个请求可能来自同一源 IP，容易误判
