HAProxy backend 显示 down 但 curl 直连正常，大概率是健康检查配置与后端实际响应不匹配：默认 HEAD / 检查可能因不支持 HEAD、缺少 Host 头、状态码不符或重定向被拒；需确认 httpchk 方法/路径/Host/状态码预期，并调整 check port、inter、rise/fall 参数，同时排查 Spring Boot、Nginx、Cloudflare 等中间件拦截。
HAProxy backend 显示 down 但 curl 直连正常，先看健康检查配置是否匹配服务真实行为
这种情况大概率不是后端真挂了，而是 HAProxy 的健康检查（option httpchk 或 tcp-check）和后端实际响应不一致。HAProxy 默认用 HTTP HEAD / 发起检查，而你的服务可能只响应 GET、返回非 2xx 状态码、或要求特定 Host 头 —— 这些都会导致误判为 down。
常见表现：show stat 中 backend 状态为 DOWN，但手动 curl -v http://backend-ip:port/ 能拿到 200；日志里反复出现 Health check for server xxx failed。
- 确认检查方式：
option httpchk默认发HEAD /，若后端不支持 HEAD，必须显式改成GET /health或其他路径 - 检查 Host 头：很多服务（如 Nginx、Spring Boot Actuator）依赖
Host头路由或鉴权，需加http-check send hdr Host myapp.local - 忽略状态码：如果后端健康接口返回 401 或 503 但逻辑上仍“可用”，用
http-check expect status 200 401显式允许 - 避免检查路径被重定向：某些 / 会 301 到 /login，HAProxy 不跟随跳转，直接判失败 —— 改用明确的、无重定向的路径（如
/healthz）
check port 和 check inter 配置不当会放大误判
check port 指定健康检查连接的目标端口，和后端 server 行的端口可以不同；check inter 控制检查频率。设得太激进（比如 inter 100ms）+ 后端稍有延迟，就容易抖动 down；设得太宽松（inter 30s），又无法及时发现故障。
- 如果后端监听在 8080，但健康检查接口单独暴露在 8081（如 Prometheus metrics 端点），必须写
check port 8081，否则 HAProxy 仍连 8080 做检查 -
inter建议从 2s–5s 起步，配合rise 3（连续 3 次成功才 up）和fall 3（连续 3 次失败才 down），避免单次网络抖动触发切换 - 不要在同一个
server行混用check和check port却漏掉inter：HAProxy 会回退到默认 5s，但你可能误以为是 1s - 注意
fastinter/downinter：仅用于状态变化初期加速探测，日常配置通常不需要，反而增加日志噪音
验证健康检查是否真能模拟 HAProxy 行为
别信 curl 直连结果，要模拟 HAProxy 实际发的请求。最准的方式是用 openssl s_client（HTTPS）或 nc（TCP）手动生成原始请求，尤其关注换行、空行、大小写。
- HTTP 检查示例（假设
option httpchk GET /health）：printf "GET /health HTTP/1.0\r\nHost: example.com\r\n\r\n" | nc backend-ip 8080
—— 注意\r\n\r\n结尾，且必须是HTTP/1.0（HAProxy 默认不用 keep-alive） - 抓包确认：在 backend 机器上
tcpdump -i any port 8080 -A，然后看 HAProxy 连上来时发的是什么 —— 经常发现它没带 Host、或用了 HEAD - 临时关闭检查：
no check后观察 backend 是否变 up，能快速定位是否检查逻辑本身有问题 - 开启详细日志：
option httpchk配合log global和option http-log，在 syslog 里搜check关键字，能看到每次检查的响应状态码
后端应用层干扰：Spring Boot、Nginx、Cloudflare 等常见陷阱
很多 down 不是因为网络不通，而是中间件或框架主动拒绝了 HAProxy 的检查请求。
- Spring Boot Actuator：默认
/actuator/health在未认证时返回 401，需配置management.endpoints.web.exposure.include=health并设management.endpoint.health.show-details=never避免权限拦截 - Nginx：如果配置了
if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; }，会直接拒掉 HAProxy 的 HEAD 请求 —— 改成允许 HEAD，或切回 GET 检查 - Cloudflare / WAF：可能把高频、无 Cookie、无 User-Agent 的检查请求当成爬虫拦截，响应 403 或超时 —— 在 WAF 规则里放行 HAProxy 源 IP 段，或加
http-check send hdr User-Agent "HAProxy Health Check" - Gunicorn / uWSGI：启动慢、预热不足时，前几次检查可能超时（即使
timeout check设了 5s），建议加大timeout check到 10s，并配inter 5s rise 5防止启动期被踢出
真正难调的往往不是参数值，而是 HAProxy 的检查请求细节和后端期望之间的微小错位 —— 一个缺失的 Host 头、一行多余的空行、一次没被允许的 401，都足够让 backend 反复 down/up。
