全站开启https后第三方外链加载失败本质是混合内容被浏览器拦截，需将http外链升级为https或确保其支持https；可通过手动验证、csp头upgrade-insecure-requests、前端相对协议等方案解决。
全站开启 HTTPS 后，第三方外链资源加载失败，本质是混合内容（Mixed Content）被浏览器拦截，而非 Nginx 本身拒绝请求。关键不在“阻止”，而在“升级”或“适配”——让 HTTP 外链自动转为 HTTPS，或确保其本身支持 HTTPS。
确认第三方资源是否真正支持 HTTPS
不是所有 HTTP 外链都能直接升级。先手动访问其 HTTPS 地址，例如将 http://cdn.example.com/logo.png 改为 https://cdn.example.com/logo.png，看是否返回 200 和正确资源。常见情况包括：
- 部分老 CDN 或小服务商未配置 HTTPS，访问会超时或返回 404/503；
- 某些资源域名不支持通配符证书（如
https://static.xxx.net无有效证书）； - 资源 URL 含动态参数（如
?v=1.0），HTTPS 下可能因后端逻辑差异返回异常。
若确认不支持 HTTPS，需联系对方启用，或替换为已支持 HTTPS 的替代源（如用 jsDelivr 加速开源库、Cloudflare CDN 中转等）。
用 CSP 响应头自动升级不安全请求
Nginx 可在 HTTPS server 块中添加响应头，让浏览器主动把页面中所有 http:// 资源请求升级为 https://：
add_header Content-Security-Policy "upgrade-insecure-requests; img-src 'self' data: https:; script-src 'self' https:; style-src 'self' https:; font-src 'self' https:;" always;
注意：
- 该策略仅对同域及明确列入
img-src/script-src等指令的第三方域名生效； - 若第三方域名未出现在对应指令中（如
script-src 'self'但资源来自https://bad-cdn.com/app.js），仍会被拦截； - 务必加
always参数，否则 304 响应可能不携带该头。
前端代码层做兼容性兜底
响应头是辅助手段，根本解法仍是前端控制资源协议。推荐方式：
- 静态资源尽量用相对协议写法：
//cdn.example.com/lib.js，浏览器会自动继承当前页面协议； - 动态生成的外链（如后台返回的图片地址），在 JS 中统一处理：
url.replace(/^http:/, 'https:')； - 构建工具（Webpack/Vite）中通过环境变量注入基础 URL，避免硬编码
http://； - 模板引擎（如 Jinja2、EJS）中使用
{{ request.scheme }}或动态拼接。
验证与清理缓存
修改后需彻底验证，避免旧响应头或资源路径被缓存：
- 清除浏览器缓存（含 Service Worker），或使用隐身窗口测试；
- 在 Chrome DevTools 的 Network 面板中查看具体资源请求的 Protocol 列，确认是否为
https； - 检查 Console 是否仍有
Mixed Content报错，定位残留的 HTTP 请求来源（可能是 CSS 中的background:url(http://...)或内联 SVG）； - 若使用 CDN 或 WAF，确认其未缓存旧版 HTML 或响应头，需主动刷新缓存。
