HAProxy的TCP代理运行于OSI第四层,仅转发连接并健康检查,适用于数据库、消息中间件等需协议透明的场景;配置需设mode tcp,禁用HTTP相关指令,结合tcp-check与leastconn提升可靠性。

HAProxy 的 TCP 代理能力是构建多级高可用架构的关键基础,尤其适合需要穿透四层、不解析应用层内容的场景,比如数据库集群、消息中间件、SSH 跳板、TLS 直通(如 HTTPS 或 MySQL over TLS)等。它不干预协议载荷,只做连接转发与健康检查,因此延迟低、兼容性强、稳定性高。
明确 TCP 模式适用的层级定位
TCP 代理运行在 OSI 第四层,不解析 HTTP 头、URL、Cookie 等七层信息,也不做重写或压缩。这意味着:
- 它天然适合作为“第一级入口网关”或“中间级透传网关”,承接来自公网或内网的原始 TCP 流量;
- 可与七层 HAProxy 实例级联:外层用 TCP 模式做 TLS 终止前的负载(如分发到多个 nginx 或 haproxy-https 实例),内层再用 HTTP 模式做 URI 路由、动静分离;
- 避免在关键链路中引入七层解析开销,提升吞吐和可靠性,特别适合 MySQL 主从、Redis 集群、Kafka Broker 等对协议透明性要求高的服务。
配置 TCP 代理的核心要点
启用 TCP 模式需在 frontend 和 backend 中显式指定 mode tcp,并禁用所有依赖 HTTP 解析的指令(如 http-request、acl hdr())。典型配置示例如下:
frontend mysql_in
bind *:3306
mode tcp
default_backend mysql_cluster
backend mysql_cluster
mode tcp
balance leastconn
option tcp-check
tcp-check connect
tcp-check send \x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00
tcp-check expect string \x00
server db1 192.168.5.10:3306 check inter 3000 rise 2 fall 3
server db2 192.168.5.11:3306 check inter 3000 rise 2 fall 3
说明:
安装并运行 Aperture(Lightning Labs 的 L402 闪电反向代理),用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
option tcp-check+tcp-check connect表示仅建立 TCP 连接即判定存活; - 若需更精准检测(如 MySQL 协议握手响应),可配合
tcp-check send和tcp-check expect发送/匹配二进制字节流; -
balance leastconn比轮询更适合数据库类长连接场景,防止某节点堆积过多连接。
多级架构中的典型组合方式
常见可靠拓扑包含三层或更多角色,HAProxy TCP 实例可灵活嵌入任一环节:
- 外层 TCP 入口 + 内层 HTTP 路由:公网流量先经 TCP 模式 HAProxy 分发至多个 HTTPS 终止节点(如 nginx 或 HAProxy-HTTPS),再由后者完成 SSL 卸载和七层分发;
-
双 HAProxy TCP 层级串联:第一层按地域或租户做 IP 哈希分发(
balance source),第二层在单个租户内按最小连接分发到底层 DB 实例; - TCP 代理 + Keepalived VIP 高可用:两个 HAProxy TCP 节点部署 Keepalived,共享一个虚拟 IP(VIP),主节点故障时 VIP 秒级漂移,后端服务无感知;
- TCP 代理作为中间网关隔离网络域:例如在 DMZ 区部署 HAProxy TCP 实例,仅开放特定端口(如 3306、6379)代理至内网数据库区,实现安全边界收敛。
健康检查与故障隔离必须到位
TCP 模式下健康检查不能依赖 HTTP 状态码,需根据目标服务协议特征定制:
- 对 MySQL:用
tcp-check发送简单握手包并校验响应首字节是否为\x00; - 对 Redis:发送
PING\r\n并期待+PONG\r\n; - 对自定义 TCP 服务:可编写外部脚本(
option external-check)调用nc或专用探针; - 务必设置合理的
inter(检查间隔)、rise(升序次数)、fall(降序次数),避免震荡或响应迟钝。
不复杂但容易忽略

















