HAProxy 业务连接可用，TLS 检查仍报 Layer6：check-sni 要单独配置

HTTPS 客户端能连接后端，HAProxy 的检查却显示 Layer6 invalid response、SSL handshake failure 或连接被重置。若后端要求 SNI，先检查独立健康检查有没有发送这个名称。业务连接已有正确的 SNI，不代表 HAProxy 自己发起的检查也有。

这条路径适用于 HAProxy 对要求 SNI 的后端执行 TLS 检查，尤其是 TCP 透传业务流量的配置。HAProxy 1.8.13 已支持 check-sni；下面按当前 3.2 文档说明参数。Layer6 错误也可能来自证书链、协议或客户端证书要求，不能只凭错误名称认定根因。

业务握手和检查握手由谁发起

TCP 透传时，业务 TLS 握手来自客户端，HAProxy 转发相应字节，客户端可以自行携带 SNI。健康检查是 HAProxy 定时建立的新连接，没有这次用户请求，也不能直接借用该请求的名称。

server 的 sni 参数用于 HAProxy 发起的代理 TLS 连接，check-sni 用于健康检查，两者用途不同。即使业务连接设置了 sni str(app.example.com)，仍要核对检查端的名称；动态表达式 ssl_fc_sni 也不能代替独立检查的静态名称。

先确认实际检查地址、端口和协议。若检查使用另一个端口，客户端访问业务端口成功不能证明检查端口正确。还应查看后端在对应时刻的 TLS 日志，区分拒绝未带 SNI、返回错误站点证书和其他握手错误。

用真正的 TLS 检查替换旧 ssl-hello-chk

旧配置可能同时存在 option ssl-hello-chk 和 check-ssl。前者模拟旧的 SSLv3 ClientHello，不适合代替现代 TLS 握手与验证；清除它时也要检查 defaults 等继承位置。不能一边加入新检查，一边留下旧的检查方式。

下面是 TCP 透传后端的配置片段示例，仍需配合已有的 frontend、defaults 和超时设置：

backend app_passthrough
    mode tcp
    server node1 192.0.2.10:443 check check-ssl check-sni app.example.com verify required verifyhost app.example.com ca-file /etc/haproxy/backend-ca.pem

192.0.2.10、域名和 CA 文件都是占位值。check-ssl 为检查连接启用 TLS，check-sni 指定后端认可的名称；verify required 保留证书验证，CA 文件应来自确认可信的信任配置，并在 HAProxy 实际运行环境中存在且可读。verifyhost 还明确静态的证书校验名称，不能把任意的后端组名当成证书名称。

这个示例没有 ssl，业务流量保持 TCP 透传，只由检查主动建立 TLS。若 HAProxy 已终止前端 TLS，再向后端建立新的 TLS 连接，业务连接应另行按原架构配置 ssl 和 sni，不能直接用本片段替换整条 server 配置。也不要在已有 TLS 字节透传连接上随意加 ssl，造成多包一层 TLS。

如果使用显式的 tcp-check connect 或 http-check connect 检查序列，应核对该序列实际使用的连接参数，不要只修改一条未被实际检查采用的 server 设置。

TLS 检查通过，还要验证需要的服务层

修正后仍失败，依据新错误检查 CA 链、有效期、证书名称、协议协商和双向 TLS 要求。不要把 verify none 当作 SNI 修复，也不要关闭后端所有站点的 SNI 要求来迁就错误的检查。

若 TLS 已通过但 HTTP 检查仍返回 400 或 404，应继续核对检查请求的方法、路径与 Host。Host 在 TLS 握手之后发送，不能补救握手阶段缺少 SNI；相反，仅完成 TLS 握手也不能证明应用的就绪接口正常。

修改前保存原配置与继承片段，评估检查变化会让哪些节点重新加入流量池。对目标实例校验配置成功后，按现有服务管理方式加载，观察错误日志与后端检查状态。只确认配置能解析不足以证明握手成功。

验收应包括预期的 TLS 检查通过、证书验证没有新增错误、节点在既有 rise/fall 阈值下正确变更状态，以及真实业务请求仍正常。如果出现误判健康或业务回归，恢复保存的配置，校验并重新加载，再检查同一后端。不要靠禁用健康检查或强制节点 UP 来代替恢复。