最直接有效的方式是在nginx https server块中添加add_header content-security-policy "upgrade-insecure-requests";，并配合80端口301跳转至https，确保混合内容自动升级且源头拦截http访问。
最直接有效的方式，是在 Nginx 的 HTTPS 服务配置中添加 Content-Security-Policy 响应头，启用 upgrade-insecure-requests 指令。浏览器收到该指令后，会自动将页面内所有 http:// 资源请求升级为 https://，无需修改前端代码。
只需一行配置就能生效
在你的 Nginx HTTPS server 块中（listen 443 ssl），加入这一行：
add_header Content-Security-Policy "upgrade-insecure-requests";
注意：该指令只对当前 HTTPS 响应生效，且仅影响该页面发起的子资源请求（如图片、脚本、API 等），不会修改页面中的超链接（<a href="http://..."></a>）或跳转行为。
常见位置示例：
- 放在
location / { ... }块内，确保静态资源响应也带上 - 避免与已有 CSP 头冲突；若已存在
add_header Content-Security-Policy，需合并指令，例如："upgrade-insecure-requests; default-src 'self'; img-src * data:; ..." - 不要在 HTTP server 块中加此头——它对 HTTP 页面无效，且可能干扰调试
配合强制跳转，堵住 HTTP 入口
仅加 CSP 不够彻底。用户仍可能通过 http:// 直接访问站点，导致后续资源加载仍走 HTTP。建议同步配置 301 强制跳转：
- 新增一个监听 80 端口的 server 块：
server { listen 80; server_name yourdomain.com; return 301 https://$host$request_uri; }- 这样所有 HTTP 请求都会被重定向到 HTTPS，从源头减少混合内容产生条件
遇到代理或 CDN 场景时的补充要点
如果你的站点经过 CDN 或反向代理（如前端请求实际打到内网 HTTP 服务），需额外注意：
- 确保代理层透传原始协议信息，即设置
proxy_set_header X-Forwarded-Proto $scheme; - 后端应用（如 PHP、Node.js）应依据
X-Forwarded-Proto判断是否为 HTTPS，避免生成http://链接 - 若必须代理内网 HTTP 服务（如私有 API），可采用 Nginx 代理转发方案：用 HTTPS 接入，再以 HTTP 转发至后端，并重写响应中的 URL 或使用
sub_filter替换 HTML 内的硬编码 HTTP 地址（慎用，仅作兜底）
验证是否生效
重启 Nginx 后，打开浏览器开发者工具 → Network 标签页 → 刷新页面 → 查看任意一个 HTML 响应的 Response Headers：
- 确认存在
Content-Security-Policy: upgrade-insecure-requests - 在 Console 中尝试手动执行
fetch('http://example.com/test')，应看到请求地址自动变为https://example.com/test（Chrome/Edge/Firefox 均支持） - 原来报 Mixed Content 的图片、脚本、AJAX 请求不再报错，控制台无红色警告
