使用 HAProxy 做负载均衡时的 SSL 卸载与透传技巧

用HAProxy  处理SSL证书流量主要有两种模式：SSL卸载（Offloading，也常被称为SSL终止）和  SSL  透传（Passthrough）。简单来说，前者是HAProxy帮你搞定加解密，让后端服务器“轻装上阵”；后者是HAProxy只负责“传话”，把加密流量原封不动地交给后端服务器处理。

下面是它们核心区别的对比：

特性      SSL  卸载  (SSL  Offloading)      SSL  透传  (SSL  Passthrough)  

处理层级          七层  (HTTP)      四层  (TCP)  

SSL  证书位置        统一在  HAProxy  上      在各个后端服务器上  

HAProxy  处理        解密流量，再以明文或新加密连接转发      不解密，只做  TCP  流量转发  

后端连接        HTTP  或  HTTPS      保持原有的  HTTPS  连接  

内容感知能力          强（可基于  URL、Header  等路由）      弱（仅能基于  IP、端口或  SNI  路由）  

主要优势          集中管理证书，减轻后端压力      安全性高，端到端加密，配置简单  

主要劣势          HAProxy  与后端间为内网明文流量，存在风险      HAProxy  无法查看或修改请求内容  

一、卸载  (SSL  Offloading)  配置技巧

SSL卸载将SSL/TLS加解密的繁重工作从后端服务器“卸载”到高性能的HAProxy上，能显著提升后端服务的处理能力。

1.  基础配置：快速实现SSL卸载

这个配置将监听443端口的HTTPS流量，解密后转发给后端的HTTP服务。

haproxy

#  /etc/haproxy/haproxy.cfg

global

        #  全局设置

        daemon

        maxconn  10000

defaults

        mode  http                                          #  工作在七层  HTTP  模式

        timeout  connect  5s

        timeout  client  50s

        timeout  server  50s

#  HTTP  流量重定向到  HTTPS（最佳实践）

frontend  http_redirect

        bind  *:80

        redirect  scheme  https  code  301

#  HTTPS  前端

frontend  https_front

        bind  *:443  ssl  crt  /etc/haproxy/certs/example.com.pem

        mode  http

        #  向后台传递客户端真实  IP  和协议信息

        option  forwardfor

        http-request  add-header  X-Forwarded-Proto  https

        default_backend  web_servers

#  后端服务器池

backend  web_servers

        balance  roundrobin

        #  健康检查

        option  httpchk  GET  /health

        server  web1  192.168.1.10:80  check

        server  web2  192.168.1.11:80  check

  `bind  *:443  ssl  crt  <证书文件路径>`：绑定443端口，启用SSL，并指定证书文件。

  `option  forwardfor`  和  `add-header  X-Forwarded-Proto  https`：关键技巧，确保后端服务器能获取客户端真实IP和原始协议，方便应用处理。

-  `redirect  scheme  https  code  301`：强制将HTTP请求301重定向到HTTPS，是全站加密的最佳实践。

2.  进阶技巧：SSL卸载到后端HTTPS（SSL  Bridging）

如果出于安全合规要求，HAProxy与后端服务器之间也必须加密，可以配置SSL  Bridging。这会启用两次SSL/TLS握手，带来更高的安全性，但也会消耗更多HAProxy的CPU资源。

haproxy

#  在前端与后端间保持全程加密

backend  web_servers_ssl

        balance  roundrobin

        option  httpchk  GET  /health

        #  关键:  server  行使用  ssl  参数和后端HTTPS端口，verify  none  为跳过证书验证（生产环境应配置  ca-file  进行验证）

        server  web1  192.168.1.10:443  ssl  verify  none  check

        server  web2  192.168.1.11:443  ssl  verify  none  check

3.  最佳实践：安全与性能

  合并证书：将证书（`.crt`）和私钥（`.key`）合并成一个  `.pem`  文件供HAProxy加载。

  强化TLS安全：建议显式禁用老旧、不安全的协议和加密套件。

    haproxy

    global

            #  仅允许  TLSv1.2  及以上

            ssl-default-bind-options  ssl-min-ver  TLSv1.2  no-tls-tickets

使用强加密套件：配置安全的密码套件列表，可根据自身合规要求选择。

自动证书管理：面对证书有效期不断缩短的趋势（已减至47天），强烈建议集成ACME协议（如Let's  Encrypt）实现证书的自动申请和续期，以避免服务中断。

优化SSL性能：开启HAProxy的SSL硬件加速（如AES-NI）及会话复用（Session  Resumption）等功能，可有效提升处理能力。

二、SSL  透传  (SSL  Passthrough)  配置技巧

