ip_hash不适用于Nginx四层负载均衡，因其仅支持HTTP模块的upstream块；stream模块须改用hash $remote_addr consistent实现客户端长连接绑定，并需通过PROXY protocol透传真实IP。
ip_hash 在 Nginx 四层（TCP/UDP）负载均衡中不生效，不能直接用于 stream 模块实现客户端长连接绑定。Nginx 的 ip_hash 指令仅支持 HTTP 的 upstream 块，对 stream 模块完全无效。
为什么 ip_hash 不能用在四层
Nginx 的 ip_hash 是 HTTP 层专用指令，设计时只解析 HTTP 请求头中的客户端 IP（实际依赖 $remote_addr），而 stream 模块工作在传输层，没有请求头概念，也不解析应用层协议。因此：
-
stream { upstream { ip_hash; ... } }会导致 Nginx 启动失败或静默忽略该指令 - 即使配置了，也不会产生任何会话保持效果
- 官方文档明确限定
ip_hash仅适用于http/upstream
四层 TCP 长连接不漂移的正确做法：用 hash $remote_addr consistent
stream 模块唯一可靠、原生支持的客户端绑定方式是 hash 指令配合 consistent 参数，基于真实源 IP 做一致性哈希：
- 必须写在
stream/upstream块内，且放在server列表之前 - 推荐使用
consistent（一致性哈希），增减后端节点时仅少量连接重映射，避免全量漂移 - 确保
$remote_addr是真实客户端 IP（若前端有 LVS、F5 或代理，需开启proxy_protocol）
示例配置：
upstream tcp_backend {hash $remote_addr consistent;
server 10.0.0.10:3306 max_fails=3 fail_timeout=30s;
server 10.0.0.11:3306 max_fails=3 fail_timeout=30s;
}
server {
listen 3306;
proxy_pass tcp_backend;
proxy_timeout 1h;
}
关键前提：拿到真实的客户端 IP
四层场景下，若上游有代理（如云厂商 SLB、LVS、HAProxy），默认 $remote_addr 是代理地址，所有连接都会被哈希到同一台后端。解决方法：
- 上游代理启用 PROXY protocol v1/v2（发送客户端真实 IP 和端口）
- Nginx stream 块中开启
proxy_protocol on; - 并在 listen 指令后显式声明：
listen 3306 proxy_protocol; - 同时确保上游与 Nginx 之间网络允许 PROXY 协议流量（非 HTTP，需端口开放且无中间设备截断）
对比说明：ip_hash vs hash consistent
两者目标相似，但机制和适用范围完全不同：
-
ip_hash：HTTP 层，取 IPv4 前三段哈希，无 consistency，增删节点必全量重散列 -
hash $remote_addr consistent：stream 层，完整 IP 哈希 + 一致性哈希环，节点变更影响极小，专为长连接设计 - 若业务同时有 HTTP 和 TCP 流量（如 Web + MySQL），需分别在
http和stream块中独立配置对应策略
