HAProxy 健康检查返回 400：HTTP/1.1 请求需要正确的 Host

浏览器或 curl 能访问后端，HAProxy 健康检查却显示 Layer7 wrong status, code: 400。如果检查使用 HTTP/1.1，应核对它是否发送正确的 Host，以及方法、路径、端口是否和成功请求一致。

400 表示后端拒绝了这条 HTTP 请求，不足以证明应用整体不可用。本文配置示例按 HAProxy 3.2 的 http-check send 语法编写；较旧版本的检查指令不同，应先确认版本，不能照搬成一条跨版本配置。

比较的是两条具体请求

先查看 HAProxy 的实际检查端口和后端访问日志。业务流量可能去一个端口，健康检查通过 check port 去另一个端口；成功访问业务端口，不能证明另一个检查端口也能提供同样路径。

再比较以下信息：请求方法、URI、HTTP 版本、Host 和是否使用 TLS。curl 通常会根据请求 URL 自动带上 Host，因此它成功，并不代表 HAProxy 发出的检查请求也含相同头。

如果 HTTP/1.0 返回 426，而改为 HTTP/1.1 后返回 400，更需要检查协议要求和请求头。HTTP/1.1 要有 Host，HAProxy 的检查请求不会自动替你添加它。带了 Host 却选错虚拟主机，也可能获得 404、重定向或其他站点的状态。

明确写出方法、路径、版本和 Host

下面是 backend 配置片段示例，实际部署仍需完整的 global、defaults、frontend 及超时配置：

backend app
    mode http
    option httpchk
    http-check send meth GET uri /healthz/ready ver HTTP/1.1 hdr Host app.example.com
    http-check expect status 200
    server node1 192.0.2.10:8080 check

IP、端口、Host 和健康路径均为示例，要使用应用认可的值。这里检查与业务连接同一个 HTTP 端口；若有专门的健康端口，应另行明确 check port 并确认那个入口提供该接口。Host 不需要照抄为任意的 www，它要能选中预期服务。

option httpchk 启用 HTTP 检查，http-check send 定义发送的请求，http-check expect status 200 规定成功条件。若仍使用带参数的 option httpchk，方法、URI 和版本也必须按语法位置写全；不能省略方法后指望后两个字段自动成为 URI 和版本。

如果服务要求 TLS，除了 HTTP 头，还需要核对检查连接的 TLS、SNI 和信任配置。Host 是 HTTP 层字段，不会自动代替 TLS 的服务器名称；不应关闭证书验证来消除另一类错误。

让健康状态反映真实可用性

不要把 400 加入允许状态，也不要直接去掉检查，让后端重新进入流量池。修正请求后仍返回 400，应继续查后端日志与接口要求；返回登录重定向或默认站点的 200，也不表示目标应用已经就绪。

修改前保存 HAProxy 配置和原检查参数，评估改变检查会使哪些节点加入或退出服务，校验后按正常流程加载。回退应恢复原配置与检查策略，而不是强制标记所有节点健康。

验收时确认后端日志收到预期的检查请求，状态符合约定，并在 rise、fall 等阈值允许的时间内发生正确的健康状态变化。还要检查一次真实业务访问；专门的健康接口通过只能证明它所检查的条件，不能自动证明所有业务操作可用。