SSL透传模式让HAProxy在四层（TCP）转发SSL流量，不解密，保证加密数据端到端直达后端服务器。后端服务器独立完成SSL握手，非常适合安全性要求极高的场景。

1.  基础配置：TCP模式透传

这是最简单的SSL透传配置，HAProxy根据端口将流量转发。

haproxy

#  /etc/haproxy/haproxy.cfg

defaults

        mode  tcp                                          #  工作模式切换为四层  TCP

        timeout  connect  5s

        timeout  client  50s

        timeout  server  50s

frontend  mysql_front

        bind  *:3306                                    #  监听  MySQL  端口

        default_backend  mysql_servers

backend  mysql_servers

        balance  roundrobin

        server  db1  192.168.1.101:3306  check

        server  db2  192.168.1.102:3306  check

frontend  https_passthrough

        bind  *:443

        mode  tcp

        default_backend  ssl_servers

backend  ssl_servers

        balance  roundrobin

        server  web1  192.168.1.10:443  check

        server  web2  192.168.1.11:443  check

  `mode  tcp`：关键设置，将模式切换为四层TCP代理。

  检查：在TCP模式下，健康检查（`check`）默认只检查端口是否存活，更为高效。

2.  高级技巧：基于SNI的路由

一个IP和端口（如443）背后有多个HTTPS服务时，SNI（Server  Name  Indication）成为区分流量的关键。HAProxy可以“窥探”TLS握手中的SNI信息，实现智能路由，无需解密。

haproxy

frontend  https_sni_routing

        bind  :443

        mode  tcp

        #  关键:  配置检查延迟，等待足够数据以分析SNI

        tcp-request  inspect-delay  5s

        #  接受包含SSL  hello的数据包

        tcp-request  content  accept  if  {  req_ssl_hello_type  1  }

        #  根据SNI域名进行路由

        use_backend  bk_api  if  {  req_ssl_sni  -i  api.example.com  }

        use_backend  bk_admin  if  {  req_ssl_sni  -i  admin.example.com  }

        default_backend  ssl_default

backend  bk_api

        mode  tcp

        server  api1  10.0.0.10:443  check

        server  api2  10.0.0.11:443  check

backend  bk_admin

        mode  tcp

        server  admin1  10.0.0.20:443  check

  `req_ssl_sni  -i  <domain>`：这是实现SNI路由的核心ACL，用于检查TLS请求中的服务器名称。

3.  最佳实践：保留客户端真实IP

在透传模式下，后端服务器看到的来源IP将是HAProxy的内网IP。如果需要获取客户端真实IP，需要使用  Proxy  Protocol**。

haproxy

#  HAProxy  前端配置

frontend  https_passthrough

        bind  :443

        mode  tcp

        default_backend  ssl_servers

#  HAProxy  后端配置，启用  send-proxy-v2

backend  ssl_servers

        mode  tcp

        server  web1  192.168.1.10:443  send-proxy-v2  check

        server  web2  192.168.1.11:443  send-proxy-v2  check

同时，需要在后端的Nginx/Apache中配置启用Proxy  Protocol，才能正确解析客户端真实IP。

三、选型建议：何时用卸载，何时用透传？

选择  SSL  卸载，如果：

      你需要根据HTTP层面的信息（如URL路径、Cookie）进行智能路由。

      希望简化后端服务器的配置，统一管理SSL证书，降低运维成本。

      后端服务器性能有限，希望将加解密计算压力从它们身上移除。

选择  SSL  透传，如果：

      后端服务有严格的合规性或安全要求，必须实现端到端的加密，不希望任何中间节点解密数据。

      后端服务需要基于客户端证书进行mTLS（双向TLS）认证，HAProxy不解密就无法处理这一过程。

      追求极致的转发性能，且不需要HAProxy处理HTTP层面的内容。

四、总结

方面      SSL  卸载  (Offloading)      SSL  透传  (Passthrough)  

模式        HTTP  (`mode  http`)      TCP  (`mode  tcp`)  

核心价值    高性能  +  智能路由      高安全  +  极致性能  

证书位置        HAProxy    各后端服务器  

HAProxy配置          相对复杂，需加载证书      非常简单，只需绑定端口  

后端配置    简单（多数接收HTTP）    需配置独立证书和Proxy  Protocol  

IP透传方法          通过  `X-Forwarded-For`  Header    必须使用Proxy  Protocol  

适用场景        Web网站、API网关、微服务      数据库、高安全要求的HTTPS服务、mTLS  

简单来说，处理普通的Web流量和API时，SSL证书卸载是功能与性能兼顾的主流选择；而在面对需要最高等级安全和合规的场景，或是处理非HTTP协议时，SSL透传则是更合适的方案。