ip hash 策略不直接控制连接池复用，但会因连接归属混乱而降低复用效率；正确做法是为每个后端 ip 单独定义 upstream 并禁用负载策略，实现专属连接池。
IP Hash 策略本身不直接控制连接池复用，但它会间接影响复用效果——关键在于它是否导致连接归属混乱或池隔离失效。
IP Hash 会干扰“每 IP 独立连接池”的建立
当多个后端节点共用同一个 upstream 块并启用 ip_hash 时，Nginx 仍只维护一个连接池（按 upstream 名称划分），但请求会被哈希到不同 server。这意味着：
- 同一客户端 IP 固定打向某台后端，看似“稳定”，但 Nginx 不会为每台后端单独建池；所有空闲连接混存在一个池里
- 若后端节点健康状态不一（如一台响应慢、一台常超时），连接池容易被低效连接占满，新请求可能被迫新建连接
- ip_hash 与 keepalive 共存时，Nginx 无法保证“同一后端的连接始终复用”，因为连接分配受哈希结果和当前可用连接双重影响
真正支持连接复用的正确做法是“单 IP 单 upstream”
要实现对特定后端 IP 的透明、高效复用，必须绕开 ip_hash 的调度逻辑：
- 为每个目标 IP 单独定义一个 upstream（如 upstream backend_10_0_1_5 { server 10.0.1.5:8080; keepalive 32; }）
- 通过 map 或 if 判断请求特征（如 Host、Header、URI），路由到对应 upstream
- 该 upstream 内不启用任何负载策略（ip_hash/least_conn/weight 都禁用），确保连接池完全专属
ip_hash 只适合会话保持，不适合连接优化
它的设计目标是把用户“粘”住，不是为了提升连接效率：
- 若后端是无状态服务（如 REST API），用轮询或 least_conn 更利于连接复用
- 若后端有状态（如 Session 存内存），ip_hash 是权宜之计；长期应改造为无状态 + 外置 Session 存储
- 在数据库代理、固定网关等单点后端场景下，ip_hash 完全没必要——直接单节点 upstream + keepalive 即可
不复杂但容易忽略：连接复用靠的是“池隔离 + 协议净化 + 生命周期匹配”，不是靠调度算法。ip_hash 属于调度层，不该越界管连接层的事。
