HAProxy 主机恢复后长连接仍在 backup：核对连接生命周期与回切条件

HAProxy 后面的首选服务器恢复健康，新连接可能已经选择它，原有 Redis、KeyDB 或其他 TCP 长连接却继续留在备用服务器。配置了 on-marked-up shutdown-backup-sessions 也没有回切时，先检查恢复的服务器是否仍带 backup 标记，以及当前观察的是旧连接还是新连接。

以下按 HAProxy 3.2 的服务器状态与配置规则说明。TCP 长连接已经连接到某个后端时，不能把它透明搬到另一台服务器；所谓回切通常是结束旧连接，让客户端重新建立连接。数据服务还必须满足自身的主从、写入和一致性要求。

健康恢复不等于旧连接换了后端

分别观察服务器健康状态、新连接的后端选择和原有连接所在服务器。首选服务器恢复后，后续选路与已建立连接是两件事。若测试一直复用同一个连接，即使选路已经符合配置，也可能只看到它仍在备用节点。

检查实际加载的 backend、各个 server 的 backup、权重和运行状态，再结合客户端连接池与 HAProxy 日志判断。配置文件出现了首选服务器，不代表运行中的实例已经加载了这份配置，也不代表它当前具有有效的非零权重。

全部标成 backup 时，恢复动作有前提限制

on-marked-up shutdown-backup-sessions 会在符合条件的服务器被标记恢复时，结束备用服务器上的流。关键条件是恢复的服务器不是 backup，并且没有被禁用、有效权重大于零。

因此，三台服务器都带 backup，即便第一台恢复，也不满足这个动作所要求的非备用身份。只把该参数加在所有备用服务器后面，不能实现任意层级的优先级回切。

若业务确实采用“一台正常活动服务器，其他作为备用”的模型，可以按这个模型核对 server 身份和恢复动作。改为正常服务器意味着它有资格承接正常流量，不能仅为了触发参数，就把数据库只读副本或尚未完成提升的节点改成活动节点。

allbackups 不负责结束旧会话

默认情况下，所有正常服务器不可用时，第一个可用的备用服务器承接备用流量。启用 option allbackups 后，会在可用备用服务器之间按所选算法及权重分配流量，不再保留同样的备用优先顺序。

这个选项改变备用服务器的选择方式，不会把已经建立的 TCP 会话搬走。如果目标是第一台优先、第二台次之、第三台最后，并且恢复时也逐级回切，就不能把 allbackups 当成实现这种策略的开关。

多层优先级还涉及谁有权提升节点、怎样确认节点已可安全服务，以及客户端何时重新连接。应让现有的服务高可用管理与代理配置配合，不能只靠备用标记推断数据库角色已经正确。

强制回切会中断业务

shutdown-backup-sessions 结束的是备用服务器上的流，客户端会经历断线。正在进行的事务或命令可能尚未完成，客户端也可能无法仅凭连接异常确定服务器是否已经执行操作。HAProxy 会为这种恢复触发的终止记录相应的 U 终止标记，但它不能替应用判断业务是否需要重试。

启用前确认客户端重连、超时和重试行为，评估正在执行的操作是否可以安全重试，并安排可接受的维护窗口。若业务能够接受旧连接自然结束，可以先让新连接使用恢复节点，再按客户端已有的连接生命周期逐步回收旧连接，避免一次中断全部会话。

对 Redis 或 KeyDB 等数据服务，单纯的存活检查也不能替代角色和业务可用性判断。节点能响应，并不自动证明它拥有正确数据、可写身份或已完成故障切换。应按现有系统的健康与角色规则核对，避免代理把写入送给不适合承接的节点。

分开验证选路与回切

保存原配置，在受控环境中验证：正常服务器可用时的新连接选择、正常服务器失效后的备用选择，以及恢复后的新旧连接行为。若启用了强制结束动作，确认实际触发条件和客户端恢复，并核对业务有没有失败、重复或状态不明的操作。

上线后恢复服务器状态、日志与客户端行为应互相一致。停止强制回切或恢复旧配置，可以改变后续连接策略，却不能复活已经被结束的 TCP 会话。出现业务异常时先暂停相关重试，根据操作记录核对结果，再按保存的配置和既有高可用流程恢复。