https链接打开http资源

浏览器地址栏里那把小锁，接打有时候就是接打个摆设。你明明访问的接打是 https 开头的网站，页面里却嵌着 http 的接打图片、脚本，接打甚至 iframe。接打这种情况太常见了，接打尤其是接打那些老站点、内部系统，接打或者图省事没配 SSL 的接打小服务商。我上周就碰上一回：公司后台是接打 https，但有个报表模块引了 http 的接打 echarts，结果整个图表死活加载不出来，接打控制台红了一片——Mixed Content，接打混合内容，接打浏览器直接给拦了。

这不是 bug，是安全策略。https 页面里加载 http 资源，等于在防弹车里开个洞递纸条。攻击者能篡改 http 响应，往里面塞恶意脚本，你的 https 页面就跟着沦陷。所以 Chrome、Firefox 这些现代浏览器默认阻止“主动混合内容”——脚本、iframe、XHR 这些直接毙掉；图片、视频、音频这类“被动混合内容”稍微宽容点，但也会在地址栏给个警告，或者干脆升级成 https 再试。

但总有人想硬来

我见过一个内部运维平台，https 部署得好好的，结果某个监控大屏嵌了 http 的 Grafana 面板。浏览器拦了，页面白一块。运维小哥的解决办法很粗暴：在 Chrome 启动参数里加 --allow-running-insecure-content。能用，但只在他自己机器上管用。换个同事访问，照样白屏。这招治标不治本，而且等于把安全策略当空气。

更常见的场景是开发环境。本地起个 https 服务，调后端 http 接口。跨域加混合内容，双重暴击。有人图省事，直接用 Nginx 反代，把 http 接口转成同域的 https 路径。这招聪明，但配置起来得小心 proxy_pass 和 sub_filter，不然路径重写错了，请求全 404。我试过一次，忘了加 proxy_set_header Host $host;，后端拿到的 Host 是 localhost，直接返回 400。

浏览器其实给了台阶

Chrome 有个“网站设置”里的“不安全内容”权限，默认是“屏蔽”，可以手动改成“允许”。但普通用户根本不知道这回事，你也不能要求每个访客都去改。所以正经做法还是把资源换成 https。如果资源在第三方手里，人家不提供 https，那就自己搭个代理，用 https 包一层。Cloudflare 的 Flexible SSL 也能救急，但注意它只加密浏览器到 CF 那段，CF 到源站还是 http，算是半吊子方案。

我自己的博客以前图便宜，图床用的 http，后来换 https 后图片全挂。懒得迁移，就在 Nginx 里加了一段：

location /images/ {  proxy_pass http://old-cdn.example.com/; proxy_set_header Host old-cdn.example.com; }

然后把文章里的 http 图片地址全改成 /images/xxx.jpg。浏览器一看是同域 https，放行。后端偷偷走 http 去取，用户无感。这算是个取巧的中间层，但至少不用改数据库。

别忽略 CSP

有时候你换了 https 资源，浏览器还是拦。查一下响应头里的 Content-Security-Policy。如果写了 default-src 'self'，那外域资源一律禁止，跟 http 还是 https 无关。得加上 img-src 'self' https://cdn.example.com 这种白名单。我见过一个后台，CSP 设得死严，连 data: URI 的图片都不让加载，结果图标全裂。开发骂街，安全说合规，最后折中加了个 img-src 'self' data:。

说到底，https 页面加载 http 资源，本质是安全模型和现实妥协的拉锯。浏览器越来越强硬，Chrome 从 81 版开始直接把混合内容当错误，以后只会更严。与其跟它斗智斗勇，不如花半小时把资源全迁到 https。实在迁不动，就上个反代。别用启动参数那种自欺欺人的法子——你总不能要求每个用户都改浏览器配置吧。

对了，还有个小坑：upgrade-insecure-requests 这个 CSP 指令能让浏览器自动把 http 请求升级成 https。但前提是目标服务器支持 https。如果对方只有 http，升级后直接连接失败，比混合内容拦截还惨。用之前先测。