HAProxy会话保持核心是确保同一客户端请求始终路由至同一后端服务器,避免状态丢失;需按协议与场景选型:Cookie方式(仅mode http)精准但依赖客户端支持,源IP哈希通用但受NAT影响,stick-table灵活可控且支持多维度匹配与超时管理。

HAProxy 配置会话保持,核心是让同一客户端的请求持续落到同一台后端服务器上,避免因状态(如登录态、购物车)丢失导致业务异常。实际配置需根据协议类型、业务场景和可靠性要求选择合适方式,不是所有情况都适合用 Cookie。
Cookie 方式(HTTP 服务首选)
适用于 Web 类应用,尤其是依赖 Session 的 PHP、Java 等后端。它比 IP 哈希更精准,不受 NAT 或移动网络 IP 变更影响。
- 必须启用 mode http,TCP 四层模式不支持
- 在 backend 段添加:cookie SERVERID insert indirect nocache
- 每个 server 行需指定唯一标识:server web1 192.168.0.10:80 cookie s1 check
- indirect 避免重复写 Cookie;nocache 防止 CDN 缓存导致粘性失效
- 客户端首次访问时,HAProxy 自动注入
Set-Cookie: SERVERID=s1;后续请求带该 Cookie 即固定路由
源 IP 哈希(TCP/HTTP 通用,简单但有局限)
适合无法控制客户端 Cookie 的场景,比如部分 API 调用或老旧系统,但要注意局域网共享出口 IP 会导致多个用户被分到同一节点。
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 配置简单:balance source,无需改 mode,TCP 和 HTTP 都可用
- 哈希结果受客户端真实 IP 影响,若前端有代理(如 Nginx),需确保 option forwardfor 正确传递 X-Forwarded-For
- 不推荐用于移动端或动态 IP 场景,IP 变更即会话中断
stick-table 方式(灵活可控,适合复杂需求)
适合需要自定义匹配条件、超时控制或非 HTTP 协议(如数据库连接、自定义 TCP 服务)的场景。
- 定义会话表:stick-table type ip size 10m expire 30m
- 指定匹配字段:stick on src(按源 IP)、stick on req.cook(SERVERID)(按 Cookie 值)等
- 支持动态故障转移:后端宕机时,可结合 on-marked-down restart 或 on-marked-up recover 控制行为
- 可通过 socat 查看实时会话:
echo "show table mybackend" | socat stdio /var/run/haproxy.sock
配套要点不能漏
无论选哪种方式,以下配置常需同步调整:
- 健康检查要到位:用 option httpchk GET /health 替代默认 TCP 检查,避免端口通但服务僵死
- 故障转移要合理:加 option redispatch,允许在后端异常时重试其他节点(注意是否影响事务一致性)
- 日志与调试要跟上:开启 log-format 记录 Cookie 值或源 IP,方便排查粘性是否生效
-
重启前务必测试:修改配置后用
haproxy -c -f /etc/haproxy/haproxy.cfg校验语法

















