Apache SNI配置不生效最典型表现是访问a.example.com却收到b.example.com证书，本质是TLS握手时服务器未按SNI域名匹配虚拟主机，导致默认或靠前站点兜底返回错误证书；需依次验证客户端是否发送SNI、服务端是否接收、OpenSSL版本及ssl_module是否启用、各是否独立完整配置SSL指令与ServerName/ServerAlias、以及DUMP_VHOSTS中匹配顺序是否正确。
apache 中 sni 配置不生效，最典型的表现是：访问 a.example.com 却收到 b.example.com 的证书，浏览器报“证书名称不匹配”或直接拒绝连接。问题本质不是证书本身错误，而是 tls 握手阶段服务器没按客户端声明的域名（sni 字段）选对虚拟主机，最终由配置靠前或默认的站点兜底返回了错误证书。
确认客户端是否真发了 SNI，服务端是否收到了
先排除“客户端没发、服务端没收”这一基础环节：
- 用 OpenSSL 模拟真实握手，显式带
-servername：openssl s_client -connect a.example.com:443 -servername a.example.com -showcerts 2>/dev/null | head -20
观察输出中证书的Subject:是否为a.example.com - 再对比不带 SNI 的情况：
openssl s_client -connect a.example.com:443 -showcerts 2>/dev/null | head -20
如果两次返回的证书不同，说明 SNI 被识别并起作用；如果相同，说明服务端忽略 SNI 或未按域名区分配置 - 加
-tlsextdebug查日志细节：openssl s_client -connect a.example.com:443 -servername a.example.com -tlsextdebug 2>&1 | grep "server name"
若看到server name: a.example.com，表示客户端已发、服务端已收
检查 Apache 是否具备 SNI 运行条件
SNI 是 TLS 层能力，依赖底层支持和模块加载状态：
- 运行
httpd -M | grep ssl或apache2ctl -M | grep ssl，确保ssl_module已启用 - 执行
openssl version，确认 OpenSSL 版本 ≥ 1.0.2（推荐 ≥ 1.1.1），老版本（如 0.9.8）虽支持 SNI 但兼容性差 - 确认主配置中有
Listen 443，且没有其他同 IP:Port 的非 SNI 兼容配置（例如遗留的ServerName）
验证每个 HTTPS 虚拟主机是否独立完整配置
SNI 生效的前提是：每个
- 每个块内必须有：
SSLEngine on、SSLCertificateFile、SSLCertificateKeyFile、SSLCertificateChainFile（或用fullchain.pem合并中间证书） - 禁用任何在
SSLCertificateFile等指令——否则所有站点会共用同一份证书，SNI 彻底失效 - 目标域名必须通过
ServerName或ServerAlias显式声明，且大小写一致、不带端口（如访问www.a.example.com，但只配了a.example.com，需补ServerAlias www.a.example.com）
查看实际生效的虚拟主机顺序与匹配结果
Apache 不查域名哈希表，而是按配置加载顺序 + ServerName 匹配。顺序错了，SNI 就白搭：
- 运行
apachectl -t -D DUMP_VHOSTS（或apache2ctl -t -D DUMP_VHOSTS），检查输出中：- 监听地址是否为
*:443 -
a.example.com对应的ServerName是否出现在列表中 - 它的位置是否在其他相似域名（如
b.example.com）之前？若靠后，而请求未命中任何ServerName/ServerAlias，就会被前面的站点捕获
- 监听地址是否为
- 检查是否有未禁用的默认站点（如
000-default.conf），它常位于配置开头或末尾，容易兜底响应所有未匹配请求
