Apache不支持SNI透传，因SNI属TLS握手阶段信息，无法随HTTP头传递；其mod_proxy_http仅基于URL中的域名自动发送SNI，后端须用域名而非IP配置，且需启用SSLProxyEngine on。
apache 本身不原生支持在负载均衡层对后端服务做 sni（server name indication）透传，因为 mod_proxy_balancer 默认使用 http/1.1 协议转发，而 sni 是 tls 握手阶段的扩展，只在建立 https 连接时由客户端发送、服务器端响应。也就是说：sni 信息不会随 http 请求头传递，也无法被 apache 自动提取并“转发”给后端 https 服务——它只存在于客户端与 apache 之间，或 apache 与后端之间各自独立的 tls 握手环节。
为什么 Apache 不需要“透传 SNI”？
真正需要 SNI 的场景是：当 Apache 作为 HTTPS 客户端去连接后端 HTTPS 服务（如 Tomcat/Node.js 的 HTTPS 端口）时，必须告诉后端自己想访问哪个域名，以便后端选择对应证书。但 Apache 的 mod_proxy_http 并不参与 TLS 握手的 SNI 字段构造；它依赖底层 OpenSSL 库行为。而默认情况下：
- 如果后端地址写成
https://backend.example.com:8443，Apache 会自动把backend.example.com作为 SNI 主机名发送（基于 URL 中的 host）； - 如果后端用 IP 地址（如
https://192.168.1.10:8443），OpenSSL 默认不发 SNI，后端可能无法匹配证书，导致握手失败（尤其多域名共用 IP 时）。
正确做法：让后端识别 SNI，靠 DNS 或 Host 头配合
要实现“SNI 意图”的负载均衡效果（即不同域名走不同后端集群），应通过以下方式间接达成：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
按 Host 头路由：在
<VirtualHost>中用多个虚拟主机分别绑定不同ServerName，每个指向独立的balancer://集群； -
用 mod_rewrite + env 判断域名：结合
%{HTTP_HOST}变量，动态设置ProxyPass目标； -
后端启用 SNI 支持：确保 Tomcat/Nginx 等后端服务配置了 SNI 虚拟主机（如 Tomcat 的
<SSLHostConfig>块中定义多个<Certificate>），并监听同一 IP+端口。
实际可配的关键点
若你确实要用 Apache 代理到多个 HTTPS 后端且它们共用 IP 但需区分域名（即依赖 SNI 选证），请确保：
- 后端地址必须写成 域名形式（而非 IP），例如：
BalancerMember https://api1.example.com:8443； - Apache 必须启用
SSLProxyEngine on，否则无法发起上游 HTTPS 连接； - 若后端证书为自签名或私有 CA 签发，添加：
SSLProxyVerify none和SSLProxyCheckPeerCN off（仅测试环境）； - 不要试图用
RequestHeader set "Host"来“模拟 SNI”——这无效，SNI 发生在 TCP 连接建立初期，远早于 HTTP 头传输。
替代建议：用 APISIX 或 Nginx 更适合 SNI 路由
如果你的核心需求是「根据 SNI 域名将流量分发到不同后端集群」，Apache 并非最佳选择。APISIX、Nginx Plus 或 Envoy 原生支持 SNI 匹配路由（如 APISIX 的 ssl 对象 + snis 字段绑定路由），能直接在 TLS 层完成分流，无需应用层介入。
