启用ip_hash需在upstream块首行添加指令，且不可与weight、backup等混用；它基于客户端ip哈希实现会话保持，但受nat、ip变更影响大，适合内网稳定环境或临时过渡。

直接在 upstream 块第一行加上 ip_hash; 指令即可启用客户端 IP 哈希算法。

ip_hash 的基本启用方式

必须写在 server 指令之前，且不能与其他负载均衡策略（如 weight）混用：

• 配置示例：

  upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
  }

• 生效逻辑：Nginx 对客户端 IPv4 地址做哈希运算，将同一 IP 的所有请求固定转发到同一台后端服务器
• IPv6 默认只取前 64 位参与哈希；如需完整地址一致性，需确认业务是否兼容

使用 ip_hash 的注意事项

该策略看似简单，但有几个关键限制容易被忽略：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 不支持 weight 参数——加了会启动失败
• 不支持 backup、down 等状态标记与 ip_hash 共存（除非用 least_conn 等替代方案）
• 增删任一 server 行，所有已有 IP 的哈希映射都会重算 → 大量用户会话中断
• NAT 环境（如企业出口、运营商共享 IP）下，多个用户共用一个公网 IP，会导致负载严重倾斜

适合用 ip_hash 的典型场景

它不是万能的会话保持方案，只在特定条件下真正有效：

• 后端服务依赖本地 Session（如未接入 Redis 的传统 PHP 应用）
• 有强本地缓存依赖，且缓存无法跨节点同步
• 内网调用、IP 分布稳定（如公司内部系统），规避 NAT 和动态 IP 问题
• 临时过渡方案：在未改造为无状态架构前，快速解决登录态丢失问题

比 ip_hash 更稳妥的会话保持替代思路

生产环境建议优先考虑更健壮的方案，而非强依赖 IP：

• 后端统一使用 Redis 或数据库存储 Session，彻底解耦会话与节点绑定
• 前端通过 Cookie + JWT Token 携带认证信息，后端无状态校验
• 用 hash $cookie_jsessionid; 或 hash $arg_token; 实现基于业务标识的哈希（需配合应用层生成稳定 token）
• 启用健康检查（max_fails=3 fail_timeout=30s）+ 备份节点（backup），提升整体容错能力