https页面加载失败多因mixed content：主页面https，但引用的图片、js、css或api仍为http://，浏览器直接拦截；需通过console报错、network筛选http://、检查html/css/js硬编码及富文本等定位并修复。
HTTPS 页面加载失败，十有八九是混合内容（Mixed Content）在作怪——主页面走 HTTPS，但里面引用的图片、JS、CSS 或 API 接口却还是 http://，浏览器直接拦截，控制台报红，页面白屏或功能异常。排查不难，关键要分层定位、逐项验证。
看浏览器控制台有没有 Mixed Content 报错
这是最直接的入口：
- 打开 Chrome 或 Edge，按 F12 进入开发者工具 → 切到 Console 标签页，刷新页面，找带 “Mixed Content” 字样的红色错误，例如：
“The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.com/app.js'” - 也可以切到 Security 标签页，点 “View blocked content”，浏览器会列出所有被拦截的 HTTP 资源及其类型（script、img、fetch 等）
- 注意区分：主动型（script、XHR、fetch）会被严格阻止；被动型（img、video）可能只警告或降级显示，但新版浏览器也倾向默认拦截
查 HTML 和静态资源里有没有硬编码的 http://
前端代码或模板中写死的协议地址，是根源所在：
- 搜索项目中所有
<script src="http://%E3%80%81<link%20href=" http:>、<code><img src="http://</script>、<iframe src="?x-oss-process=image/resize,p_40%22http://</code"> 等标签</iframe> - 检查 CSS 文件里的
background-image: url(http://...)、@import "http://..." - 查看 JS 中的 API 请求地址，比如
fetch('http://api.example.com/login')或 Axios 默认 baseURL 设为http:// - 别漏掉数据库字段——用户上传的富文本、文章封面图、广告位链接等，也可能存了 http:// 开头的 URL
用 Nginx 响应头自动升级不安全请求
如果代码量大、上线急、或第三方资源无法改源，可在 Nginx 层加一层兜底防护：
- 在对应 server 块中添加响应头：
add_header Content-Security-Policy "upgrade-insecure-requests; script-src 'self' https:; img-src 'self' data: https:;" always; - 这个指令会让浏览器在发起网络请求前，自动把页面内所有
http://xxx替换为https://xxx，对主动/被动混合内容都生效 - 搭配
proxy_set_header X-Forwarded-Proto $scheme;，确保后端也能识别原始协议，避免它自己又跳回 HTTP
验证 Nginx 是否正确透传 HTTPS 协议信息
反向代理场景下，后端服务若没意识到前端是 HTTPS，可能生成 HTTP 链接或重定向，间接导致混合内容：
- 确认 Nginx 配置中已设置：
proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Host $host; - 检查后端返回的 302 重定向 Location 头是否仍是 http://，如有，需加：
proxy_redirect http:// https://; - 若后端依赖协议判断生成资源路径（如 Laravel 的
asset()、Django 的static()），必须确保它读取的是X-Forwarded-Proto而非原始请求协议
