HAProxy后端异常curl正常排查指南

HAProxy后端显示“DOWN”而curl直连却正常，往往并非服务真实故障，而是健康检查配置与后端实际响应行为存在细微错位——如默认HEAD请求被拒绝、缺失Host头、状态码不匹配、重定向未跟随，或受Spring Boot鉴权、Nginx方法限制、Cloudflare拦截等中间件干扰；只需精准复现HAProxy检查请求（用nc/openssl模拟）、校准httpchk方法/路径/Host/状态码预期、合理设置check port、inter/rise/fall参数，并排查应用层拦截逻辑，即可快速定位并根治这一高频“假下线”问题。

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。

到这里，我们也就讲完了《HAProxy后端异常curl正常排查指南》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！