Nginx Stream模块中hash $remote_addr consistent;实现四层会话保持，基于客户端IP一致性哈希确保长连接稳定落同一后端，避免数据库状态错乱；必须置于upstream块内并显式加consistent参数，否则为普通取模导致扩缩容时大量漂移。
在 Nginx Stream 模块的四层转发中，hash $remote_addr consistent; 是实现客户端连接“会话保持”的核心机制，尤其适用于 Redis、MySQL 等有状态长连接场景。它不依赖应用层协议解析，仅基于 TCP 连接发起方的源 IP 做一致性哈希，确保同一客户端 IP 的所有连接稳定落在同一个后端节点上。
为什么需要 hash $remote_addr consistent？
四层负载均衡默认轮询（round_robin）或最少连接（least_conn），对无状态服务（如 HTTP API）足够友好；但数据库类服务常隐含连接上下文：临时表、用户变量、事务状态、连接级权限缓存等。若请求被随机分发到不同节点，会导致查询失败、逻辑错乱或权限拒绝。一致性哈希能规避这类问题，同时比传统 IP hash 更抗节点增减带来的连接大规模重散列。
配置写法与关键细节
该指令必须写在 upstream 块内，且需显式启用 consistent 参数（否则为普通取模哈希，节点变动时几乎全量漂移）：
-
正确写法：
hash $remote_addr consistent; -
错误写法：
hash $remote_addr;（无 consistent，节点扩缩容时大量连接跳转） - 不能写在 server 块或 http 块中，只能位于 stream → upstream 内部
- $remote_addr 是客户端真实 IP，若前端有 LVS 或云 LB，需确保开启 PROXY protocol 并配置
proxy_protocol on;，否则拿到的是中间代理 IP
实际效果与典型场景
假设 upstream 定义了三台 Redis 节点：
- 客户端 IP 192.168.1.100 的所有连接，始终打到 10.0.0.1:6379
- 客户端 IP 192.168.1.101 的所有连接，始终打到 10.0.0.2:6379
- 当新增一台 10.0.0.4 后，只有约 1/4 的客户端连接会被重新映射，其余保持原路径
这种稳定性对运维变更友好，也避免了应用侧频繁重建连接或处理连接中断异常。
注意事项与常见陷阱
- NAT 环境慎用：多个用户共用一个出口 IP（如企业宽带、运营商 NAT）时，所有用户会被视为同一客户端，流量全部压向单个后端，造成严重倾斜
- IPv6 支持需确认：$remote_addr 在 IPv6 场景下返回完整地址（如 2001:db8::1），Nginx 1.11.0+ 已支持，但旧版本可能截断或报错
- 不解决单点故障：该策略保障“粘性”，但不提供故障自动摘除——开源版 Stream 无原生 TCP 健康检查，需配合外部脚本 + reload 或使用 Nginx Plus
- 权重无效：启用 hash 后，upstream 中的 weight、max_fails、fail_timeout 等参数对调度无影响（仅用于健康标记）
