ip_hash策略通过哈希客户端ip实现会话保持，确保同一ip始终路由至同一后端；但不支持weight、后端变更导致重散列、nat下负载不均、ipv6仅用前64位。
Nginx 的 ip_hash 策略用于实现会话保持（session persistence），即确保同一客户端 IP 的所有请求始终被转发到同一台后端服务器。这在需要依赖本地会话状态的场景中非常关键，比如登录态未集中存储、购物车暂存于内存、或旧版应用不支持共享 session。
ip_hash 的核心机制
nginx 对客户端 IPv4 地址（或 IPv6 的前 64 位）做哈希运算，再对后端服务器数量取模，结果唯一映射到某台 server。只要后端列表不变，同一 IP 总是命中同一节点。
基础配置方法
在 http 块中定义 upstream，并启用 ip_hash 指令：
upstream backend_pool {
ip_hash;
server 192.168.1.101:8080;
server 192.168.1.102:8080;
server 192.168.1.103:8080;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
必须注意的关键限制
- 不能与 weight 混用：ip_hash 不支持权重配置，加了 weight 参数会导致 nginx 启动失败
- 后端列表变更会重散列：增删任意一台 server，原有 IP 映射关系全部打乱，可能导致大量用户会话丢失
- 不适用于 NAT 环境：若用户经企业网关或运营商 NAT 出口，多个真实用户共享一个公网 IP，会被强制路由到同一后端，造成负载倾斜
- IPv6 支持有限：默认只取 IPv6 地址前 64 位参与哈希，需确认业务是否满足一致性要求
增强可用性的实用建议
- 搭配 backup 标识备用节点：当某台 server 故障时，其原分配的 IP 流量不会自动漂移，但可手动标记 backup 节点承接紧急流量
- 启用健康检查参数：虽然 ip_hash 本身不主动剔除故障节点，但可配合 max_fails 和 fail_timeout 让 nginx 在连续失败后临时屏蔽该 server（注意：屏蔽期间对应 IP 请求将返回 502）
- 日志中记录 upstream_addr：添加
log_format main '$remote_addr - $upstream_addr ...';，便于验证 IP 分配是否稳定 - 测试时用不同公网 IP 或代理工具（如 curl -x）模拟多客户端，避免本地反复刷新导致误判
不复杂但容易忽略。真正上线前，务必在灰度环境验证 IP 分配稳定性与故障转移行为。
