ip_hash仅实现ip路由固定，不保障长连接稳定；需确保真实客户端ip可用、规避nat哈希倾斜、配置http/1.1及超时参数（如proxy_read_timeout 86400）、透传upgrade头，并推荐改用hash $remote_addr consistent替代以降低扩容缩容导致的会话漂移。
ip_hash 本身不处理长连接，它只负责把同一个客户端 IP 的请求固定路由到同一台后端。长连接能否稳定维持，取决于你是否补全了协议支持、超时控制和连接复用机制。
确保真实客户端 IP 可用
若 Nginx 前面有 CDN、WAF 或多层代理，$remote_addr 默认是上一跳地址，所有请求会被哈希到同一台后端，ip_hash 彻底失效。
- 在 http 块启用 real_ip_module，并明确可信代理网段：
set_real_ip_from 192.168.0.0/16;
set_real_ip_from 10.0.0.0/8;
set_real_ip_from 172.16.0.0/12; - 指定原始 IP 来源头：
real_ip_header X-Forwarded-For;（仅当上游已去重且可信） - 在 proxy_pass location 中透传真实 IP：
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 验证方式：检查 access_log 中的 $http_x_real_ip 或后端日志，确认为用户公网 IP
规避 ip_hash 固有缺陷对长连接的影响
IPv4 仅取前三段参与哈希（如 192.168.1.100 和 192.168.1.254 被视为相同），NAT 环境下大量用户会挤在一台后端，导致连接堆积、资源争抢，长连接稳定性直接受损。
- 测试环境避免用相同网段虚拟机模拟多客户端（如全为 192.168.1.x）
- 扩容缩容时，用 down 标记临时下线节点，而非直接删 server 行，可保留现有哈希映射，防止会话漂移
- 移动或宽带用户占比高时，建议弃用 ip_hash，改用 cookie 粘滞（sticky cookie）或基于 token 的 header 路由
必须配套长连接关键参数
ip_hash 不等于连接不断。默认空闲 60 秒即断连，WebSocket 或 HTTP 长连接会频繁重建，带来大量握手、TLS 协商开销——这才是高并发下真正的瓶颈。
- 强制使用 HTTP/1.1：
proxy_http_version 1.1; - 透传升级头（尤其 WebSocket）：
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade; - 大幅延长空闲超时（建议设为 24 小时）：
proxy_read_timeout 86400;
proxy_send_timeout 86400; - 避免 keepalive 复用干扰：清除 Connection 头或按需透传，防止与后端协商冲突
更优替代方案：一致性哈希
传统 ip_hash 在节点增减时全量重散列，长连接会话大面积中断。可用 hash + consistent 替代：
- 配置示例：
upstream backend {
hash $remote_addr consistent=1000;
server backend1.example.com;
server backend2.example.com;
} - 一致性哈希能显著降低节点变动带来的映射波动，适合长连接场景
- 注意版本兼容性：需 Nginx 商业版或编译支持 consistent 参数的开源模块
