ip_hash可实现基于客户端ip的会话保持，需在upstream块首行配置且不支持weight等参数；依赖真实ip、易受nat和节点变动影响，仅为临时方案，长期应采用redis或jwt等状态共享机制。
直接在 upstream 块里加 ip_hash; 就能启用——它让同一客户端 IP 的请求始终打到同一台后端，从而缓解购物车、登录态等私有状态不一致的问题。但要注意，这只是会话保持，不是真正的状态共享，长期仍需 Redis 或 JWT 等方案。
ip_hash 的核心配置写法
必须放在 upstream 块第一行，且不能缩进：
- 正确示例：
upstream cart_backend {<br> ip_hash;<br> server 10.0.1.10:8080;<br> server 10.0.1.11:8080;<br>} - 错误写法：加了
weight、backup或和其他 hash 指令（如hash $cookie_sessionid）共存，Nginx 启动会失败 - IPv4 默认取前三个字节哈希（如
192.168.1.x和192.168.1.y视为相同），IPv6 则用完整地址
真实 IP 不可用时必须做透传还原
如果前端有 CDN、WAF 或公司 NAT 代理，$remote_addr 就是代理的 IP，直接 hash 会导致所有用户被分到一台后端。这时要配合 real_ip_module：
- 在
http块中声明可信代理段：set_real_ip_from 10.0.0.0/8;<br>set_real_ip_from 192.168.0.0/16;<br>real_ip_header X-Forwarded-For;
- 确保上游代理（如 CDN）确实设置了
X-Forwarded-For，且值为用户原始 IP - 验证方式：在后端打印
$remote_addr，确认已变成真实客户端 IP
搭配健康检查提升稳定性
ip_hash 本身不自动规避故障节点，需显式配置容错机制：
- 每台 server 加上
max_fails=3 fail_timeout=30s，Nginx 会在连续失败后临时剔除该节点 - 注意：节点恢复后不会立即“回流”，新连接才会重新参与哈希分配
- 避免单点雪崩：不要把全部流量压向少量机器；若后端只有两台，扩缩容极易引发大量用户重哈希失联
它解决不了什么？这些坑得提前知道
ip_hash 是权宜之计，不是分布式状态的终极解法：
- 用户换网络（WiFi → 4G）、NAT 共享出口 IP（校园网、企业内网）都会导致状态中断或集中压测
- 后端扩容/缩容时，服务器数量或顺序变化，哈希映射整体重排，大量用户会话丢失
- 不支持 IPv6 原生扩展（除非用
stream模块的hash $remote_addr consistent） - 真正推荐的演进路径：购物车存 Redis + 前端带 token；登录态改用 JWT 无状态校验
