企业网站完成 HTTPS 配置以后，有时地址栏已经能够通过加密连接访问，但浏览器控制台仍然出现安全提示，某些图片、字体或者脚本甚至无法正常加载。
这类问题经常与 Mixed Content，也就是“混合内容”有关。
简单理解就是：当前 HTML 页面通过 HTTPS 打开，但页面内部仍然请求 HTTP 资源。
例如页面本身处于加密连接中，却又加载了一个未加密的 JavaScript 文件。浏览器为了避免安全风险，可能直接阻止该资源。
所以网站建设中的 HTTPS 检查不能只看首页地址有没有变成 HTTPS，还需要继续检查页面内部所有资源请求。
一、示例环境
下面以常见环境说明：
Linux
Nginx 1.24.x
HTTPS 已正常部署
Chrome 或 Edge
企业网站前端页面
图片、CSS、JavaScript、字体和接口请求
这里重点讨论 HTTPS 已经可访问，但页面仍出现混合内容提示的情况。
如果证书本身无效、过期或域名不匹配，需要先处理证书问题，两类故障不要混在一起排查。
二、先从浏览器 Console 看报错
打开存在问题的页面后，按 F12 打开开发者工具。
进入：
Console
如果存在混合内容，通常会看到类似提示：
Mixed Content
并指出具体是哪一个资源仍然使用 HTTP。
常见对象包括：
图片
CSS
JavaScript
字体
iframe
接口请求
视频资源
这一步的目的不是马上修改，而是先把所有异常请求找出来。
如果页面有多个资源存在问题，可以先记录资源类型和来源位置，再逐项处理。
三、再用Network确认资源协议
进入：
Network
重新加载页面。
可以检查异常资源的 Request URL 或请求信息，确认它实际使用的是：
http
还是：
https
有些资源在 HTML 源码中并不明显，例如 CSS 背景图片、JavaScript 动态生成地址或者接口返回的图片路径，所以只搜索 HTML 往往找不全。
Network 面板更接近浏览器真实请求结果。
四、检查模板中写死的HTTP地址
较早的网站代码中常见直接写死资源协议，例如：
或者：
升级 HTTPS 后，这些资源不会自动全部变成 HTTPS。
如果资源属于当前站点，可以优先改为站内相对路径，例如：
这样浏览器会自动沿用当前页面的协议。
如果资源来自第三方，需要先确认对方是否支持 HTTPS，再决定是否替换。
不要简单把所有 http 字符串批量改成 https，因为目标服务器未必支持加密连接。
五、CSS里的资源也容易被漏掉
有些混合内容并不在 HTML，而藏在 CSS 中。
例如：
.hero {
background-image: url("http://...");
}
网页主体已经切换到 HTTPS，但背景图仍通过 HTTP 请求。
字体也可能存在类似问题：
@font-face {
font-family: "WebFont";
src: url("http://...");
}
排查时应该同时搜索：
url(
@font-face
background-image
尤其是从旧网站迁移过来的 CSS 文件，比较容易保留以前的绝对资源地址。
六、接口地址也要检查
前端网站如果需要调用接口，还要检查 JavaScript 中的 API 地址。
例如：
const apiBase = "http://...";
HTTPS 页面调用 HTTP 接口，同样可能被浏览器限制。
更容易维护的方式，是把接口地址放到统一环境配置中，而不是散落在多个组件。
例如：
const apiBase = window.location.origin;
是否适合这样处理，要根据接口和网站是不是同源决定。
如果前端和接口属于不同服务，则需要使用独立的 HTTPS 接口地址，并同时检查 CORS 配置。
七、数据库中的旧内容也可能带HTTP
网站改版时还有一个比较隐蔽的位置：历史内容。
文章正文、产品介绍或者后台富文本中，可能已经保存了大量完整图片地址。
即使新模板已经全部改成 HTTPS，旧文章里仍然可能存在：
这种情况下，需要检查数据库中的正文内容，而不是继续修改前端模板。
处理前建议先备份数据，再根据实际内容批量替换。
批量操作后还要抽查不同文章，避免误改普通文本。
八、Nginx强制跳转不能代替页面内部整改
HTTPS 部署时通常会把 HTTP 请求重定向到 HTTPS。
典型思路类似：
server {
listen 80;
server_name ;
return 301 https://$host$request_uri;
}
这可以处理用户直接访问 HTTP 页面的问题。
但它不能说明所有页面内部资源都已经处理正确。
特别是外部资源不受当前服务器控制，即使主站有跳转规则，也无法替第三方服务器完成协议升级。
所以“80端口已经301”与“页面不存在混合内容”是两件不同的事情。
九、可以使用CSP辅助发现问题
如果项目已经使用 Content Security Policy，可以通过策略进一步限制不安全资源。
例如：
add_header Content-Security-Policy "upgrade-insecure-requests";
它会尝试把页面中的 HTTP 请求升级为 HTTPS。
但这个配置不应该用来掩盖所有旧地址问题。
如果某个资源本身不支持 HTTPS，自动升级以后仍然会加载失败。
因此，更合适的顺序是：
先通过 Console 和 Network 找出问题；
修改站内明确可以处理的 HTTP 地址；
确认外部依赖是否支持 HTTPS；
完成验证以后，再决定是否增加安全策略。
十、HSTS和混合内容不是同一个问题
HTTPS 网站还经常配置 HSTS。
HSTS 的作用主要是告诉浏览器后续访问该站点时应使用 HTTPS。
它并不会自动修复模板、CSS 或数据库里错误的资源地址。
所以即使 HSTS 已经生效，页面仍可能出现混合内容。
而且 HSTS 配置具有持续影响，上线前应确认 HTTPS 已经稳定，不建议在问题还没排查清楚时盲目设置较长有效期。
十一、修改以后怎么验证
处理完成后，可以重新打开开发者工具。
先清除旧页面缓存，再刷新。
检查 Console：
是否还有 Mixed Content
检查 Network：
页面资源是否都使用预期协议
是否存在被阻止请求
图片、字体和脚本是否返回正常
接口请求是否成功
然后继续抽查不同类型页面：
首页；
产品详情；
文章详情；
列表页；
表单页；
移动端页面。
不要只验证一个首页，因为历史内容和不同模板可能引用不同资源。
十二、为什么上线后还要持续检查
企业网站运行时间越长，新的编辑人员、第三方组件和历史内容都可能再次带入 HTTP 地址。
因此，HTTPS 检查不应该只是上线当天执行一次。
网站模板升级、富文本编辑器调整、外部组件更换以后，都可以重新看一遍浏览器 Console。
如果突然出现：
图片不显示；
字体无法加载；
接口请求失败；
控制台出现安全警告；
也可以先检查协议问题，再判断是不是其他前端故障。
网站建设中的 HTTPS 完成标准，不只是浏览器地址栏能够打开加密页面，还包括页面内部资源、接口和历史内容都能够在安全连接环境下稳定加载。
本文由梓彤超越（武汉）科技有限公司整理。
