什么是 SNI？在一个 IP 地址上运行多个 SSL 证书

在 HTTPS 的早期，一个服务器每个 IP 地址只能有一个 SSL 证书。在一个服务器上托管多个 HTTPS 域需要多个 IP。SNI 完全解决了这个问题。本文解释了什么是 SNI、它如何工作，以及为什么它对现代网络托管很重要。

什么是 SNI？

SNI 代表服务器名称指示。它是 TLS 协议的一个扩展，允许客户端（浏览器）在 TLS 握手期间指定它想要连接到的主机名 — 在建立 SSL 连接之前。

简单来说，SNI 告诉服务器浏览器连接到哪个域，这样服务器即使在多个域共享同一 IP 地址时也可以返回正确的证书。

SNI 之前的问题

问题在于 SSL/TLS 握手发生在浏览器发送包含 Host Header 中的域名的 HTTP 请求之前。服务器无法知道要返回哪个证书。

在 SNI 之前，网络托管需要：

• 每个启用 SSL 的域需要一个专用 IP
• 由于 IP 有限，共享主机上的 SSL 很困难
• 提供商对每个 SSL 域的额外 IP 地址收费

SNI 如何解决问题

SNI 向 TLS Client Hello 消息添加了一个"server_name"字段 — 这是客户端在 TLS 握手期间发送的第一条消息。该字段告诉服务器客户端想要连接到哪个域。

SNI 工作流程：

1. 浏览器启动 TLS 握手并在 Client Hello 中包含域名
2. 服务器读取 SNI 字段并选择正确的证书
3. 服务器将证书发送回浏览器
4. 浏览器验证证书并建立 HTTPS 连接

浏览器对 SNI 的支持

所有现代浏览器都完全支持 SNI：

• Chrome — 自 Chrome 6（2010 年）起支持
• Firefox — 自 Firefox 2（2006 年）起支持
• Safari — 自 Safari 3（2007 年）起支持
• Edge / IE — Windows Vista 及以上的 IE8+，所有 Edge 版本
• 移动设备 — iOS Safari 和 Android Chrome 完全支持

不支持 SNI 的旧版浏览器（如 Windows XP 上的 IE6）如今市场份额可以忽略不计。

在您的服务器上配置 SNI

Apache

Apache 自版本 2.2.12 起支持 SNI，在端口 443 上使用 NameVirtualHost：

<VirtualHost *:443>
    ServerName domain1.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain1.crt
    SSLCertificateKeyFile /etc/ssl/domain1.key
</VirtualHost>

<VirtualHost *:443>
    ServerName domain2.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain2.crt
    SSLCertificateKeyFile /etc/ssl/domain2.key
</VirtualHost>

Nginx

Nginx 自版本 0.5.23 起支持 SNI，使用单独的服务器块：

server {
    listen 443 ssl;
    server_name domain1.com;
    ssl_certificate /etc/ssl/domain1.crt;
    ssl_certificate_key /etc/ssl/domain1.key;
}

server {
    listen 443 ssl;
    server_name domain2.com;
    ssl_certificate /etc/ssl/domain2.crt;
    ssl_certificate_key /etc/ssl/domain2.key;
}

AsiaGB 共享主机上的 SNI

AsiaGB 托管运行 DirectAdmin，完全支持 SNI。客户可以在共享 IP 上为不同的域和子域安装多个 SSL 证书，无需额外配置。这对免费的 Let's Encrypt 和付费 SSL 证书都有效。

您应该了解的 SNI 限制

虽然 SNI 解决了核心的每个域需要一个 IP 的问题，但在设计基础设施之前，值得理解一些边界情况。

1. 不支持 SNI 的旧客户端

例子包括比 Java 7 更旧的 Java 虚拟机、链接到旧 OpenSSL 版本的 curl 旧版本，以及某些嵌入式或工业设备上的 SSL 库。如果您必须严格支持这些客户端，可能仍然需要为该域设置专用 IP。

2. SNI 不是通配符

SNI 让服务器识别每个域的正确证书 — 但这并不意味着一个证书覆盖所有域。您仍然需要每个域的单独证书，或者一个覆盖单个主域所有子域的通配符证书。

3. SNI 和加密客户端 Hello (ECH)

标准 SNI 的一个已知限制是域名在 TLS Client Hello 中以明文形式发送，这意味着网络观察者可以看到用户连接到哪个域。加密客户端 Hello (ECH) 通过加密主机名来解决这个问题 — 现代浏览器越来越多地支持它。这不会改变 SNI 在服务器端的工作方式。

SNI vs. 通配符 SSL：您应该选择哪一个？

当您在一个主域上有多个子域时，有两种主要方法：每个子域使用单独的证书（依赖 SNI 进行路由）或一个覆盖所有子域的通配符证书。

AsiaGB 通配符 SSL 证书从 5,000 泰铢/年起（RapidSSL 通配符），这对拥有多个子域的网站来说成本非常低。

测试您的服务器是否支持 SNI

在将多个域迁移到一个 IP 之前，使用以下任何方法确认您的服务器正确处理 SNI。

方法 1：OpenSSL

# Test SNI with OpenSSL — includes domain name in Client Hello
openssl s_client -connect YOUR_SERVER_IP:443 \
  -servername domain1.com \
  -verify_return_error

# Check "subject" in the output — must match domain1.com
# Repeat for domain2.com to confirm a different certificate is returned

方法 2：curl

# curl supports SNI from version 7.18.1 onward
curl -vI --resolve domain1.com:443:YOUR_IP https://domain1.com 2>&1 | grep -E "subject|issuer|SSL"
curl -vI --resolve domain2.com:443:YOUR_IP https://domain2.com 2>&1 | grep -E "subject|issuer|SSL"

方法 3：在线工具

SSL Labs (ssllabs.com/ssltest/) 提供您的服务器向浏览器提供的证书的详细分解，包括 SNI 是否在多个测试 IP 上正确工作。

SNI 与负载均衡器和反向代理

在更复杂的基础设施中 — 例如 Web 服务器前面的负载均衡器，或充当反向代理的 Nginx — 只要在终止 SSL 连接的层配置，SNI 就会继续正确工作。

带有 SNI 的 Nginx 反向代理

# Nginx terminates HTTPS with SNI, then forwards plain HTTP to backends
server {
    listen 443 ssl;
    server_name shop.example.com;
    ssl_certificate     /etc/ssl/shop.crt;
    ssl_certificate_key /etc/ssl/shop.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.crt;
    ssl_certificate_key /etc/ssl/api.key;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
    }
}

Nginx 读取 Client Hello 中的 SNI 字段，选择正确的证书，并将请求转发到相应的后端 — 所有都在来自单个 IP 地址的端口 443 上进行。这种模式是在一个服务器上托管多个服务、API 和前端的标准架构。