HAProxy 扩容后新节点流量很少：会话 Cookie 仍绑定旧节点

HAProxy 后端从五台扩到六台，配置仍是 balance roundrobin，新节点却只收到少量请求。若同时启用了 cookie SERVER insert indirect nocache，已有客户端会继续根据持久化 Cookie 回到原节点，不会因新增服务器就平均迁移。

先区分后端不可用与会话保持。新节点已经健康且新客户端能进入时，应检查请求携带的 Cookie；如果新节点是 DOWN、权重为零或未进入当前运行配置，先处理那些条件。

有 Cookie 的请求不等同于新请求分配

下面仅是 HTTP 后端结构示例：

backend app
    mode http
    balance roundrobin
    cookie SERVER insert indirect nocache
    server app1 10.0.0.11:8080 cookie app1 check
    server app2 10.0.0.12:8080 cookie app2 check
    server app3 10.0.0.13:8080 cookie app3 check

Cookie 将客户端与具体服务器关联。roundrobin 用于需要按算法选择服务器的请求，不会自动重分配仍有效的会话关联。把算法改为 leastconn 也不会立即搬走这些已绑定的请求。

检查当前运行状态及新节点健康结果，再比较有、无这枚持久化 Cookie 的受控请求。可使用独立浏览器会话判断新客户端能否进入新节点，并观察服务器日志或现有统计；不要为了测试清掉所有用户的应用登录 Cookie。

indirect 会避免将这枚持久化 Cookie 继续交给后端应用，它不会取消 HAProxy 对 Cookie 的路由判断。还应确认持久化 Cookie 名称没有与应用自己的 Cookie 冲突。

可以限制绑定时间，但先确认会话允许迁移

如果应用登录状态保存在各节点本地，切换节点可能丢失会话或未完成的交互。先明确会话是否共享、是否能恢复，及用户能否接受重新登录，再选择渐进迁移方案。

在支持这些选项的 HAProxy HTTP Cookie insert 模式中，可以考虑 maxidle 和 maxlife。下面的 30 分钟与 8 小时只是结构示例，不是推荐的固定时长：

cookie SERVER insert indirect nocache maxidle 30m maxlife 8h

maxidle 限制持久化 Cookie 被使用的空闲间隔；持续有请求的客户端可能不断更新相关时间。maxlife 限制它的总有效时长，适合需要为长时间活跃会话设置迁移边界的场景。二者不是应用会话过期时间，也不保证每到一个固定时刻就全量均分流量。

配置为这些机制保存时间信息后，后续请求才能按有效期判断。已经存在的旧格式 Cookie 需要按版本的处理规则和实际更新过程观察，不能把 reload 当作全部绑定立即清空。到期重新选择服务器后，新的请求分布仍会受活跃客户端、请求数量、连接和后端状态影响。

强制清空关联会影响正在使用的用户

改 Cookie 名称或移除持久化可以改变绑定行为，但会让现有客户端重新选择节点。它不能作为没有影响的扩容步骤。应用如果尚未支持跨节点会话，应先完成状态共享或恢复设计，再安排这种变更窗口。

修改前保存实际加载的配置与 Cookie 策略，按已安装版本校验配置，再通过服务既有方式 reload。不要为调整负载直接关闭旧节点，或者盲目清空全部应用会话。

验收要分别观察新客户端、已有客户端和到期后的客户端：新节点是否健康并接到新分配，已有会话是否仍正常，计划内迁移是否符合业务要求。回退可恢复旧配置，但已更新到浏览器的 Cookie 和已发生的节点迁移不会自动撤销，应继续检查用户状态与服务日志。