HAproxy健康检查需合理设置check inter、rise/fall及timeout check：check inter建议3000ms起步，不得小于后端处理时间+RTT；rise/fall推荐3/3，慢服务可调大；必须显式配置timeout check（如5s），且小于check inter；http检查需明确expect状态码并处理认证。
check inter 设置太小导致健康检查频繁超时
HAProxy 的 check inter 控制两次主动健康检查之间的间隔（毫秒），设得太小会让后端服务来不及响应，尤其在高延迟或资源紧张时直接触发 fall 计数。默认值是 2000ms，但有人为“快速发现故障”改成 100ms，结果日志里全是 Server xxx is DOWN，其实服务完全正常。
- 建议起步值设为
check inter 3000（3 秒），再根据实际 RTT 和服务响应稳定性微调 - 如果后端是慢速 API 或数据库代理，应拉长到
5000甚至10000 - 注意：该值不能小于后端服务的典型处理时间 + 网络往返时间，否则等同于“主动制造失败”
rise 和 fall 值不匹配真实故障恢复节奏
rise 是连续成功次数才标记为 UP，fall 是连续失败次数才标记为 DOWN。设成 rise 2 fall 2 看似对称，但容易抖动 —— 一次网络丢包就 DOWN，一次偶然快响应又 UP，后端在 UP/DOWN 间反复横跳。
- 生产环境推荐
rise 3 fall 3起步；若后端恢复较慢（如 Java 应用冷启动需 10 秒），可加大rise到 5，避免过早转发流量 - 若后端故障后需人工干预（如 DB 主从切换），可设
fall 5防止误判 - 切忌把
rise设成 1：只要一次检查成功就 UP，可能把半死不活的服务当健康节点用
没配 timeout check 导致健康检查被阻塞
HAProxy 默认没有为健康检查单独设超时，它会复用 timeout connect 或更底层的系统限制。一旦后端响应慢（比如卡在 DNS 解析、ssl 握手或应用锁表），检查线程卡住，check inter 计时器也不走，后续检查全部堆积，最终批量标记为 DOWN。
- 必须显式配置
timeout check 5s（建议比check inter小至少 1 秒） - 该值应略大于后端健康接口的 P95 响应时间，但不超过
check inter的 80% - 常见错误：只写了
timeout connect 5s，但没写timeout check，此时健康检查仍可能无限等待
HTTP 健康检查返回码没覆盖重定向或认证场景
用 option httpchk GET /health 时，如果后端返回 302（跳转到登录页）或 401（需要 Basic Auth），HAProxy 默认只认 2xx 和 3xx 为成功 —— 实际上 302 会被当作失败，除非你明确允许。
- 加
http-check expect status 200可锁定只认 200，避免误判 - 若后端健康接口确实返回 302，得配
http-check expect status 302，或者用http-check expect ! status 5xx排除错误码 - 带认证的健康接口要补
http-check send hdr Authorization "Basic xxx"，否则永远 401
健康检查不是越激进越好，关键在匹配后端的真实行为节奏。很多问题不是配置写错了，而是把“理论最短检测时间”当成了“合理检测窗口”。