多域名共用证书链冲突源于nginx无法按sni精准分发证书，需确保各域名独占server块、显式配置完整ssl指令、证书san覆盖全部域名，并验证sni传递与兜底逻辑。
多域名共用证书链时的冲突，本质不是“链本身出错”，而是 Nginx 在 TLS 握手阶段无法把正确的证书链精准分发给对应的域名请求。排查重点不在证书内容，而在 SNI 匹配逻辑、server 块隔离性与链文件的实际加载路径是否对齐。
确认共用证书链是否合法覆盖所有域名
通配符或 SAN 证书才能安全共用；否则会触发“证书不匹配”警告：
- 运行 openssl x509 -in fullchain.pem -text -noout | grep -A1 "Subject Alternative Name"，检查输出中是否明确列出每一个要服务的域名（如 DNS:site-a.com、DNS:site-b.net 或 DNS:*.example.com）
- 若使用通配符 *.example.com，它不自动包含 example.com（根域）或 dev.api.example.com（二级子域），必须显式补全
- Let’s Encrypt 的多域名证书需在申请时一次性指定全部 -d 参数，后续不能追加
验证每个域名是否独占独立 server 块且配置一致
Nginx 不会根据 Host 头动态切换证书；共用链的前提是每个域名都有自己的 server 块，并指向同一份 fullchain.pem：
- ✅ 正确：两个块分别写 server_name site-a.com; 和 server_name site-b.net;，且都配置 ssl_certificate /path/to/fullchain.pem;
- ❌ 错误：把 server_name site-a.com site-b.net; 写在同一块里——Nginx 只加载第一个匹配的证书上下文，第二个域名实际无 SSL 上下文或 fallback 到默认块
- 确保两个块都含完整 SSL 指令：ssl_certificate、ssl_certificate_key、listen 443 ssl，缺一不可
检查 Nginx 是否因配置顺序导致“默认接管”
当请求的域名未被任何 server_name 精准匹配，Nginx 会交给该端口下第一个定义的 HTTPS server 块处理——这常造成“本该访问 site-b.net 却拿到 site-a.com 的证书”：
- 用 openssl s_client -connect your-ip:443 -servername site-b.net -showcerts 显式带 SNI 测试，观察返回的第一块证书是否为 site-b.net 的证书
- 若返回的是 site-a.com 的证书，说明 site-b.net 的 server 块未生效，可能被语法错误、include 顺序靠后或 default_server 覆盖
- 在所有租户块之前，显式定义一个兜底块：server { listen 443 ssl default_server; server_name _; return 444; }，避免意外泄露证书
抓包验证 SNI 字段是否真实送达 Nginx
浏览器或客户端若未发送 SNI（如老旧设备、curl 未加 -servername），Nginx 就无法区分域名，只能 fallback：
- 用 Wireshark 抓取客户端到 Nginx 的 443 流量，过滤 tls.handshake.type == 1，查看 Client Hello 中的 SNI 字段值是否为你期望的域名（如 site-b.net）
- 若 SNI 为空或为 IP，说明客户端不支持 SNI，此时需确保兜底块行为可控（如 return 444），而非返回某张业务证书
- CDN 或 WAF 回源时可能覆盖原始 SNI，需确认其是否透传 Host 和 SNI，必要时在 Nginx 中用 proxy_ssl_name $http_x_forwarded_host; 替代 $host
