DNS污染导致HTTPS证书验证失败，本质是客户端被误导连接错误IP而收到不匹配证书，表现为首次访问报NET::ERR_CERT_COMMON_NAME_INVALID、刷新后正常或地域性异常，需通过dig/nslookup比对DNS解析、curl查实际连接IP、openssl验证书归属来逐层排查污染环节。
DNS 污染导致的 HTTPS 证书验证失败，本质不是 Nginx 配置错误，而是客户端（浏览器或 App）被误导连接到了错误的 IP 地址，进而收到了不匹配的证书。这种问题常表现为：首次访问提示“证书域名不匹配”“NET::ERR_CERT_COMMON_NAME_INVALID”，刷新后却正常；或不同地区/网络下表现不一致。排查需跳出 Nginx 日志和证书本身，聚焦 DNS 解析与连接路径。
确认是否真是 DNS 污染引发的证书错配
不要依赖浏览器一次访问结果。用命令行直接比对解析结果和实际连接目标：
- 查本地 DNS 解析：dig +short yourdomain.com 和 nslookup yourdomain.com 8.8.8.8（对比公共 DNS），看结果是否一致；若本地返回 IP A，而 8.8.8.8 返回 IP B，大概率存在污染
- 查实际建连目标：curl -vI https://yourdomain.com 2>&1 | grep "Connected to"，确认 TCP 连接的 IP 是否与你预期的服务器 IP 一致
- 查证书归属：openssl s_client -connect 实际IP:443 -servername yourdomain.com -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "(CN|DNS)"，看证书里 Subject CN 或 SAN 是否真包含 yourdomain.com —— 如果显示的是 bb.com 或 *.cdn.net，说明连到了别人的服务
区分污染发生在哪一层
DNS 污染可能出现在多个环节，需逐层排除：
- 本机 hosts 文件：检查 /etc/hosts（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows），是否有手动写入的错误映射
- 本地 DNS 服务器：路由器、公司内网 DNS 或 ISP 提供的 DNS 常是污染源。改用 1.1.1.1 或 8.8.8.8 后重试，若恢复正常，基本锁定
- 中间网络设备（如防火墙、运营商劫持）：在不同网络（家庭 WiFi、4G/5G、办公网）下分别测试 dig 和 curl。若仅某网络异常，极可能是该网络出口做了 DNS 重定向或 TLS 插件拦截
- CDN 或负载均衡器配置错误：如果你用了腾讯云 CDN、阿里云 SLB 等，检查其 CNAME 或回源配置是否指向了错误的源站，或缓存了旧的证书绑定关系
避免 Nginx 配置被误判为根因
这类问题容易让人误以为是 Nginx 证书没配好、SNI 没开或 ssl_certificate 路径错。但关键线索在于：
- error.log 中通常不会出现 SSL 相关报错（因为 TLS 握手成功了，只是证书内容不对）
- 同一台 Nginx 服务器上，其他域名访问正常，唯独这个域名出问题
- 服务端抓包（tcpdump）能看到 Client Hello，也能发出 Server Hello 和证书，但客户端收到的证书却是别的域名的——说明流量根本没到你的 Nginx
临时验证与长期规避
快速验证是否 DNS 导致：
- 在 curl 中强制指定 IP：curl -k --resolve yourdomain.com:443:你的真实服务器IP https://yourdomain.com，如果能拿到正确证书并返回 200，就坐实是 DNS 层问题
- 手机切换蜂窝网络再访问，或使用 DNSCloak、AdGuard DNS 等干净 DNS 工具测试
生产环境建议：
- 启用 HTTPS 的 DNS over HTTPS（DoH） 或 DNS over TLS（DoT） 客户端配置
- 在 Nginx 上开启 HTTP Strict Transport Security（HSTS），减少明文 HTTP 重定向被劫持的风险
- 对关键域名，考虑使用 CAA 记录 限制可签发证书的 CA，降低钓鱼站点伪造可信证书的可能性
