HTTPS 页面仍报不安全？混合内容与资源地址排查
HTTPS 页面并不一定只请求 HTTPS 资源。旧模板、历史文章、接口配置或第三方脚本，都可能继续生成 HTTP 地址，导致部分功能被浏览器升级或拦截。本文适用于当前受维护的 Chrome、Firefox 等浏览器，以及已经正确配置证书的网站。
从报错资源反查引用位置
打开浏览器开发者工具，保留控制台与网络记录，重新加载出现问题的页面。找到具体资源地址、请求类型和发起位置，区分脚本、样式、图片、接口及下载。只看到“不安全”提示时，先确认它是否真是混合内容，而不是证书过期、域名不匹配或用户上传文件的下载警告。
现代浏览器对不同资源采取的策略不完全相同，部分资源可能自动尝试 HTTPS，另一些会被阻止。图片偶尔能显示，不能证明地址设置已经正确；应以请求记录与控制台为准。MDN 混合内容说明
修正生成地址的源头
如果问题来自模板中的固定链接，把它改为经过验证的 HTTPS 地址或符合应用路由的相对地址，再检查构建输出。不要只修改浏览器看到的一份生成文件，因为下一次部署可能再次生成旧地址。
历史内容中保存了完整资源链接时，先备份并抽样定位字段，使用应用支持的迁移或替换工具。数据库可能包含序列化内容、转义字符和非网页用途地址，不能对整个数据库盲目替换所有 http://。先在测试副本验证数量和内容，再处理生产数据。
修改资源协议之前，确认对应主机确实提供可信 HTTPS，路径和内容也一致。一个只支持 HTTP 的第三方资源，不能靠改字符串变成安全资源，应联系提供方、换成维护中的来源，或在授权条件下改为自有托管。
反向代理后的应用要识别正确协议
如果用户通过 HTTPS 访问，代理到本机应用却使用 HTTP，应用可能误以为外部也是 HTTP，从而生成错误链接。检查代理传递的协议信息，以及应用是否只信任真实代理节点，不能让任意公网请求头决定它的安全状态。
同时核对应用的站点基础地址、资源域名、上传地址和 WebSocket 地址。需要安全 WebSocket 的功能，应使用正确的 wss 入口。修改协议识别后，检查登录跳转和回调地址，避免修复图片却引入无限重定向。
多层 CDN 或负载均衡环境中，外部协议与某一内部连接协议不同并不罕见。应沿请求链确认由哪一层声明原始协议，记录信任范围，再让应用读取符合其官方部署方式的信息。
内容安全策略可辅助，不能代替修复
内容安全策略可以约束资源来源，并在合适场景辅助升级不安全请求，但它无法让不支持 HTTPS 的主机突然提供有效证书。部署新策略前先评估第三方资源与业务功能，不要用一条严格规则直接替换所有现有策略。
如果网站已经有策略导致资源被阻止，应分清是混合内容还是来源限制，两个问题需要不同处理。不要建议访客关闭浏览器安全设置；这会掩盖故障，并把风险交给用户。诊断视图的使用可以参考Chrome DevTools 安全文档。
在完整页面流程中验证修复
清理或更新自己控制的构建缓存、应用缓存和 CDN 对象，再用正常浏览器缓存状态访问。首页通过后，还要检查历史文章、登录页面、懒加载图片、搜索结果和上传后的资源，因为它们可能走不同模板与地址生成逻辑。
保留修改前版本、替换清单和测试样本。若新资源地址导致功能异常，回退相关发布或数据变更，暂时停用有问题的第三方组件；不应把整个网站退回 HTTP。验收标准是资源内容正确、协议正确、浏览器不再报告相同问题，并且没有出现新的跳转或权限异常。