HAProxy健康检查必须配置在backend而非frontend，因仅server行支持check机制；应使用http-check指令替代已弃用的option httpchk，并合理设置inter/fall/rise/timeout check参数。
haproxy 健康检查必须配在 backend，不是 frontend
很多人一上来就在 frontend 段加 healthcheck，结果 reload 时报错或完全不生效——因为 HAProxy 的健康检查机制只作用于 server 行，而 server 只能出现在 backend 中。
正确做法是：在 backend 块内启用 HTTP 检查，并为每个 server 显式加上 check 标志。例如：
backend web_servers
option httpchk GET /health
http-check expect status 200
server web1 192.168.1.10:80 check inter 5000 fall 3 rise 2
server web2 192.168.1.11:80 check inter 5000 fall 3 rise 2
inter 5000 表示每 5 秒发一次请求；fall 3 表示连续 3 次失败才标记为 DOWN；rise 2 表示连续 2 次成功才恢复为 UP。这些值不能拍脑袋定，得结合后端接口响应时间来调。
HAProxy 2.0+ 必须用 http-check，option httpchk 已弃用
如果你用的是 HAProxy 2.0 或更新版本（2026 年主流发行版默认已是 2.2+），option httpchk 语法虽然还能解析，但会被警告，且某些高级行为（比如自定义响应体匹配）不生效。
应改用 http-check 系列指令：
-
http-check send meth GET uri /health替代option httpchk GET /health -
http-check expect status 200或http-check expect string OK替代旧版的http-check expect模糊写法 - 所有检查逻辑必须写在
backend块开头，且顺序敏感：先send，再expect
错误示例：http-check expect string OK 写在 http-check send 前面 → 配置校验失败，haproxy -c -f /etc/haproxy/haproxy.cfg 直接报错。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
自动切换故障节点的关键参数：fall/rise/inter 组合要合理
自动切换不是“一断就切”，而是靠 fall 和 rise 控制状态跃迁节奏。设得太激进（如 fall 1）会导致网络抖动时频繁踢出节点；设得太保守（如 fall 10）又会让故障服务持续收流量。
生产环境推荐组合：
-
inter 3000：3 秒间隔，兼顾及时性与后端压力 -
fall 3：3 次失败才 DOWN，容忍单次超时或丢包 -
rise 2：2 次成功即 UP，避免恢复延迟过长 -
timeout check 4000：检查超时设为略大于inter，防止误判（例如后端平均响应 3.2s，超时设 4s）
注意：timeout check 必须写在 defaults 或 backend 块里，不能挂在 server 行后面。
验证健康检查是否真正在工作
光 reload 成功不代表健康检查跑起来了。必须确认三点：
- 后端服务的
/health接口返回 200 且响应体符合http-check expect规则（比如你写了string OK，但实际返回{"status":"ok"}→ 不匹配，永远 DOWN） - HAProxy 统计页面（需开启
stats）中对应server状态栏显示UP，不是DOWN或no check - 手动停掉一个后端服务，观察统计页是否在
fall × inter时间内（如 3×3s=9s）变为DOWN，且流量不再打过去
常见盲点：http-check send 默认走 HTTP/1.0，不带 Host 头，某些后端（如 Nginx 虚拟主机）会直接 400；此时得加 hdr Host example.com 显式指定。
