HAProxy 完全指南：从入门到实战

一、HAProxy 是什么？

HAProxy，全称 High Availability Proxy，是一款专业的、开源的、高性能的 TCP/HTTP 反向代理和负载均衡器。它诞生于 2000 年，经过二十多年的发展，已成为高可用性环境的事实标准。

核心定位：HAProxy 的专长就是负载均衡和代理。它不像 Nginx 那样能兼任 Web 服务器，而是专注于一件事：把流量高效、智能、稳定地分发给后端的多个服务器。

技术特点：

• 高性能：采用事件驱动架构，单进程多线程设计，能在普通硬件上轻松处理数万甚至数十万并发连接。
• 资源占用极低：专注于单一职责，对系统资源消耗很小。
• 极强的稳定性：被广泛应用于 PayPal、Stadia Maps 等对稳定性要求极高的生产环境。

二、HAProxy 怎么用？核心配置解析

HAProxy 的核心能力通过其配置文件（通常是 haproxy.cfg）来定义。配置文件结构清晰，主要分为几个逻辑部分。

1. 配置结构

global
    # 全局配置，如进程数、最大连接数、运行模式等
    maxconn 2000
    daemon

defaults
    # 默认配置，会被 frontend 和 backend 继承
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http-in
    # 前端：定义入口，即"在哪里接收流量"
    bind *:80
    # 根据规则匹配，决定将请求送往哪个后端
    default_backend servers_web

backend servers_web
    # 后端：定义出口，即"将流量转发给谁"
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

2. 关键配置项详解

• frontend：定义客户端连接的入口，包括监听的 IP 和端口，以及匹配规则（ACL）。所有流量首先进入这里。
• backend：定义真实的服务器池。在这里指定负载均衡算法、服务器列表及健康检查方式。
• listen：一个简化配置的写法，等同于将 frontend 和 backend 合并在一起，适用于简单的场景。

3. 常用负载均衡算法

在 backend 部分通过 balance 指令指定：

• roundrobin（轮询）：最常用的算法，请求按顺序轮流分发到各个服务器，适用于服务器性能相近的场景。
• leastconn（最少连接）：将请求分发给当前活动连接数最少的服务器，适用于长连接或服务器处理能力差异较大的场景。
• source（源地址哈希）：根据客户端 IP 进行哈希计算，确保同一个客户端的请求始终被转发到同一台服务器，用于实现会话保持。

4. 健康检查

在 server 行末尾添加 check 参数，HAProxy 就会定期向后端服务器发送探测请求，自动将故障服务器从负载均衡池中剔除，并在其恢复后重新加入。

server web1 192.168.1.10:80 check

5. 快速安装与启动（以 Ubuntu 为例）

# 安装
sudo apt update
sudo apt install haproxy -y

# 启动并设置开机自启
sudo systemctl start haproxy
sudo systemctl enable haproxy

# 验证
haproxy -v

三、HAProxy vs. Nginx：核心区别

虽然两者都能做反向代理和负载均衡，但它们的基因和设计哲学完全不同。

维度	HAProxy	Nginx
核心定位	专业负载均衡器，为高可用、高并发代理而生	全能型 Web 服务器，兼具反向代理功能
擅长领域	四层（TCP）和七层（HTTP）复杂负载均衡、精细流量控制	处理静态内容（如图片、CSS）、高并发 HTTP 服务、缓存
配置风格	扁平、面向代理的配置，ACL（访问控制列表）功能强大灵活	层级分明的块状结构，功能模块丰富
健康检查	提供丰富且高级的健康检查机制	基础的健康检查功能
典型应用	数据库流量分发、微服务网关、大规模 Web 集群入口	静态资源服务器、作为 Kubernetes Ingress 控制器

一句话总结：如果你需要一个专业、高效、稳定的流量入口，选 HAProxy；如果你需要一个多功能、能直接提供网页服务的软件，选 Nginx。

特别提示：两者并非只能二选一。在实践中，一个常见的黄金组合是 Nginx 处理静态内容，HAProxy 负责复杂的负载均衡，各司其职。

四、主要使用场景

由于 HAProxy 在负载均衡领域的专业性，它被广泛应用于以下场景：

1. 大型 Web 应用集群入口
   作为整个网站流量的总入口，将海量请求按策略分发到成千上万的后端 Web 服务器，是构建高可用 Web 架构的核心组件。
2. 数据库层负载均衡
   对 MySQL、PostgreSQL、Redis 等数据库集群进行 TCP 层的负载均衡，实现读写分离或故障转移，这是 Nginx 不太擅长的领域。
3. 微服务 API 网关
   在微服务架构中，作为统一的 API 网关，根据请求路径、Header 等信息，将请求动态路由到不同的后端微服务。
4. 构建全球 PoP（接入点）网络
   如 Stadia Maps 的案例所示，利用 HAProxy 在全球部署边缘节点，将认证、限流等通用逻辑下沉到边缘，极大提升用户体验和服务可靠性。
