haproxy 单靠配置无法实现高可用，必须结合 keepalived 抢 vip；健康检查仅针对后端服务，不保障 haproxy 自身或宿主机可用；vip 才是客户端访问目标，需确保 vrrp 通信、服务启动顺序及兼容性配置正确。

HAProxy 本身不提供高可用，单靠 haproxy.cfg 配再全的健康检查也防不住它自己挂掉；真要高可用，必须配 Keepalived 抢 VIP，两台机器共享一个虚拟 IP，主挂了备秒接流量。

为什么只改 haproxy.cfg 永远不是高可用

很多人在 backend 里加 check inter 2000 fall 3 就以为“能自动切换”了——这只是检查后端服务是否活着，不是检查 HAProxy 进程或宿主机是否正常。一旦服务器内核 panic、磁盘满、systemd 崩溃、甚至网卡失联，整个入口就断了，且毫无恢复能力。

• haproxy -c -f /etc/haproxy/haproxy.cfg 通过 ≠ HAProxy 能持续运行
• 后端健康检查 DOWN ≠ 入口可用；入口不可用时，所有检查都失去意义
• VIP（虚拟 IP）才是客户端真正访问的目标，不是某台物理机的 IP

Keepalived + HAProxy 最小可行配置要点

以两节点主备为例（主：172.24.8.10，备：172.24.8.11，VIP：172.24.8.100），关键不是写多复杂，而是几处不能错：

FastAPI Flask Proxy

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

下载

• interface 必须真实存在（用 ip link 确认，别硬写 ens33 或 eth0）
• virtual_router_id 主备必须一致，且同一二层网络中不能与其他 Keepalived 实例冲突
• state MASTER 和 state BACKUP 必须明确区分，priority 主建议 100、备建议 90（差值 ≥ 10 更稳妥）
• HAProxy 必须监听 0.0.0.0:80 或 *:80，不能绑定具体物理 IP，否则 VIP 切换后无法响应
• 两台机器的 /etc/haproxy/haproxy.cfg 内容需完全一致（日志路径等本地路径除外）

启动前必须验证的三件事

跳过这三步，90% 的 VIP 切换失败都源于此：

• 防火墙必须放行 VRRP 组播：224.0.0.18，协议号 112（firewall-cmd --add-protocol=vrrp --permanent 或 iptables -I INPUT -p 112 -j ACCEPT）
• 确认 keepalived 和 haproxy 都已启用并设为开机自启：systemctl enable keepalived haproxy
• 先启 keepalived，再启 haproxy；切勿反序，否则 VIP 可能无法绑定或立即被抢占

容易被忽略的兼容性细节

CentOS Linux 7.9.2009 这类老系统仍广泛存在，但它的 systemd 版本较旧，对 AmbientCapabilities 支持不完整——这意味着即使给 /usr/sbin/haproxy 加了 cap_net_bind_service，绑定 :80 仍可能失败。此时更可靠的做法是：

• 在 frontend 中改用非特权端口（如 bind *:8080），前端再套一层 Nginx 或云 LB 做端口映射
• 或确保 user 和 group 在 global 段设为 root（仅限内网可信环境，不推荐生产）
• haproxy -v 输出版本低于 1.8 时，stats 不支持直接放在 frontend 下，得用 listen stats 单独块

高可用真正的难点不在配置语法，而在于主备之间的心跳是否真实可达、VIP 是否真的被路由识别、以及故障发生时整个链路（从客户端 DNS 解析到后端服务响应）有没有单点静默失效。这些没法靠 reload 一次配置就验证，必须模拟 kill -9 haproxy、拔网线、关电源来实测切换时间与连接连续性。