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 脚本自定义分发逻辑