“浏览器能打开”并不能证明 HTTPS 全部正确
HTTPS 问题最麻烦的地方，是它经常只在某些客户端、某些域名或某条网络路径上出现。Chrome 可能显示正常，但命令行工具、爬虫或 IPv6 请求却得到证书名称不匹配、连接失败或错误的虚拟主机。
最有效的排查方式不是不断修改配置，而是把问题拆成 DNS、连接路径、HTTP 响应、TLS 证书和虚拟主机绑定几个层次，一层一层确认。
1. 先确认 DNS 到底解析到哪里
同一个域名可能同时有 A 记录和 AAAA 记录。A 通常对应 IPv4，AAAA 对应 IPv6。如果两条记录指向不同设备，而只有其中一台服务器配置正确，就会出现“有时正常、有时失败”。
同时检查根域名与 www。如果使用通配符 DNS，仍然要确认实际解析结果，而不是只看控制面板里“看起来有配置”。
2. 分别测试 HTTP 与 HTTPS
如果 HTTP 返回 200，而 HTTPS 报证书错误，可以快速判断网站文件本身通常没有丢失，问题更可能在 TLS 层。
反过来，如果 HTTPS 能握手但返回 404，则应该继续检查虚拟主机、Web Station、Nginx location 或网站根目录，而不是把焦点放在证书上。
3. 强制 IPv4 与 IPv6 分开测试
在双栈环境中，分别测试 IPv4 和 IPv6 很重要。若 IPv4 正常、IPv6 失败，优先检查 AAAA 记录、路由器 IPv6 转发、防火墙和服务监听。若两边都出现同一个证书名称错误，则更可能是服务器端证书绑定问题。
4. 证书存在，不代表正在使用正确证书
服务器里可能同时存在多个证书，例如根域名证书、NAS DDNS 证书、QuickConnect 证书和其他服务证书。真正决定客户端看到哪一张证书的，是当前端口、SNI、虚拟主机和“系统默认 / 服务映射”的组合。
一个很典型的情况是：服务器已经有正确的 example.com 证书，但 443 默认仍指向另一张证书。浏览器访问根域名时就可能拿到错误证书。
5. 通配符 DNS 与通配符证书是两回事
*.example.com 的 DNS 记录表示很多子域名可以解析到同一个 IP；它不会自动生成 TLS 证书。反过来，*.example.com 的证书通常覆盖一级子域名，但不一定自动覆盖根域名 example.com。
如果希望根域名和全部一级子域名共用证书，申请时通常需要同时包含：
example.com *.example.com
6. 用“忽略证书验证”只做诊断，不做长期解决方案
如果正常 HTTPS 请求失败，但忽略证书验证后立即返回 200，这个结果非常有价值：它说明网页服务和目标文件大概率可用，真正的问题在证书验证。
7. 一个稳定的排查顺序
- 检查根域名和 www 的 DNS。
- 确认 A 与 AAAA 记录。
- 测试 HTTP 状态码。
- 测试 HTTPS 状态码与证书。
- 强制 IPv4 与 IPv6 分别测试。
- 检查服务器里的证书域名与有效期。
- 检查 Nginx / NAS 的默认证书与服务证书映射。
- 修改后重新测试，不要一次改五个地方。
8. 为什么这件事也会影响搜索与广告抓取
搜索引擎、广告系统和其他自动化客户端不会像人一样“点一下忽略证书警告”。如果 TLS 验证失败，它们可能直接停止请求。因此，稳定的 HTTPS 不只是浏览器地址栏有没有锁头，也是网站能否被外部系统可靠抓取的基础。
把 DNS、IPv4/IPv6、证书和虚拟主机都处理正确之后，后续很多“明明文件存在但平台说找不到”的问题都会少很多。