android 2.3不支持sni，导致https握手时无法发送server_name字段，服务器返回默认证书引发sslhandshakeexception；无配置绕过方案，唯一可行策略是单域名单证书部署。
apache 本身不直接处理 android 2.3 的 sni 兼容问题，真正涉及 sni 兼容性的是 客户端（如 android webview 或内置浏览器）与服务端 tls 握手过程。android 2.3（api 级别 10）的系统 webview 和 httpsurlconnection 不支持 sni 扩展，这是根本限制。
这意味着：当你的 Apache（或任何后端服务器，包括 APISIX、Nginx）配置了基于 SNI 的多证书（例如为 a.example.com 和 b.example.com 各配不同证书），而 Android 2.3 客户端发起 HTTPS 请求时：
- 它不会在 ClientHello 中发送
server_name扩展； - 服务器无法得知客户端想访问哪个域名；
- 通常会返回默认虚拟主机的证书（可能是不匹配的、自签名的，或完全错误的证书）；
- 客户端校验失败，抛出
javax.net.ssl.SSLPeerUnverifiedException或SSLHandshakeException，表现为“证书不匹配”“无法建立安全连接”。
SNI 在 Android 2.3 上不可用，没有绕过方案
Android 对 SNI 的原生支持始于 Android 4.0（API 14）；
Android 2.3（Gingerbread）的 OpenSSL 版本（通常为 0.9.8）和 Java SSL 栈硬编码不发送 SNI 字段，且无公开 API 可启用。
因此：
- ❌ 不能通过 Apache 配置开关、RewriteRule 或 SSL 指令“开启 SNI 兼容”；
- ❌ 不能靠 Java 层设置
SSLSocketFactory或HostnameVerifier来修复握手阶段缺失的 SNI； - ❌ 不是证书格式（PEM/DER）、密钥长度或 TLS 版本问题——是协议扩展缺失。
实际可行的应对策略
如果你必须支持 Android 2.3（已极度罕见，2026 年存量可忽略），只能从架构层面规避 SNI 依赖：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
单域名 + 单证书部署
所有服务共用一个权威域名（如api.yourapp.com），使用一张覆盖该域名的证书（无需泛域名或多个 SNIs）。Apache 虚拟主机只配置一个ServerName，不依赖 SNI 区分。避免虚拟主机级证书分离
不要在同一 IP+端口上为多个域名配置不同 SSL 证书。Apache 的<virtualhost></virtualhost>若启用了SSLEngine on且含多个ServerAlias，仍需 SNI 才能选对证书——这在 2.3 下必然失败。降级到 HTTP（仅限内网/调试场景）
开发或测试时，可临时关闭 HTTPS，用http://+ 自定义 Header 鉴权，但绝不适用于生产环境。前端代理兜底（不推荐）
在 Apache 前加一层支持 SNI 的反向代理（如 Nginx），让它根据 Host 头路由并终止 HTTPS；但 Android 2.3 仍需先完成 TLS 握手才能发 Host 头——此路不通。
补充说明：APISIX 场景同理
你知识库中提到的 APISIX SNI 配置（snis: ["test.com"]）同样受此限制：Android 2.3 请求 https://test.com:9443 时，APISIX 收不到 SNI，若配置了多个 SSL 对象，就可能返回默认证书或握手失败。解决方式唯一：确保该端口只绑定一个有效 SNI 证书，且该证书的域名与客户端请求的 Host 完全一致（包括无泛域名歧义）。
本质上，这不是 Apache 或 APISIX 的配置问题，而是客户端能力断层。2026 年继续兼容 Android 2.3 已无现实必要，建议明确最低支持版本为 Android 4.1+（API 16）。
