网站明明装了SSL证书，浏览器却提示不安全？

前两天在整理 WordPress 网站时，又碰到了一个挺烦人的问题。

网站明明已经安装了 SSL 证书，地址栏也能正常使用 HTTPS，结果浏览器还是提示连接不安全。有时候电脑端访问完全正常，换个浏览器或者手机打开，警告又出现了。

第一次遇到这种情况，很容易怀疑证书是不是安装错了，然后重新申请、重新部署，折腾一圈发现问题还在。

其实 网站能通过 HTTPS 打开，不代表整个页面的所有资源都已经通过 HTTPS 加载。

浏览器提示不安全，除了证书本身的问题，还可能和网页里的图片、JavaScript、CSS、证书链以及 WordPress 地址配置有关。

我现在处理这类问题，基本会从下面几个地方开始检查。

一、先看证书是不是真的正常

排查之前，先别急着动 WordPress。

直接在浏览器打开网站，点击地址栏左侧的网站信息或连接状态图标，查看 HTTPS 连接和证书详情。不同浏览器的入口位置会有区别。

主要确认三件事。

• 证书是否已经过期
• 证书包含的域名是否与当前访问域名一致
• 浏览器能否建立可信的证书链

这里特别容易被忽略的是带 www 和不带 www 的区别。

比如证书只覆盖了 example.com，但用户实际访问的是 www.example.com，浏览器就可能提示证书名称不匹配。

反过来也一样。

申请证书时，需要确认实际使用的域名都在证书覆盖范围内。

如果网站使用了 CDN，还要检查 CDN 边缘证书，而不只是服务器上的源站证书。用户浏览器首先连接的是 CDN，源站证书正确并不能保证浏览器看到的证书一定正确。

二、证书没问题，再查是不是混合内容

这个问题在 WordPress 网站里特别常见。

所谓混合内容（Mixed Content），简单理解就是网页本身通过 HTTPS 打开，但页面内部仍然引用了 HTTP 资源。

例如网站地址已经变成

https://example.com

网页里却还保留着这样的图片地址。

http://example.com/uploads/logo.png

浏览器加载页面时，就会发现安全连接中夹杂了不安全资源。

部分 HTTP 请求会被浏览器自动升级为 HTTPS，部分资源则可能遭到阻止。具体表现取决于资源类型和浏览器策略。

对于站长来说，最直观的现象就是图片不显示、样式加载异常，或者开发者工具中出现 Mixed Content 警告。

遇到 HTTPS 异常，我现在会优先打开浏览器开发者工具，而不是反复重新安装证书。

在 Chrome 或 Edge 中按下 F12，切换到 Console 面板。

页面存在混合内容时，控制台可能出现类似提示。

Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.

看到这条信息，就说明应该去找页面里的 HTTP 资源，而不是继续怀疑证书签发。

三、WordPress 最容易漏掉网站地址配置

WordPress 从 HTTP 切换到 HTTPS 后，有两个设置非常重要。

进入后台的「设置 → 常规」，找到 WordPress 地址和站点地址。

这两项应当根据网站实际部署方式填写正确的 HTTPS 地址。

例如

https://example.com

很多网站虽然已经部署证书，但这里仍然保留着原来的 http:// 地址。

结果前台部分链接、图片地址或者跳转依然使用 HTTP。

修改完成后，记得清理 WordPress 缓存、页面缓存和 CDN 缓存，再重新检查网站。

不过这里有个坑需要提醒一下。

不要在没确认服务器 HTTPS 配置和访问链路正常之前，直接修改 WordPress 地址。

尤其网站前面还有 CDN、反向代理或者负载均衡时，HTTPS 终止位置和后端请求协议可能不同。

地址改错以后，轻则出现循环跳转，严重时可能连 WordPress 后台都进不去。

四、数据库里可能还留着以前的 HTTP 链接

WordPress 网站迁移过域名，或者后来才启用 HTTPS，很容易出现这个问题。

站点地址已经改成 HTTPS，文章里的图片却还是原来的 HTTP 地址。

因为 WordPress 数据库保存的不只有网站地址，还包括文章内容、页面构建器设置、图片链接、菜单配置以及部分插件数据。

光修改后台的两个网站地址，并不能自动把历史内容全部替换掉。

