SSLStrictSNIVHostCheck on必须在VirtualHost块或全局段中配置，因该指令属TLS握手路由控制，仅在启用SSL的上下文中有效；写在httpd.conf顶层报错、.htaccess中被忽略。
SSLStrictSNIVHostCheck on 是唯一能阻止“SNI 不匹配却落入默认站点”的配置方式，但它不解决无 SNI 请求的问题，也不校验证书本身——只管 TLS 握手时客户端报的 hostname 是否有对应 VirtualHost。
为什么必须在 VirtualHost 里配，不能写在 .htaccess 或全局顶层？
该指令属于 TLS 握手阶段的路由控制，Apache 要求它必须出现在启用 SSL 的上下文中。写在 httpd.conf 根层级会直接报错 SSLSNIVHostCheck not allowed here；放在 .htaccess 则完全被忽略——mod_ssl 不支持运行时重载该行为。
- 正确位置只有两个：
- 若你有多个 HTTPS 站点共用 IP，推荐在每个
on，避免依赖加载顺序 - 不要和
SSLInsecureRenegotiation混用在同一行——它们是独立指令，无语法组合关系
SSLStrictSNIVHostCheck on 后老设备连不上，怎么排查？
这不是 HTTP 层错误，而是 TLS 握手被 Apache 主动终止，浏览器通常显示 ERR_SSL_PROTOCOL_ERROR 或空白页，curl 会卡住或报 ssl handshake failed。
- 先确认是否真由该指令触发：用
openssl s_client -connect example.com:443 -servername wrong.example.com模拟错误 SNI，若返回no peer certificate available或立即断连，说明生效 - 测试无 SNI 场景：
openssl s_client -connect example.com:443（去掉-servername），此时即使开了on也不会拒连——它只管“有 SNI 但不匹配”，不管“没 SNI” - 常见不兼容客户端：Android 4.0 以下、IE6–8（XP）、旧版 Java 6/7 的
HttpsURLConnection，它们要么不发 SNI，要么固定发错域名
开了之后请求掉进错误站点？检查这三个地方
开启后仍被路由到非预期站点，往往不是指令失效，而是虚拟主机定义本身存在冲突或加载顺序问题。
-
ServerName和ServerAlias必须与客户端 SNI 字段完全一致（区分大小写、不含端口、不带协议），例如 SNI 发的是api.example.com，但配置里只写了ServerName www.example.com，就会匹配失败 - 确保没有其他
ServerName，否则 Apache 可能把它当作兜底默认站点（尤其在SSLStrictSNIVHostCheck off时） - 检查配置加载顺序：Apache 按文件字典序读取
a.conf、b.conf… 若某个未设ServerName的 HTTPS 站点排在前面，它可能成为事实上的 fallback，而SSLStrictSNIVHostCheck on对它无效
和 SSLOptions、证书链配置有没有关系？
完全没有。这个指令不碰证书内容、不读 SSLCertificateFile、不干预 OCSP 装订或客户端证书验证流程。它只做一件事：收到 SNI 后查表，查不到就断握手。
- 如果你同时启用了双向认证（
SSLVerifyClient require），那是另一条独立路径，SSLStrictSNIVHostCheck不影响其触发时机 - 证书链缺失、私钥权限不对、TLS 版本不匹配等问题，都会导致连接失败，但错误现象不同（比如
SSL_ERROR_BAD_CERT_DOMAIN或握手卡在 Certificate 阶段），别误判成 SNI 校验问题 - 使用 Let’s Encrypt 时，务必用
fullchain.pem（含域名证书 + 中间 CA），而不是单独的cert.pem，否则浏览器可能因链不全拒绝连接，但这和 SNI 无关
真正容易被忽略的是：它只在 SNI 存在且不匹配时起作用，对无 SNI 客户端完全透明；而生产环境中，那些“连不上”的反馈，大概率来自 Android 4.x 或嵌入式设备，它们根本不会发 SNI——这时候开 on 并不能帮你发现问题，反而掩盖了真实兼容性缺口。
