SNI本身不产生切换延迟，所谓“延迟”实为握手卡顿或证书错配，根源在配置或环境缺陷；需验证客户端是否发送SNI、检查OpenSSL版本、确保证书SAN覆盖域名、排查OCSP Stapling及默认server干扰。
测试 Nginx 多域名虚拟主机在共享证书场景下的 SNI 切换延迟，本质上是个误区——SNI 本身不产生“切换延迟”。Nginx 在 TLS 握手阶段根据客户端发来的 SNI 值做哈希查找，毫秒级完成，不存在逐个匹配 server 块的“切换”过程。所谓“延迟”，实际是握手卡顿或证书错配的表现，根源不在 SNI 切换逻辑，而在配置或环境缺陷。
先确认是否真有 SNI 行为
很多所谓“延迟”其实源于客户端根本没发 SNI，导致 Nginx 回退到第一个 server 块处理：
- 用
openssl s_client -connect your.ip:443 -servername example.com -showcerts测试：若返回的证书 CN/SAN 包含example.com，说明 SNI 生效；若返回的是另一个域名的证书（比如site-b.net），说明 SNI 未被识别或服务端不支持 - 对比测试不带
-servername参数：若此时返回证书变了，基本可断定是客户端未发送 SNI 或 OpenSSL 层不支持 - 检查 Nginx 编译信息：
nginx -V 2>&1 | grep -i openssl，必须显示 OpenSSL ≥1.0.2（推荐 ≥1.1.1），且不能是 BoringSSL
排查证书与 server_name 匹配问题
共享证书（如多域名 SAN 证书）时，SNI 正常但浏览器仍报错，往往因匹配逻辑被误读：
- Nginx 对 HTTPS 的 server_name 匹配只校验首个值是否在证书 SAN 中；其余域名靠 HTTP 层 $host 处理。例如：
server_name a.com b.com;+ SAN 证书含 a.com 和 b.com → SNI 握手通过；但若证书只含 a.com，b.com 就会触发浏览器警告 - 不要把泛域名和精确域名混在同一 server 块：
server_name *.example.com api.example.com;是无效写法，Nginx 只取第一个*.example.com做证书校验，api.example.com实际无法走 SNI 精确匹配 - 用
openssl x509 -in cert.pem -text -noout | grep -A1 "Subject Alternative Name"确认证书真正覆盖了哪些域名
观察真实握手耗时（而非“切换”）
真正的性能瓶颈通常出现在证书链验证或 OCSP Stapling 环节，而非 SNI 查找：
- 启用详细 SSL 日志：
error_log /var/log/nginx/error.log info;，然后看握手阶段是否有SSL_do_handshake() failed或ocsp: no response sent类报错 - 检查 OCSP Stapling 是否生效：确保每个 server 块包含完整四要素：
ssl_stapling on;、ssl_stapling_verify on;、resolver 8.8.8.8 valid=300s;、ssl_trusted_certificate /path/to/fullchain.pem; - 用
curl -vI https://a.com和curl -vI https://b.com分别测首字节时间（time_appconnect），若差异明显且都 >300ms，大概率是 OCSP 请求超时或证书链不全
避免默认 server 干扰测试结果
当多个域名共用同一 IP:443 监听，且未显式设 default_server，Nginx 会把第一个定义的 server 当作兜底。这会导致：
- 无 SNI 请求（如某些 IoT 设备）全部命中第一个块，掩盖真实 SNI 行为
- 误以为“a.com 快、b.com 慢”，其实是 b.com 被 fallback 到了 a.com 的证书链上，而 a.com 配置了 OCSP、b.com 没配
- 建议显式声明一个最小化兜底块：
listen 443 ssl http2 default_server;+ 专用 fallback 证书，并在日志中加$ssl_server_name字段便于区分
