HTTPS 出错时，页面上常常只有“连接不安全”或“证书无效”这样的概括提示。真正的问题却可能发生在证书申请、服务器配置、DNS 解析乃至浏览器缓存中的任意一层。我的习惯不是立刻重新申请证书，而是先记录浏览器给出的错误代码，再用无痕窗口、另一台设备或命令行复现，确认它是稳定故障，而不是本机残留状态。
先看域名是否匹配，以及证书是否仍在有效期
我会先在浏览器的证书详情里确认当前收到的证书颁发给谁。访问 example.com 时，证书的 SAN（主题备用名称）中必须包含这个完整域名；仅有 www.example.com 的证书不能保护裸域名，通配符 *.example.com 通常也不包含 example.com 本身。若两个地址都需要使用，就应同时写入证书。
接着检查生效时间和到期时间，并确认服务器与客户端的系统时间正确。新证书已经签发但网站仍展示旧证书，往往说明证书文件没有真正加载，或者请求落到了另一台服务器，而不一定是续期程序本身失败。
再检查证书链是否完整
服务器通常不只需要站点证书，还要发送必要的中间证书，让浏览器能够一路验证到受信任的根证书。桌面浏览器偶尔会从缓存补齐中间证书，因此“我的电脑能打开、部分手机打不开”尤其值得检查证书链。
在 Nginx 中，ssl_certificate 一般应指向包含站点证书和中间证书的完整链文件，而不是只放一张站点证书。宝塔等面板通常会自动拼接，但手工替换内容时仍可能漏掉中间段。修改后先做配置语法检查，再平滑重载服务，并从外部网络重新验证服务器实际返回的证书链。
核对 DNS、80 与 443 端口最终到了哪里
证书本身看起来正确后，我会检查域名的 A、AAAA 或 CNAME 记录。常见情况是 IPv4 已指向新服务器，IPv6 仍指向旧机器；不同网络因此访问到不同证书。若使用 CDN、反向代理或负载均衡，也要分别确认边缘节点和源站的 HTTPS 配置，不要只检查源站面板。
随后确认防火墙、安全组和服务器监听状态。80 端口通常负责 HTTP 访问、跳转以及部分证书签发验证，443 端口才承载 HTTPS。二者不要混为一谈：80 可访问不代表 443 已开放，443 已开放也不代表流量进入了预期的 Nginx 虚拟主机。端口转发、容器映射或旧代理规则同样可能把请求送错位置。
确认 SNI 选中了正确站点
一台服务器托管多个 HTTPS 网站时，客户端会通过 SNI 告诉服务器自己要访问的域名，Nginx 再选择对应的 server 配置。如果域名没有匹配到正确的 server_name，或者多个配置发生冲突，服务器可能返回默认站点的证书，于是出现“证书有效但域名不匹配”。
因此我会同时检查 443 监听、server_name、证书路径及默认虚拟主机，并用域名发起测试，而不是直接用 IP 地址判断证书是否正确。直接访问 IP 时，证书通常不会包含该 IP，也可能无法触发预期的 SNI 选择，测试结果容易误导。
最后处理缓存、跳转与强制 HTTPS
完成服务端修改后，我会先用命令行或无痕窗口查看最新结果，再处理浏览器缓存、DNS 缓存、CDN 缓存和可能存在的代理缓存。若刚修改过 DNS，还需要考虑各级缓存的 TTL；反复清空本机缓存无法让尚未过期的公共 DNS 记录立即更新。
强制 HTTPS 应放在最后开启。比较稳妥的顺序是：先让域名解析到正确服务器，确认 80 和 443 可达；再安装与域名匹配、有效期正常且链完整的证书；验证 SNI 返回正确证书后，才配置 HTTP 到 HTTPS 的 301 跳转。如果过早开启全站跳转或 HSTS，错误配置会被浏览器长期记住，也可能干扰证书验证和排障。
对我来说，这套顺序的核心是始终确认“客户端此刻连接的是谁、对方实际返回了什么”。从域名和有效期开始，依次排查证书链、DNS、端口、SNI，最后再看缓存与强制跳转，通常比反复续签和重启服务更快找到根因。