混合内容问题需通过浏览器开发者工具定位，重点检查console红字报错和network中blocked:mixed-content请求，修复http资源为https协议，并配置nginx透传x-forwarded-proto、添加upgrade-insecure-requests响应头及80端口301跳转。
直接打开浏览器开发者工具（F12），切到 Console 和 Network 面板，就能定位混合内容问题。Nginx 本身不报错，拦截由浏览器发起，所以排查重点不是 Nginx 日志，而是前端资源实际加载的协议是否安全。
看控制台红字报错
Console 中所有被拦截的 HTTP 资源都会以红色文字明确提示，例如：
- Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script 'http://cdn.example.com/app.js'
- Mixed Content: The page at 'https://example.com/login' was loaded over HTTPS, but requested an insecure image 'http://example.com/uploads/logo.png'
报错里直接写出被拦截的完整 URL，这就是你要修复的目标——不是改 Nginx 配置，而是让这个地址变成 https:// 或协议相对地址（//），但更推荐显式写 https://。
查 Network 中的混合请求
在 Network 面板顶部过滤栏输入 Mixed（Chrome/Edge 支持），或手动筛选状态为 blocked:mixed-content 的请求。重点关注：
-
Protocol 列是否显示
http（应为https或h2） - Initiator 列指出是哪个 HTML 标签、哪行 JS 或 CSS 触发了该请求
- 若某请求显示
302跳转且目标是http://，说明后端未识别原始 HTTPS 协议，常见于 Nginx 未透传X-Forwarded-Proto
检查 Nginx 是否透传协议头
如果后端服务（如 PHP、Node.js、Java）生成了 http:// 链接，大概率是因为它没收到客户端真实协议。确认反向代理配置中包含：
proxy_set_header X-Forwarded-Proto $scheme;- 后端需读取该 header 并据此拼接资源 URL 或跳转地址
- 可临时在后端打印该 header 值，验证是否为
https
加响应头自动升级协议
在 Nginx 的 HTTPS server 块中添加以下响应头：
add_header Content-Security-Policy "upgrade-insecure-requests; default-src 'self'; img-src 'self' data: https:; script-src 'self' https:; style-src 'self' https:; font-src 'self' https:;" always;-
always参数确保 304、200 等所有响应都带上该头，避免缓存导致缺失 - 若已存在 CSP 头，需合并而非覆盖，不能简单重复
add_header
该指令会让浏览器自动把页面内所有 http:// 子资源请求升级为 https://，对图片、脚本、样式等均生效。
配合强制跳转堵住 HTTP 入口
仅加 CSP 不够彻底。用户仍可能通过 http:// 直接访问站点，导致后续资源加载仍走 HTTP。建议同步配置 301 强制跳转：
- 新增一个监听 80 端口的
server块： server { listen 80; server_name yourdomain.com; return 301 https://$host$request_uri; }
这样所有 HTTP 请求都会被重定向到 HTTPS，从源头减少混合内容产生条件。
