SSLStrictSNIVHostCheck 是 Apache 2.2.12+ 控制 SNI 匹配失败时是否拒绝连接的指令，仅影响 TLS 握手阶段的 hostname 匹配；必须开启的场景是多 HTTPS 站点共用 IP 且需防止无 SNI 或错误 SNI 请求落入默认站点。
SSLStrictSNIVHostCheck 是什么，什么时候必须开
SSLStrictSNIVHostCheck 是 Apache 2.2.12+ 引入的指令，控制是否在 SNI（Server Name Indication）匹配失败时直接拒绝连接。它只对启用 SNI 的 HTTPS 虚拟主机生效，且仅影响 TLS 握手阶段——不涉及证书内容校验（比如域名匹配、过期时间），只管客户端发来的 SNI hostname 是否有对应 VirtualHost。
开启它的典型场景是：你有多个基于 SNI 的 HTTPS 站点共用一个 IP，又想防止客户端不带 SNI 或填错 hostname 时“掉进”某个默认站点（尤其是那个默认站点本不该对外暴露）。
常见错误现象：SSLStrictSNIVHostCheck on 后，老 Android（4.0 以下）、IE6/7/8（XP）、OpenSSL
如何正确配置 SSLStrictSNIVHostCheck
该指令必须放在全局或 VirtualHost 上下文中，不能写在 .htaccess 里。它本身不校验证书，所以和 SSLCertificateFile、SSLVerifyClient 无关。
- 全局强制（推荐用于多租户或安全敏感环境）：
SSLStrictSNIVHostCheck on
- 仅对特定虚拟主机启用：
<virtualhost><br> ServerName example.com<br> SSLCertificateFile /path/to/example.crt<br> SSLStrictSNIVHostCheck on<br></virtualhost>
- 关闭（默认行为）：
SSLStrictSNIVHostCheck off
—— 此时若无匹配 SNI，Apache 会回退到第一个加载的 HTTPSVirtualHost（按配置文件顺序）
注意：SSLStrictSNIVHostCheck 不影响非 SNI 客户端的行为逻辑；它只让“SNI 有但不匹配”的情况变严格。没有 SNI 的连接仍走默认虚拟主机，不受此指令约束。
为什么开了之后某些请求 503 或直接断连
这不是 Apache 返回 HTTP 状态码，而是 TLS 层直接终止握手，浏览器通常显示为网络错误而非 503。根本原因是客户端不支持 SNI，或发送了错误的 SNI name（比如请求 https://a.example.com 却在 SNI 字段填了 b.example.com）。
排查建议：
- 用
openssl s_client -connect example.com:443 -servername example.com测试正常流程 - 去掉
-servername参数模拟无 SNI 请求，观察是否被拒（SSLStrictSNIVHostCheck on时应返回no peer certificate available或直接 close） - 检查
VirtualHost的ServerName和ServerAlias是否覆盖所有可能的 SNI 值；通配符不生效，必须显式列出 - 确认没有两个
VirtualHost声明相同的ServerName，否则 Apache 启动会报错或行为未定义
和 SSLCertificateCheck、OCSP Stapling 完全无关
SSLStrictSNIVHostCheck 不触发任何证书链验证、CRL 检查或 OCSP 查询。它发生在 TLS ClientHello 解析后、ServerHello 发出前，早于证书传输阶段。
如果你真正想要的是“证书域名必须匹配 Host 头”，那是应用层逻辑，得靠 mod_ssl 的 SSLRequire（已废弃）或更可靠的方式：在应用中读取 SSL_SERVER_S_DN_CN 或用 SSLOptions +StdEnvVars 暴露变量后做判断。
容易被忽略的一点：即使开了 SSLStrictSNIVHostCheck on，只要客户端 SNI 匹配任意一个 VirtualHost，哪怕那个站点证书已过期、域名不匹配、自签名，Apache 仍会继续握手——证书有效性检查是后续独立步骤。
