Apache SNI配置生效但返回兜底证书，本质是请求被默认或靠前的<VirtualHost *:443>块捕获；需检查DUMP_VHOSTS匹配顺序、清除/修正兜底配置、确保各虚拟主机独立完整配置SSL指令及ServerName/ServerAlias，并验证证书SAN与域名严格一致。
apache 开启 sni 后仍出现“兜底证书”（即访问 a 域名却返回 b 域名的证书），本质不是 sni 没开，而是 sni 虽被接收，但路由逻辑没落到目标虚拟主机——请求被默认或靠前的 <virtualhost *:443> 块捕获并返回了它的证书。解决关键在于切断错误兜底路径、确保域名精准匹配、杜绝 ssl 指令泄露。
检查并清除默认/靠前的 HTTPS 虚拟主机
Apache 不按域名查表，而是按配置加载顺序匹配；若第一个 <VirtualHost *:443> 没设 ServerName 或只配了 IP，它就会无差别接收所有未明确匹配的 HTTPS 请求，成为静默兜底源。
- 运行
apachectl -t -D DUMP_VHOSTS，查看输出中排在最上方的*:443块是谁——它大概率就是兜底者 - 定位该配置文件（常为
00-default-ssl.conf或default-ssl.conf），临时注释或删除整个<VirtualHost *:443>块，重启 Apache 测试 - 如访问恢复正常，说明问题确由该块引发；可保留它，但必须补全
ServerName+ServerAlias，或改用<VirtualHost _default_:443>并加Redirect 404 /主动拒绝未定义域名
确保每个 HTTPS 虚拟主机完整独立配置 SSL
SSL 指令一旦写在全局上下文（如主配置或 <IfModule ssl_module> 外），会被所有 <VirtualHost *:443> 继承，导致 SNI 失效——所有站点共用同一份证书。
- 每个
<VirtualHost *:443>内必须显式包含：SSLEngine on、SSLCertificateFile、SSLCertificateKeyFile、SSLCertificateChainFile（或用fullchain.pem合并） - 严禁在
<VirtualHost>外设置任何SSLCertificate*指令，包括httpd.conf顶部或mod_ssl.c区域 - 用
httpd -M | grep ssl确认ssl_module已加载；用openssl version确保 ≥ 1.0.2（推荐 ≥ 1.1.1）
验证域名匹配与证书 SAN 是否严格一致
即使 SNI 正确路由，若 ServerName/ServerAlias 和证书的 Subject Alternative Name（SAN）不完全对应，浏览器仍会报错，而 Apache 可能退回到第一个可用证书。
- 用命令检查证书实际覆盖域名：
openssl x509 -in /path/to/cert.pem -text -noout | grep -A1 "Subject Alternative Name" - 若访问
www.example.com，证书 SAN 必须含DNS:www.example.com；仅含DNS:example.com不够，需加ServerAlias www.example.com - 通配符证书
*.example.com默认不覆盖example.com，申请时需额外指定-d example.com -d *.example.com
用 OpenSSL 模拟握手确认 SNI 路由是否生效
不依赖浏览器，直接验证服务端是否根据 SNI 返回正确证书，这是判断问题在客户端、网络还是 Apache 配置的分水岭。
- 执行：
openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | openssl x509 -noout -subject，看输出是否为你期望的域名 - 再执行不带
-servername的版本：openssl s_client -connect example.com:443 -showcerts ...，对比两次-subject输出是否不同 - 若相同，说明服务端忽略 SNI（配置未分离或模块未启用）；若不同，说明 SNI 生效，但你的域名配置或证书 SAN 仍有偏差
