答案是直接通过浏览器开发者工具的console和network面板定位混合内容问题：console中红色报错明确显示被拦截的http资源url，network中筛选mixed或blocked:mixed-content可查发起源及重定向问题，同时需检查nginx是否透传x-forwarded-proto及是否配置csp upgrade-insecure-requests响应头。
直接打开浏览器开发者工具的 Console 和 Network 面板，就能快速定位问题。Nginx 本身不报混合内容错误，拦截行为由浏览器发起，所以排查重点不在 Nginx 日志，而在前端资源的实际加载协议。
看控制台红字报错
按 F12 打开开发者工具 → 切换到 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:// 或协议相对地址。
查 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
验证响应头与资源路径
点击任意 HTML 请求 → 查看 Response Headers → 确认是否含：
-
Content-Security-Policy: upgrade-insecure-requests;（启用后浏览器会自动把 http:// 升级为 https://） - 若已存在 CSP 头，需合并而非覆盖，例如：
upgrade-insecure-requests; default-src 'self'; img-src 'self' https: data:; - 同时检查资源 URL 是否真能访问：在新标签页直接打开
https://yourdomain.com/static/app.css，观察是否返回 200、403 还是 404——403/404 是权限或 location 匹配问题，和混合内容无关但常被混淆
