Linux HAProxy 高可用部署技巧

haproxy启动失败因端口权限或冲突，应授cap_net_bind_service能力而非sudo；keepalived主备失效需校准priority、vrrp_script及时间同步；http健康检查优选http-check；ssl卸载后需配置forwardfor与后端可信代理。

HAProxy 进程启动失败：bind 权限被拒或端口冲突

linux 上非 root 用户无法绑定 1024 以下端口，而 haproxy 默认监听 80 或 443，直接启动会报 Permission denied 或 Address already in use。别急着加 sudo 启动服务——这会埋下权限和安全风险。

• 用 setcap 'cap_net_bind_service=+ep' /usr/sbin/haproxy 授予能力，比全权 root 更细粒度；验证：运行 getcap /usr/sbin/haproxy 应返回该行
• 检查端口占用：ss -tlnp | grep ':80'，确认没被 nginx、apache 或残留进程占着
• 若测试环境想绕开权限问题，临时改配置里 bind 行为：bind *:8080，但上线前必须切回标准端口并配好能力

Keepalived + HAProxy 主备切换不生效

常见现象是 VIP（如 192.168.1.100）始终只在一台机器上响应，另一台 keepalived 日志里反复出现 Master received advert from XXX with higher priority，本质是状态同步逻辑没对齐。

• vrrp_script 必须检测 haproxy 进程真实存活：killall -0 haproxy 比 ps aux | grep haproxy 可靠，后者可能匹配到 grep 自身
• 主备的 priority 值不能只差 1——网络抖动可能触发误判，建议至少差 50；同时设 advert_int 1（秒级探测），别用默认 2 秒
• 确保两节点时间同步：chronyd 或 systemd-timesyncd 必须启用，否则 VRRP 报文时间戳校验失败，keepalived 会静默丢包

HAProxy 配置里 http-check 和 option httpchk 选哪个

两者都能做 HTTP 健康检查，但底层行为差异大，混用容易导致后端节点被误踢。

• option httpchk 是传统模式，仅发 HEAD 请求，不带 Host 头，适合简单静态服务；若后端依赖 Host 头路由（比如多租户 API 网关），它大概率失败
• http-check send hdr Host example.com + http-check expect status 200 是现代写法，可构造完整请求，支持自定义 header、method、path，且能解析响应体内容（如 http-check expect String "OK"）
• 注意：启用了 http-check 就别再写 option httpchk，HAProxy 会忽略后者；检查是否生效：看 stats 页面里 backend 的 check 列是否显示 “HTTP” 而非 “L4TCP”

SSL 卸载后客户端真实 IP 丢失

HAProxy 默认把源 IP 替换为自身地址传给后端，X-Forwarded-For 头虽存在，但 Nginx/Apache 不默认信任它，日志和限流仍显示 HAProxy 的内网 IP。

• HAProxy 配置中必须加 option forwardfor except 127.0.0.1（或你内网段），否则本地健康检查也会塞入伪造头
• 后端 Web 服务器要显式配置可信代理段：Nginx 用 set_real_ip_from 10.0.0.0/8; + real_ip_header X-Forwarded-For;；Apache 用 RemoteIPTrustedProxy
• 别漏掉 option http-server-close——它让 HAProxy 保持与客户端的连接，同时释放与后端的连接，避免长连接场景下 X-Forwarded-For 被覆盖

真正麻烦的从来不是单点配置，而是当 Keepalived 抢 VIP、HAProxy 重载配置、后端滚动发布三件事撞在一起时，那个 200ms 的窗口期——它不会报错，但会悄悄丢请求。盯住 show stat 输出里的 qcur（当前排队请求数）和 bin/bout（字节收发量）突变，比看日志更早发现问题。