ip_hash通过哈希客户端ip实现固定后端路由，保障会话一致性；需置于upstream首行、禁用weight、配合max_fails/fail_timeout提升容错，但受限于nat、ip变动及ipv6兼容性。
Nginx 的 ip_hash 策略本身不直接提升响应速度，但它通过稳定会话路由间接增强交互体验的连贯性与可靠性——尤其在有状态业务中，避免因后端切换导致的重复登录、购物车丢失或 session 失效等问题，从而让用户感觉“更流畅、更可靠”。
ip_hash 如何保障交互一致性
它对客户端 IP 做哈希运算，将同一 IP 的所有请求固定分发到同一台后端服务器。这种确定性路由消除了无状态负载均衡（如轮询）带来的会话漂移风险。
- 适用于登录态依赖本地 session 的应用（如传统 PHP/Java Web 应用）
- 不依赖额外中间件（如 Redis 共享 session），降低架构复杂度
- 对 IPv4 支持稳定；IPv6 需注意 Nginx 1.11.3+ 版本才完整支持
正确配置 ip_hash 的关键点
- 必须放在
upstream块的第一行或紧随其后，否则会被忽略 - 不能与其它 hash 类指令共存（例如
hash $cookie_jsessionid;或least_conn） - 后端服务器若临时下线，Nginx 会自动将其从哈希环中剔除，但原 IP 请求仍尝试路由到该节点，直到重试失败后才转向其他节点（可通过
max_fails和fail_timeout缓解）
upstream backend_pool {
ip_hash;
server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.103:8080 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
注意实际限制与替代建议
- NAT 环境下（如公司出口统一公网 IP），多个用户被映射为同一 IP，会导致流量集中于单台后端，引发负载不均
- 移动网络中 IP 易变（如切换基站、Wi-Fi/蜂窝切换），可能造成会话中断
- 若业务已支持无状态设计（如 JWT + 分布式缓存），优先考虑
least_conn或加权轮询，再配合共享 session 存储，比ip_hash更具弹性与可扩展性
不复杂但容易忽略
