ip_hash可实现基于客户端IP的会话保持，确保同IP请求固定转发至同一后端；需配置upstream块内ip_hash指令，注意IPv4八位组忽略、不支持weight混用、代理下需real_ip模块配合。
Windows 下 Nginx 的 upstream 模块启用 ip_hash 可实现基于客户端 IP 的会话保持，确保同一 IP 的请求始终转发到同一台后端服务器。这在无共享 Session 机制的场景（如传统 PHP 应用）中很实用。
ip_hash 基本配置写法
在 nginx.conf 的 http 块中定义 upstream，并添加 ip_hash; 指令：
upstream backend {
ip_hash;
server 127.0.0.1:8080;
server 127.0.0.1:8081;
}
注意：ip_hash 会自动忽略 IPv4 地址的最后一个八位组（即对 192.168.1.x 视为同一 IP），但 Windows 下行为与 Linux 一致，无需额外适配。
必须满足的前置条件
- 后端服务器需能稳定响应，否则 Nginx 会临时剔除该节点，导致哈希失效
- 不能与
weight、fair等负载策略混用（ip_hash自带轮询逻辑，不支持权重） - 若使用代理（如公司出口 NAT 或 CDN），真实客户端 IP 可能被覆盖，需配合
real_ip模块和set_real_ip_from正确提取原始 IP
常见问题与绕过方式
Windows 用户常遇到以下情况：
-
本地测试时所有请求都打到同一台后端：因 localhost 或 127.0.0.1 的哈希值固定，建议改用不同局域网 IP 测试，或临时注释
ip_hash验证路由是否正常 -
IPv6 客户端不生效：Nginx 1.19+ 才原生支持 IPv6 hash；旧版本（如 Windows 常用的 1.18.x）下 IPv6 请求会被忽略
ip_hash，退化为轮询 -
后端服务重启后连接中断：
ip_hash不感知后端健康状态变化，需搭配health_check（商业版）或第三方模块（如 nginx_upstream_check_module）增强容错
替代方案参考（当 ip_hash 不适用时）
如果业务需要更精细的会话绑定（如按 Cookie、JWT 或用户 ID），可考虑：
- 使用
hash $cookie_sessionid consistent;实现 Cookie 哈希分发（需客户端支持且 Cookie 稳定） - 引入 Redis + Sticky Session 中间层，由应用统一管理 Session 路由
- 升级至 OpenResty，用 Lua 脚本自定义分发逻辑
