HAProxy怎么配置基于Cookie的会话保持黏性连接-LINUX-PHP中文网

haproxy的cookie黏性配置必须置于backend段且仅在mode http下生效；mode tcp会静默忽略，需配合cookie serverid insert nocache indirect及各server的对应cookie值才能实现稳定会话保持。

haproxy怎么配置基于cookie的会话保持黏性连接

cookie 配置必须放在 backend 段，且只在 mode http 下生效 —— 四层 mode tcp 直接忽略该指令，不会报错但也不起作用。

必须用 mode http，否则 cookie 黏性完全无效

frontend 或 defaults 中写 cookie 指令会被静默忽略（HAProxy 不校验语法位置，只在 backend 解析）
如果后端是 HTTPS 服务但 HAProxy 终止 SSL，则仍属七层，可用 cookie；若仅做 TCP 透传（如 TLS passthrough），则必须切回 mode tcp，此时无法用 cookie，得换 stick-table 或源 IP 哈希
RHEL9.3 默认启用 http-request set-var 等高级策略，但不影响基础 cookie 指令，只要没禁用 option http-server-close 类参数即可

cookie 指令的三个核心组件不能漏

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

backend 行必须带 cookie <name> insert nocache indirect</name>：其中 <name></name> 是客户端看到的 Cookie 键名（如 SERVERID），insert 表示首次响应时注入，nocache 防 CDN/代理缓存错误路由，indirect 避免重复下发已存在的 Cookie
每个 server 行必须带 cookie <value></value>：这个 <value></value> 是后端节点唯一标识（如 web1），和上面 <name></name> 无关，但必须一一对应

示例配置片段：

backend webapp
  mode http
  balance roundrobin
  cookie SERVERID insert nocache indirect
  server web1 192.168.10.11:8080 cookie web1 check
  server web2 192.168.10.12:8080 cookie web2 check

常见失效场景和验证方法

curl 测试时没带 -b 和 -c，看不到 Cookie 轮转：用 curl -v -c /tmp/cookie.txt @#@#@#@#@#@#@#@#@#@0 发第一次请求，再用 curl -b /tmp/cookie.txt @#@#@#@#@#@#@#@#@#@0 发第二次，观察后端日志或响应头中 X-Forwarded-For 是否固定
后端应用自己也设了同名 Cookie（如 PHPSESSID），覆盖了 HAProxy 的 SERVERID：检查响应头里是否出现两个 Set-Cookie，优先级以 HAProxy 插入的为准，但浏览器可能按顺序取第一个
option forwardfor 没开，后端拿不到真实 IP，误判为新会话：虽不影响 cookie 路由，但日志排查时容易混淆，建议始终开启
redispatch 未启用，后端宕机后旧 Cookie 请求持续 503：加一行 option redispatch 在 backend 里，让 HAProxy 在节点失败时主动重选（注意这会破坏“绝对黏性”，但提升可用性）

真正容易被忽略的是 nocache 和 indirect 的协同效果

单独用 nocache 只防中间缓存污染，但若用户刷新页面或重发请求，HAProxy 仍可能重写 Cookie；加上 indirect 才确保“已有 Cookie 就不碰”，这才是生产环境稳定的组合
RHEL9.3 的 SELinux 默认策略对 /var/lib/haproxy 有严格控制，如果启用了 stick-table 日志或持久化，cookie 本身虽不依赖磁盘，但健康检查日志路径若配错，会导致 check 失败进而误判节点下线 —— 这会让黏性看起来“突然断掉”