least_conn与ip_hash互斥，因Nginx底层peer selection函数不兼容且策略目标冲突；需会话保持时，可采用cookie hash、两级upstream架构或会话亲和+主动驱逐等替代方案。
最少连接（least_conn）和会话保持（如 ip_hash）是两类目标相反的负载均衡机制：前者追求动态资源利用率，后者强调请求路由稳定性。二者不能直接共存于同一 upstream 块——Nginx 明确禁止在启用了 least_conn 的 upstream 中配置 ip_hash，否则启动报错："ip_hash cannot be used with least_conn"。
为什么 least_conn 和 ip_hash 互斥？
Nginx 的 upstream 负载均衡策略在初始化阶段就绑定唯一算法逻辑。least_conn 依赖实时活跃连接数比较，需对所有健康节点做无差别扫描；而 ip_hash 是确定性哈希路由，绕过连接状态直接锁定后端。两者底层 peer selection 函数（ngx_http_upstream_init_least_conn vs ngx_http_upstream_init_ip_hash）不兼容，无法叠加或优先级切换。
需要会话保持时，如何保留 least_conn 的优势？
可采用分层或替代方案，在保障业务连续性的同时，避免连接堆积：
-
用 cookie hash 替代 ip_hash：后端应用在首次响应中写入一致性 cookie（如
route=backend-A），Nginx 使用hash $cookie_route consistent;实现服务端可控的会话粘性，同时允许 upstream 内仍使用least_conn——前提是该 upstream 不参与 hash 计算，而是作为下游子组被调用 -
两级 upstream 架构：外层 upstream 做
ip_hash分流到“会话组”，每组内再定义独立的least_connupstream。例如用户按地区分组，每组含 2–3 台同机房后端，组内用 least_conn 消化突发请求，组间靠 ip_hash 隔离 -
会话亲和 + 主动驱逐：不强依赖固定绑定，改用后端返回
Set-Cookie: session_id=xxx; Path=/; Max-Age=3600，前端携带 session_id；Nginx 配置proxy_cache_key "$scheme$request_method$host$uri$is_args$args$cookie_session_id";并启用缓存，配合least_conn向后转发。当某后端异常时，其 session 自然失效，新请求由 least_conn 重新分配，实现软性会话恢复
哪些场景其实不需要严格会话保持？
很多所谓“需要会话保持”的需求，本质是状态未外部化。建议优先检查：
- 用户登录态是否全放在后端内存？应迁移到 Redis 或 JWT，消除对特定节点的依赖
- WebSocket 连接是否必须固定后端？可通过消息队列+广播机制解耦，让任意节点都能处理后续帧
- 文件上传临时缓存是否本地存储？改为对象存储（如 S3）或共享 NFS，后端无状态化后，least_conn 可自由调度
真正需要强会话绑定的场景较少，多数可通过架构调整释放 least_conn 的弹性优势。硬凑 ip_hash 和 least_conn 不仅无效，还会掩盖真实瓶颈。
