答案是直接通过浏览器开发者工具的console和network面板定位混合内容问题：console中红色报错明确显示被拦截的http资源url，network中筛选mixed或blocked:mixed-content可查发起源及重定向问题，同时需检查nginx是否透传x-forwarded-proto及是否配置csp upgrade-insecure-requests响应头。
直接打开浏览器开发者工具的 Console 和 Network 面板，就能快速定位混合内容问题。Nginx 本身不报错，真正拦截发生在浏览器端，所以排查重点不在 Nginx 日志，而在前端加载行为。
看控制台红字报错
访问 HTTPS 页面后，按 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 XMLHttpRequest endpoint 'http://api.internal/v1/user'.
报错里直接写出被拦截的完整 URL，这就是你要修复的目标。
查 Network 中的“Mixed”请求
在 Network 面板顶部过滤栏输入 Mixed（Chrome/Edge 支持），或手动筛选状态码为 blocked:mixed-content 的请求。你还能看到这些请求原本的发起位置（Initiator 列），比如是哪个 JS 文件、哪行 HTML 的 <img src="http://...?x-oss-process=image/resize,p_40"> 触发的。
特别注意：如果页面里有重定向（如 302），且跳转目标是 http://，也会被标记为混合内容——这往往说明后端没识别到原始请求是 HTTPS，常见于 Nginx 未透传协议头。
确认 Nginx 是否正确传递了协议信息
混合内容常因后端服务生成了 HTTP 链接导致。关键检查点是 Nginx 是否把客户端真实协议告诉了后端：
- 确保反向代理配置中包含：
proxy_set_header X-Forwarded-Proto $scheme; - 如果后端是 Java（Tomcat）、PHP 或 Node.js，它需读取
X-Forwarded-Proto来判断当前应生成 HTTPS 链接，否则会默认拼出http://跳转地址或 API 基地址。 - 可在后端日志或调试中打印该 header 值，验证是否为
https。
检查响应头是否缺失 CSP 升级指令
即使资源链接仍是 http://，加一条响应头就能让浏览器自动改写请求。在 Nginx 的 HTTPS server 块中检查是否有：
若已存在其他 CSP 头，需合并而非覆盖，例如：
add_header Content-Security-Policy "upgrade-insecure-requests; default-src 'self';" always;注意：always 参数很重要，它确保 304、500 等非 200 响应也携带该头，避免部分页面漏掉升级逻辑。
