SNI（服务器名称指示）是一种 TLS（传输层安全）扩展，其中客户端在 TLS 握手中向服务器提供它想要访问的目标的域名。它用于在同一 IP 地址上有多个具有不同证书的虚拟服务器的情况下，以便服务器可以提供正确的证书。

到目前为止，它类似于 HTTP 请求中的 HTTP 主机头，用于选择匹配的虚拟主机配置 - 只有 Host 头不能用于选择证书，因为它是在HTTP 请求内部发送的。（即在 TLS 握手已经完成之后）。

由于 SNI TLS 扩展是可选的，因此某些客户端可能不会发送此扩展。openssl s_client没有参数的情况就是这种情况-servername，但不同编程语言的许多 TLS 库也是如此。虽然所有现代浏览器都使用 SNI，但 XP 上的 IE8 等较旧的浏览器不使用它。

如果这样的客户端连接到具有多个证书的服务器，服务器不知道客户端实际需要哪个证书，即客户端因不使用SNI扩展而落入“SNI洞”。在这种情况下，服务器通常要么发回错误（或者有时只是关闭连接），要么使用为此目的显式或隐式配置的默认证书。

SNI 漏洞是指您为 IP 地址设置的默认站点不需要存在 SNI 即可完成 HTTPS 连接。

事实上，这就是所有HTTPS 连接在 SNI 存在之前的工作方式。每个 HTTPS 站点都需要一个可路由的 IP 地址，而不仅仅是主机名。因此，当以这种方式设置时，对该 IP 地址的任何端口 443 请求都将解析到该站点，即使您有许多使用虚拟主机名的 HTTP（端口 80）站点也是如此。对于为多个站点重复使用网络服务器，然后决定为其中一个站点设置 SSL/HTTPS 的人来说，这是一个长期存在的问题。如果你正在运行http://example.com和http://contoso.com在同一台服务器上，然后设置HTTPS的example.com，对于结果http://contoso.com还是会正常工作，但要求https://contoso.com将返回结果https://example.com，尽管有证书错误。

你在这里看到的实际上是同一件事。如果您不发送 SNI 扩展程序告诉 Google 的服务器您尝试连接的主机名，则 Google 网络服务器 IP 地址的默认值是google.com站点，因此无论您尝试连接哪个主机名，它将是google.com那会回应的。

您联系了一个 SNI 服务器，该服务器实际上有多个 SSL 域和一个非 SNI 客户端。服务员猜错了。

使用 HTTP/1.0 客户端联系 HTTP/1.1 服务器时的基本情况相同。服务器猜测。