5. 大规模容器化环境路由
   如 PayPal 的案例，利用 HAProxy Enterprise 和 Fusion 控制平面，在拥有 6 万个容器的 Kubernetes 集群中，实现了每秒数万次的动态配置更新和毫秒级路由生效。

五、配置实战：根据 SNI 转发到不同服务（TLS 分流）

这是 HAProxy 在四层（TCP）模式下非常经典且强大的用法。当客户端通过 TLS 加密连接时，SNI（Server Name Indication）字段会以明文告知目标域名。HAProxy 可以读取这个 SNI，在不终结 TLS 的情况下，直接将加密流量路由到对应的后端服务。

适用场景

• 多域名共用同一个 VIP（IP:Port），例如 api.example.com 和 web.example.com 都监听 443 端口，但需要由不同的服务器集群处理。
• TCP 透传，需要保留客户端原始 IP 或后端需要直接处理 TLS（如数据库证书认证）。
• 节省 TLS 处理开销，由后端服务器自己负责加解密。

配置示例（TCP 四层模式）

global
    log /dev/log local0
    maxconn 40000
    user haproxy
    group haproxy
    daemon

defaults
    mode tcp              # 工作在四层 TCP 模式
    timeout connect 5s
    timeout client 30s
    timeout server 30s
    log global

# TCP 前端：监听 443 端口
frontend ft_tcp_443
    bind *:443
    mode tcp
    # 需要开启 tcp 日志以记录 SNI 信息
    option tcplog

    # 核心：根据 SNI 进行条件匹配
    tcp-request inspect-delay 5s   # 等待 TLS Client Hello 足够数据到达
    acl is_api req.ssl_sni -m end .api.example.com
    acl is_web req.ssl_sni -m end .web.example.com

    # 根据匹配结果，将流量转发到不同的后端
    use_backend bk_api if is_api
    use_backend bk_web if is_web
    # 默认后端，如果没有匹配到任何 SNI
    default_backend bk_default

# 后端 1：处理 api 相关请求
backend bk_api
    mode tcp
    balance roundrobin
    option tcp-check
    server api1 10.0.1.10:443 check
    server api2 10.0.1.11:443 check

# 后端 2：处理 web 相关请求
backend bk_web
    mode tcp
    balance roundrobin
    option tcp-check
    server web1 10.0.2.10:443 check
    server web2 10.0.2.11:443 check

# 后端 3：默认 fallback
backend bk_default
    mode tcp
    balance roundrobin
    server default 10.0.3.10:443 check

关键指令说明

指令	作用
mode tcp	HAProxy 工作在四层，不解析 HTTP，直接透传 TCP 流量
tcp-request inspect-delay	等待客户端发送足够的数据（如 TLS ClientHello），以便读取 SNI
req.ssl_sni	HAProxy 内置的 fetch method，专门用于提取 TLS ClientHello 中的 SNI 字段
-m end	匹配后缀，如 .api.example.com 可同时匹配 v1.api.example.com 和 v2.api.example.com
use_backend ... if ...	条件执行，符合 ACL 则转入对应的 backend
option tcp-check	对后端服务器执行 TCP 健康检查（可进一步扩展为 SSL 握手检查）

补充：七层模式下的 SNI 用法

如果你的 HAProxy 需要终结 TLS（即由 HAProxy 自己处理证书），则工作在 mode http 下，SNI 的用法会略有不同。此时的 SNI 主要用于选择合适的服务器证书，而非仅用于路由。

frontend ft_https
    bind *:443 ssl crt /etc/haproxy/certs/example.pem  # 可包含多域名证书
    mode http

    # 七层模式下同样可以获取 SNI
    acl is_api ssl_fc_sni -m end .api.example.com
    acl is_web ssl_fc_sni -m end .web.example.com

    use_backend bk_api if is_api
    use_backend bk_web if is_web

生产环境注意事项

1. inspect-delay 的时间：建议设为 5s 即可，过短可能导致 SNI 尚未到达，过长则影响用户体验。
2. 证书配置：如果 HAProxy 不终结 TLS，则无需在 HAProxy 上配置证书，由后端自己管理，更安全。
3. 日志审计：建议开启 option tcplog 并在日志格式中包含 %[ssl_fc_sni]，便于排查路由是否生效。
4. 性能：四层 SNI 分流几乎不增加性能开销，因为 HAProxy 只读取首包，不做加解密。

六、总结

HAProxy 是专为负载均衡和高可用性而生的"尖刀"型软件。它通过极致的性能、丰富的策略和极强的稳定性，成为支撑现代高并发、分布式系统基石的关键组件。

核心理念：

• 专注一件事，做到极致
• 四层与七层均衡能力兼备
• ACL 灵活控制，精细路由
• 与 Nginx 互补而非替代

如果你正在构建一个需要承受大流量、对稳定性有严苛要求的系统，HAProxy 将是你在负载均衡层面无可替代的选择。