HTTPS页面加载HTTP资源被浏览器拦截，属混合内容（Mixed Content）问题：主动型（JS/CSS/API）被直接阻止，被动型（图片等）可能仅降级；需通过Console/Network定位http://请求，替换为https://或环境变量驱动URL，后端模板应判isSecure，第三方资源须确认HTTPS支持。
这不是 HTTPS 配置出错，而是浏览器主动拦截了混合内容（Mixed Content）——页面走 HTTPS，但资源地址写的是 HTTP。排查关键在于定位哪些资源被降级、为什么没自动升级、以及如何从源头修复。
看浏览器控制台报什么错
打开开发者工具（F12）→ Console 或 Security 标签页，找明确含 Mixed Content 的警告，例如：
The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.com/app.js'.Blocked loading mixed active content 'http://api.example.com/data.json'
注意区分：active content（如 JS、CSS、AJAX）会被直接阻止；passive content（如图片、音频）可能仅降级显示或警告。前者导致功能异常，后者影响体验。
查资源链接实际用的协议
切到 Network 标签页 → 刷新页面 → 找到报错的请求 → 看 Protocol 列：
- 如果是 http/1.1 或 http/2，说明 HTML/JS 中硬编码了
http://； - 如果是 https/1.1 但仍报 CORS，那问题不在混合内容，而是响应头缺失（另需排查 Access-Control-Allow-Origin）；
- 若 URL 是
//cdn.example.com/xxx.js（协议相对地址），但最终发起的是 HTTP 请求，说明当前页面加载环境异常（比如本地 file:// 打开，或代理中间件改写了协议）。
检查资源来源是否可控
分三类情况处理：
-
前端代码中写死的 HTTP 地址：搜索项目里所有
http://，替换成https://或环境变量驱动的 baseURL（如 Vite 的import.meta.env.VITE_API_BASE）； -
后端模板渲染的链接：检查服务端逻辑，确保生成的
<script src="..."></script>使用request.isSecure()或类似判断来拼协议； - 第三方 SDK 或 CDN 脚本：确认其官方文档是否提供 HTTPS 入口；若只提供 HTTP，应联系供应商或换用支持 HTTPS 的替代方案。
临时兜底：用 Nginx sub_filter 强制替换
当无法修改源码（如老旧 CMS、闭源系统），可在 Nginx 的 server 块中启用 sub_filter：
- 开启模块：
sub_filter 'http://' 'https://'; - 限定作用范围：
sub_filter_once off;（默认只替换第一个） - 确保响应类型匹配：
sub_filter_types text/html application/javascript text/css; - 注意：该方式不处理内联 JS 中动态拼接的 URL，且对二进制资源（如图片）无效。
验证是否还有残留 HTTP 请求
清除浏览器缓存 + 使用无痕窗口重新访问；也可用 curl 模拟：
-
curl -sI https://yourdomain.com | grep -i location查 301/302 是否跳转到 HTTP（说明 Nginx 有错误 rewrite）； -
curl -s https://yourdomain.com | grep -o 'http://[^"]*'快速扫描 HTML 中是否还存在 http:// 链接。
