什么是 SNI（服务器名称指示）扩展？它如何在一台服务器上支持多个 HTTPS 域名，又为何会导致部分老旧客户端连接失败？

在 HTTPS 普及的早期，Web 托管面临着一个巨大的资源瓶颈：由于 TLS 加密握手发生在 HTTP 请求之前，服务器在建立安全连接时，只能看到客户端请求的 IP 地址，而无法获知客户端真正想要访问的域名。这意味着，为了让同一台服务器上的多个域名都能使用各自独立的 SSL 证书，管理员必须为每个域名分配一个独立的公网 IPv4 地址。在 IPv4 资源极度匮乏的背景下，这种“一证一 IP”的模式成本高昂且难以扩展。

SNI 的破局之道
为了打破这一僵局，IETF 在 2003 年将 SNI（Server Name Indication，服务器名称指示） 作为 TLS 协议的扩展（RFC 3546）引入。SNI 的核心机制是：允许客户端在 TLS 握手的第一步（即发送 Client Hello 消息时），以明文形式将目标域名（主机名）附带发送给服务器。

当服务器接收到这个请求后，会解析 SNI 字段，从而在 TLS 握手阶段就能精准识别出客户端想要访问的具体站点。随后，服务器会从配置中加载与该域名精确匹配的 SSL 证书，并在 Server Hello 阶段返回给客户端。通过这一机制，SNI 完美实现了“单 IP 多证书”，不仅大幅节省了 IPv4 地址资源，还让虚拟主机技术在 HTTPS 时代得以继续繁荣。

为何会导致部分老旧客户端连接失败？
尽管 SNI 极大地提升了网络基础设施的灵活性，但它也带来了一个历史遗留的兼容性痛点。由于 SNI 是作为 TLS 协议的“扩展”引入的，它要求客户端（浏览器、操作系统或应用程序）在底层网络栈中实现对该扩展的支持。

然而，在 SNI 标准发布后的很长一段时间里，许多老旧的系统和设备并没有跟进更新：
操作系统与浏览器限制：例如 Windows XP 搭配 Internet Explorer 6（甚至未打补丁的 IE8），以及 Android 2.x/3.x 等早期移动系统，它们的 TLS 协议栈中压根不包含 SNI 扩展。
嵌入式设备限制：许多老旧的嵌入式设备（如早期的 POS 终端、Cisco IP Phone、定制 ROM 设备等）由于硬件算力受限或固件长期未更新，同样无法在 Client Hello 中携带 SNI 字段。

连接失败的底层逻辑
当这些不支持 SNI 的老旧客户端尝试访问部署了 SNI 的服务器时，由于握手消息中缺失了关键的域名字段，服务器无法判断客户端究竟想访问哪个站点。此时，服务器通常会触发兜底逻辑：直接返回配置在监听端口上的第一个虚拟主机的证书（即默认证书）。

由于这个默认证书的域名通常与老旧客户端实际请求的域名不匹配，客户端在进行证书校验时，会发现证书上的通用名称（CN）或主题备用名称（SAN）与目标不符，从而直接抛出 NET::ERR_CERT_COMMON_NAME_INVALID（证书域名不匹配）或 ERR_SSL_PROTOCOL_ERROR 等致命错误，并强制终止连接。

现代视角的应对策略
虽然 SNI 兼容性曾是一个棘手的问题，但随着时间的推移，这些老旧系统的使用份额已降至可忽略不计的程度。目前，几乎所有现代浏览器、操作系统（Windows 7+、macOS、Linux、Android 4.0+）及主流编程语言环境均已完美支持 SNI。

对于极少数仍需要兼容老旧设备的特殊企业场景，管理员通常只能放弃 SNI，回归传统的“一证一 IP”方案，或者为这些特定客户端配置多域名（SAN）证书以作兼容兜底。但在绝大多数面向公众的现代 Web 架构中，SNI 早已成为不可或缺的基础标准。