Nginx 1.11.0+ 默认支持 SNI，无需手动开启；关键在于确保 OpenSSL ≥1.0.2 且非 BoringSSL、每个 server 块独立配置专属证书路径与精确匹配的 server_name，并通过 openssl s_client 验证域名对应证书是否正确返回。
直接配置就行，Nginx 1.11.0+ 默认支持 SNI，不需要额外开启开关——关键在证书路径、server 块结构和 OpenSSL 底层支持是否到位。
确认 OpenSSL 支持 SNI
这是最常被跳过的一步。运行：
nginx -V 2>&1 | grep -i openssl输出必须包含类似 OpenSSL 1.1.1w 或 OpenSSL 3.0.13 的版本号。若显示 BoringSSL、版本低于 1.0.2，或无任何 OpenSSL 输出，说明不支持 SNI，需更换官方预编译包或重编译 Nginx（启用 --with-http_ssl_module 并链接合规 OpenSSL）。
每个域名配一个独立 server 块
不能把多个域名塞进同一个 server 块里“共用”一套证书（除非是 SAN 或泛域名证书）。正确做法是：
- 每个主域名（如
site-a.com）单独写一个server块 - 每块都写
listen 443 ssl http2;（ssl参数不可省略） -
server_name列出该证书实际覆盖的所有域名，例如：server_name site-a.com www.site-a.com; -
ssl_certificate和ssl_certificate_key必须指向该域名专属的 PEM 文件，路径不能复用
证书必须一一对应且有效
Nginx 启动时不校验证书内容，但运行时严格按路径加载：
- 推荐用 Certbot 分别申请：
certbot --nginx -d site-a.com和certbot --nginx -d site-b.net - 证书目录建议隔离，如
/etc/nginx/ssl/site-a.com/fullchain.pem和/etc/nginx/ssl/site-b.net/fullchain.pem - 不要把多个域名的 leaf 证书合并进同一个 PEM 文件——这不是优化，是错误，会导致 TLS 握手失败
- 泛域名证书（如
*.example.com）只覆盖同主域子域，无法用于other.net
验证 SNI 是否真正生效
别只看浏览器，用 OpenSSL 直接测 TLS 层行为：
openssl s_client -connect your.ip:443 -servername site-a.com -showcerts 2>/dev/null | openssl x509 -noout -subject应返回 CN = site-a.com；换域名再试：
应返回另一张证书的 subject。这个测试绕过缓存、CDN 和浏览器中间层，结果最真实。
