HAProxy既能在TCP层转发数据库、TLS或其他连接，也能在HTTP层按Host、Path、Header路由。排查前必须确认Frontend、Backend运行在什么模式。TCP模式没有HTTP状态语义；HTTP模式才能检查响应头、状态和应用路径。
TCP与HTTP模式差异
| 项目 | TCP模式 | HTTP模式 |
|---|---|---|
| 观察层级 | 连接与字节流 | HTTP方法、头、路径和状态 |
| 路由能力 | 地址、端口及有限内容检查 | Host、Path、Header等 |
| 健康检查 | TCP连通或协议检查 | HTTP请求与预期响应 |
| 日志 | 连接时长和字节 | HTTP状态、队列与时间字段 |
健康检查通过为何业务仍失败
健康检查可能只验证端口或简单路径，真实请求却需要数据库、外部API和用户身份。应让检查足够代表服务可用，又不能执行昂贵业务或产生副作用。Readiness与深度业务监控可以分层，避免一个下游波动让所有节点同时被摘除。
检查间隔和阈值怎么设置
过于敏感会因一次抖动频繁上下线，过于宽松则继续向故障节点发送流量。应结合正常延迟、部署启动时间、故障检测目标和后端数量配置rise/fall等阈值，并在灰度环境模拟。
超时必须按阶段理解
客户端、连接、服务端、HTTP请求和隧道等超时含义不同。缺失关键超时可能让连接长期占用资源，设置过短则造成误杀。应从HAProxy日志中的队列、连接、首字节和总会话时间判断瓶颈。
为什么出现排队
Backend或Server最大连接数达到上限时，新请求可能在队列等待。排队不一定意味着CPU满，也可能是数据库连接池、长连接、慢请求或限制值太低。盲目提高maxconn会把压力转移到后端。
会话保持有哪些代价
Cookie、源地址或一致性策略可提高会话稳定性，也会造成负载倾斜。移动网络和共享NAT使源IP保持不够精确；节点故障时会话仍需转移。关键状态应放在共享存储或可恢复Token中。
TLS在哪里终止
HAProxy终止TLS时负责证书、协议和客户端安全，再以HTTP或重新加密连接后端；TLS透传时无法直接读取HTTP内容。两种架构在SNI路由、真实IP、后端证书和日志能力上不同，应明确选择。
真实客户端IP如何传递
HTTP模式可通过受控X-Forwarded-For传递；TCP模式可使用PROXY Protocol，但后端必须支持并只信任HAProxy来源。多层代理解析原则可参考Forwarded、XFF与可信代理链。
重试会不会重复写操作
HAProxy可在特定条件下重试或切换后端，但请求是否安全重放取决于方法和业务。POST已发送部分或上游已处理时，重试可能产生重复。应用必须提供幂等机制，代理策略应谨慎限制。
日志与Stats看什么
- Frontend与Backend会话数；
- 队列长度和等待时间；
- 连接、响应和总时长；
- 终止状态与重试次数；
- 每个Server健康状态和权重；
- TLS握手、协议和证书到期。
变更验证顺序
- 确认TCP或HTTP模式；
- 校验配置语法并保留回滚；
- 测试健康、慢响应和故障响应；
- 观察队列、连接和高分位延迟；
- 模拟单节点下线与重新加入；
- 验证会话、真实IP和TLS；
- 检查写请求不会被不安全重试。
结论
HAProxy排查的核心是模式与阶段。健康检查、连接队列、会话保持和TLS终止互相影响；用日志时间字段和故障演练验证，远比只看端口是否开放更可靠。
