最轻量通用的解决方式是在nginx https server块中添加add_header content-security-policy "upgrade-insecure-requests" always;，浏览器会自动将页面内所有http://请求升级为https://发出，无需改前端或依赖后端https支持。
直接在 Nginx 的 HTTPS server 块中添加 Content-Security-Policy: upgrade-insecure-requests 响应头，是最轻量、最通用的解决方式。它不依赖后端是否支持 HTTPS，也不用改前端代码，浏览器收到后会自动把页面里所有 http:// 请求升级为 https:// 发出。
用 CSP 头让浏览器自动升级请求
这是首选方案，适用于绝大多数静态资源或 API 地址写死为 HTTP 的场景。只要前端页面本身是 HTTPS 加载的，加上这行配置，浏览器就会在发起请求前把 http://api.example.com/login 自动转成 https://api.example.com/login（前提是目标域名实际能响应 HTTPS）。
- 在 Nginx 的
server { listen 443 ssl; ... }配置块内，添加：
add_header Content-Security-Policy "upgrade-insecure-requests" always;
-
always参数确保即使返回 304 或错误状态码也带上该头，避免遗漏 - 注意：该策略只对同源或允许跨域的资源生效；若目标 HTTP 接口跨域且未配 CORS，升级后仍可能因跨域被拦，需额外处理
用反向代理把 HTTP 后端“伪装”成 HTTPS
当后端服务确实无法启用 HTTPS（如内网 Spring Boot 应用、老旧设备接口），又必须保持前端调用路径不变时，Nginx 可以作为 SSL 终结点，对外提供 HTTPS 接口，对内仍用 HTTP 通信。
- 例如前端请求
https://your.com/api/user，Nginx 收到后转发给http://127.0.0.1:8080/api/user - 关键配置包括：
proxy_pass http://backend;、proxy_set_header X-Forwarded-Proto $scheme;（让后端知道原始是 HTTPS）、proxy_ssl_verify off;（不用验证后端证书） - 务必在 location 中显式设置
proxy_set_header Host $host;，避免后端因 Host 不匹配返回 404
配合 meta 标签做前端兜底
如果 Nginx 无法修改（如托管在某些 PaaS 平台），可在 HTML 的 中加入 meta 指令，效果与 CSP 响应头一致：
- 注意：meta 方式仅对当前 HTML 文档生效，无法作用于通过 JavaScript 动态插入的 iframe 或 worker
- 不推荐单独使用，建议与 Nginx 响应头配合，形成双重保障
排查与验证要点
配置生效后，不要只看页面是否“看起来正常”，要确认根本问题已解：
- 打开 Chrome 开发者工具 → Network 标签页 → 刷新页面 → 筛选 XHR 或 JS，检查所有请求 URL 是否已变为
https:// - 查看 Response Headers，确认存在
Content-Security-Policy: upgrade-insecure-requests - 若仍有报错，检查是否漏了某个第三方资源（如统计脚本、CDN 图片），它们的 HTTP 地址同样会被拦截
- 手机 Safari 对混合内容更敏感，务必在 iOS 设备上实测