这时候可以借助支持 WordPress 数据库序列化数据处理的搜索替换工具，例如 WP-CLI 的 search-replace。

使用前先完整备份数据库。

然后根据网站实际路径和域名，执行类似下面的命令。

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

这里的 --dry-run 很重要。

它只预览将会发生哪些替换，不会直接修改数据库。

确认匹配结果符合预期以后，再移除 --dry-run 正式执行。

另外，不建议直接用普通 SQL 全局替换 WordPress 数据库。部分插件和主题会使用序列化数据保存配置，直接替换可能破坏其中的数据结构。

先备份、再预览、最后正式替换，比修复出问题的数据库轻松得多。

五、启用了 HTTPS，却一直循环跳转

有些站点的问题更明显。

访问网站以后，浏览器直接提示重定向次数过多，页面根本打不开。

这种情况经常发生在 WordPress、Nginx 和 CDN 同时参与 HTTPS 跳转的时候。

例如 CDN 已经把 HTTP 自动跳转到 HTTPS，源站也设置了跳转规则，而后端应用又因为没有正确识别原始访问协议，再次要求跳转。

几个地方反复处理，就可能形成循环。

我一般先使用下面的命令查看响应头。

curl -I https://example.com

需要观察完整的跳转过程，可以执行

curl -IL --max-redirs 10 https://example.com

这里重点检查返回的 HTTP 状态码和 Location 地址。

发现同一个地址来回跳转，就应该检查 CDN、Nginx 和 WordPress 的 HTTPS 配置，而不是继续申请新证书。

HTTPS 跳转规则不是配置得越多越好，关键是整条访问链路保持一致。

特别是反向代理部署的 WordPress，后端能不能正确识别用户原始请求使用的是 HTTPS，非常重要。

六、证书正常，电脑能打开，手机却提示不安全

这种情况也值得单独说一下。

首先要区分是不是所有手机都存在问题。

只有某个浏览器异常，可能与浏览器版本、缓存或者设备信任的根证书有关。

多个设备都提示证书不可信，则应该进一步检查服务器是否正确提供了完整证书链。

Nginx 用户可以检查 HTTPS 虚拟主机配置，确认 ssl_certificate 指向的是包含所需中间证书的完整证书链文件，而不是只有站点证书的文件。

修改 Nginx 配置后，先执行

nginx -t

确认配置没有语法错误，再重新加载服务。

systemctl reload nginx

还有一种比较隐蔽的问题，就是网站已经续签证书，但 Nginx 没有重新加载，仍然在使用旧证书。

这时后台明明显示证书续签成功，浏览器却依然提示过期。

证书文件更新了，不代表正在运行的 Web 服务已经加载了新证书。

七、我现在会把 HTTPS 排查分成三个层次

以前遇到浏览器提示不安全，我也喜欢从证书开始折腾。

现在发现，先判断问题属于哪一层，效率反而更高。

证书层有问题，就检查证书部署和信任链。

页面资源有问题，就打开浏览器 Console 找到具体的 HTTP 请求。

网站配置有问题，再去检查跳转规则、WordPress 地址和反向代理设置。

三个方向分开处理，比从头到尾反复修改证书配置更容易找到原因。

八、修复完成以后，别忘了重新检查

HTTPS 问题处理完以后，我一般不会只打开首页看一眼就结束。

至少还会测试文章页面、图片较多的页面、WordPress 后台和移动端访问。

有 CDN 的网站，记得清理相关缓存，否则旧的 HTML 页面或者资源链接可能还会被继续返回给访客。

浏览器开发者工具也值得再打开一次，确认 Console 里面没有新的混合内容警告。

最后可以检查 HTTP 到 HTTPS 的跳转是否符合预期，避免出现两个地址都能访问、页面内容却完全相同的情况。

HTTPS 不只是给网站安装一张证书，还要保证页面资源、访问地址和服务器配置都能正确配合。

网站明明装了 SSL 证书，浏览器却提示不安全，未必是证书本身出了问题。

有时候只是 WordPress 数据库里的旧图片地址没改，有时候是 CDN 回源配置不一致，也可能是证书链没有部署完整。

找到具体原因以后，很多问题其实不用花太长时间。

比起不断重新申请证书，我现在更习惯先打开浏览器开发者工具，看清楚它究竟在抱怨什么。