https证书与域名不匹配告警源于tls握手时证书cn/san与访问域名不符，解决关键在于证书、域名、nginx配置三者精准对齐：需确认证书san覆盖访问域名，server_name严格匹配且避免默认块误配，ssl_certificate指向含域名证书及中间证书的fullchain.pem，并确保代理链中sni和host头正确透传。
HTTPS 证书与域名不匹配告警，本质是浏览器在 TLS 握手时发现服务器返回的证书中声明的域名（CN 或 SAN）和用户实际访问的域名对不上。Nginx 本身不直接触发该告警，但它作为终端 Web 服务器或反向代理，配置不当会直接导致这一问题。解决重点不是“屏蔽警告”，而是让证书、域名、配置三者精准对齐。
确认证书是否覆盖当前访问域名
这是最常见也最容易忽略的一环。证书必须明确包含用户正在访问的完整域名：
- 检查证书 SAN（Subject Alternative Name）字段：用
openssl x509 -in cert.pem -text -noout | grep -A1 "Subject Alternative Name"查看； - 若访问
www.example.com，证书需包含www.example.com，仅含example.com不足以覆盖（除非使用通配符或显式列出）； - 通配符证书
*.example.com无法匹配根域example.com或三级域名api.www.example.com； - 多域名场景务必使用 SAN 证书，且所有域名都列在同一个证书中，不要混用多个单域名证书。
确保 Nginx server_name 与证书域名严格一致
Nginx 依靠 server_name 决定启用哪个 SSL 上下文，错配会导致返回错误证书：
- 每个 HTTPS 站点应有独立的
server块，监听443 ssl，并明确写全匹配域名：server_name example.com www.example.com; - 避免把不相关的域名塞进同一个
server_name列表——Nginx 不会按需选证，而是按块加载证书； - 检查是否有未定义的域名被默认
server拦截：Nginx 总会把不匹配任何server_name的请求交给第一个listen 443 ssl的server块，它所配的证书很可能不适用于该请求； - 生产环境建议显式设置一个兜底
server块，返回 444 或重定向，避免意外证书暴露。
验证证书链是否完整且正确拼接
90% 的浏览器红叉并非域名不匹配，而是证书链缺失——客户端无法构建信任路径：
- Nginx 的
ssl_certificate必须指向包含**域名证书 + 所有中间证书**的合并文件（如fullchain.pem），不能只放cert.pem； - 顺序必须是：域名证书在最前，中间证书依次追加，根证书通常不放入；
- 用命令验证：
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep "subject\|issuer"，应输出至少两段不同 issuer 的证书； - Let’s Encrypt 用户请直接使用
fullchain.pem，勿替换为cert.pem。
排查代理链中的 Host 头篡改
当请求经过 CDN、负载均衡器或其它代理时，原始 Host 头可能被覆盖，导致 Nginx 加载了错误的 server 块：
- 检查 Nginx 日志中
$host和$http_host是否与用户真实访问域名一致； - 若使用 Cloudflare、阿里云全站加速等，需在 CDN 控制台开启「透传原始 Host」，并确保传递
X-Forwarded-Host； - Nginx 中可添加
proxy_set_header Host $http_x_forwarded_host;（仅限反向代理场景），但注意这不影响server_name匹配逻辑； - 真正影响证书选择的是 TLS 层的 SNI，由客户端发起，Nginx 无法修改——所以前端代理必须保证客户端 SNI 正确到达 Nginx。
