本质是Nginx多server块在同IP:443下因匹配顺序、ssl_certificate路径错误或默认server干扰，导致请求被错误分发至非目标证书；须用nginx -T和openssl验证实际响应的server块及fullchain.pem是否匹配域名。
多域名通配符证书在 Nginx 中配置混乱，本质不是证书本身有问题，而是多个 server 块共用同一 IP:443 时，因匹配逻辑、文件指向或默认行为不一致，导致本该用通配符证书的请求被错误地塞进另一个域名的证书链里——浏览器看到“证书与域名不匹配”或“链不完整”，其实只是它拿到了别的证书。
确认哪个 server 块真正响应了你的域名
Nginx 不按配置文件顺序选块，而是根据 listen + server_name 匹配。若你同时配置了：
-
server_name *.example.com;（通配符） -
server_name api.example.com;（精确） -
server_name site-b.com;（另一个主域）
而请求的是 admin.example.com，它会命中第一个通配符块；但若你漏写了通配符块，或它排在后面，Nginx 可能 fallback 到第一个定义的 server { listen 443 ssl; } 块（即“默认 server”），而那个块绑的是 site-b.com 的证书——这就造成证书覆盖错乱。
执行：
nginx -T | grep -A 15 "listen 443" | grep -E "(server_name|ssl_certificate)"
检查每个 server 块的 server_name 是否覆盖目标域名，且 ssl_certificate 指向正确的 fullchain.pem（比如 /etc/letsencrypt/live/example.com/fullchain.pem）。
通配符证书必须用 fullchain.pem，且不能混用其他域名的链文件
Let’s Encrypt 的通配符证书（如 *.example.com）生成后，其 fullchain.pem 仅包含该域名的终端证书 + R3 中间证书。它**不能**和 site-b.com 的证书混用，也不能被 cert.pem 替代。
验证方法：
openssl s_client -connect admin.example.com:443 -servername admin.example.com -showcerts 2>/dev/null | grep "subject="
应输出两行：
→ 第一行含 CN = *.example.com
→ 第二行含 CN = Let's Encrypt R3
如果出现 CN = site-b.com 或只有 ISRG Root X1，说明证书被别的 server 块覆盖了，或 ssl_certificate 路径写错了。
避免泛域名与精确域名配置冲突
通配符 *.example.com 不匹配 example.com（裸域）。如果你希望两者都走同一张通配符证书，必须显式加一条：
server_name example.com *.example.com;
否则 example.com 请求可能落入另一个未设 server_name 的默认块，或触发重定向到 HTTP，再跳回 HTTPS 时证书已换人。
同样，不要让 server_name ~^.*\.example\.com$; 这类正则块和通配符块并存——正则优先级低于通配符但高于默认块，易引发意外交替。
检查 CDN 或本地缓存是否干扰判断
Cloudflare、阿里云 DCDN 等若开启“代理模式”，它们会终止 TLS 并用自己的证书对外，此时你查的是 CDN 的链，不是 Nginx 的。绕过 CDN 直连源站 IP 测试：
- curl -vkI --resolve admin.example.com:443:YOUR_SERVER_IP https://admin.example.com
- 或用
openssl s_client -connect YOUR_SERVER_IP:443 -servername admin.example.com
另外，Chrome / Safari 的 HSTS 缓存可能强制走 HTTPS 并记住旧证书错误，清除方式：
- Chrome：
chrome://net-internals/#hsts→ 删除域名 - iOS Safari：设置 → Safari → 清除历史记录与网站数据
