HAProxy用tcp-check发HTTP HEAD请求失败且日志仍报400求助

核心错误点 #

• 未在TCP检查中启用SSL握手：后端server配置了ssl，但tcp-check默认用明文连接，导致发送的HTTP请求被SSL服务端无法正确解析，直接触发错误。
• HTTP/1.1请求缺少Host头：HTTP/1.1规范强制要求携带Host字段，缺失会让应用返回400错误，这也是日志中400条目持续存在的根本原因。
• tcp-check expect正则格式错误：正则里多余的空格转义和注释写法不符合HAProxy语法，导致响应匹配失败。

修正后的配置 #

backend bk_my-service-9801
  mode tcp
  balance leastconn
  option tcp-check
  # 建立SSL加密连接，与后端server的ssl配置匹配
  tcp-check connect ssl ca-file cicada_CA_renew20220113.pem
  # 发送完整合规的HTTP HEAD请求
  tcp-check send HEAD\ /\ HTTP/1.1\r\n
  tcp-check send Host:\ myhost\r\n  # 替换为你的实际域名/主机名
  tcp-check send User-Agent:\ HAProxy\ tcpcheck\r\n
  tcp-check send \r\n
  # 匹配HTTP 2xx/3xx响应的严谨正则
  tcp-check expect rstring ^HTTP/1\..\ (2[0-9]{2}|3[0-9]{2})
  server kube_my-service-0 myhost:31801 check ca-file cicada_CA_renew20220113.pem ssl

关键说明 #

1. tcp-check connect ssl：必须添加该选项，确保健康检查的连接是SSL加密的，和后端server的ssl配置对齐，否则明文请求会被SSL服务端拒绝。
2. Host头补充：补上Host字段满足HTTP/1.1规范，彻底解决日志中的400错误条目。
3. 正则优化：^HTTP/1\..\ (2[0-9]{2}|3[0-9]{2}) 是更严谨的匹配逻辑，精准识别HTTP/1.0/1.1的2xx/3xx状态码，去掉了无效的转义和注释。
4. 指令顺序：option tcp-check后先配置tcp-check connect，再写发送和检查指令，顺序不能颠倒。

内容的提问来源于stack exchange，提问作者rmf