现代浏览器默认拦截https页面中的http资源（混合内容），并非nginx问题，而是安全策略：主动型（脚本、iframe）被强制阻止，被动型（图片等）在新版浏览器中同样被静默屏蔽；解决需nginx配置301跳转、注入csp头（含upgrade-insecure-requests）、透传x-forwarded-proto，前端则须使用协议相对url或根相对路径确保资源协议一致。
现代浏览器对资源加载越来越严格，尤其在 HTTPS 环境下，若页面通过 HTTPS 加载，但其中某张图片、脚本或 iframe 的地址是 HTTP（即混合内容），浏览器会直接阻止加载——不是报错，而是静默屏蔽，连控制台都可能不提示（取决于浏览器版本和设置）。这不是 Nginx 的 bug，而是浏览器主动执行的安全策略。适配关键不在“让图片显示”，而在“让所有资源走安全协议、符合同源约束、声明可信来源”。
一、为什么“没证书就不显示图片”？根源是混合内容拦截
当网页本身由 HTTPS 提供（比如 https://example.com），但 HTML 中写了：<img src="http://cdn.example.com/logo.png?x-oss-process=image/resize,p_40">
这个 HTTP 图片就是混合主动内容（mixed active content）。Chrome、Firefox、Edge 等主流浏览器自 2017 年起默认阻止此类请求，且不给 fallback 提示——图片位置留白，Network 面板里状态为 blocked:mixed-content。
注意：仅图片（<img>）属于“被动内容”，部分旧版浏览器曾允许加载，但当前所有现代浏览器（Chrome 100+、Firefox 110+、Safari 16+）已统一按主动内容标准拦截，尤其当页面含 script、iframe、audio/video 时，整个页面可能被标记为“不安全”。
二、Nginx 层必须做的三件事
Nginx 不生成证书，也不校验证书有效性，但它能强制重定向、改写响应、注入安全头，从源头减少混合内容发生概率：
-
全站 301 强制跳转 HTTPS：避免用户访问 http:// 时渲染出含 HTTP 资源的页面
在 HTTP server 块中加：return 301 https://$host$request_uri; -
响应头注入 Content-Security-Policy（CSP），明确只允许 HTTPS 资源：
add_header Content-Security-Policy "default-src 'self' https:; img-src 'self' https: data:; upgrade-insecure-requests;" always;
其中upgrade-insecure-requests是关键：它告诉浏览器，自动把所有http://资源请求升级为https://（前提是目标服务器支持 HTTPS）；https:表示允许任意 HTTPS 来源；data:保留 base64 图片等内联资源。 -
隐藏后端真实协议暴露：若 Nginx 作为反向代理，后端是 HTTP（如本地 Node.js 服务），务必在 proxy_pass 后添加：
proxy_set_header X-Forwarded-Proto $scheme;
并确保应用层（如 Express、Django）读取该 header 判断是否为安全连接，否则生成的绝对 URL 仍可能是 http://。
三、前端配合不可省：相对协议 + 协议无关 URL
Nginx 再强也管不了 HTML 源码。如果静态页里硬编码了 http://，Nginx 无法自动替换（除非用第三方模块如 sub_filter，但性能差、易出错）。更可靠的方式是前端规范：
- 用 协议相对 URL：
//cdn.example.com/logo.png—— 浏览器自动继承当前页面协议； - 用 根相对路径：
/images/logo.png，配合 Nginx 正确配置location /images代理到 HTTPS CDN； - 服务端模板（如 Jinja、EJS）中，动态拼接 URL 时优先使用
request.scheme或window.location.protocol判断。
四、验证是否生效的实操方法
别只看页面有没有图——要查底层行为：
- 打开 Chrome DevTools → Network 标签 → 刷新页面 → 查看所有图片请求的 Status 列，确认没有
blocked:mixed-content； - 在 Console 中执行：
document.querySelectorAll('img').forEach(i => console.log(i.currentSrc))，检查所有currentSrc是否均为https://开头； - 用 curl 检查响应头：
curl -I https://example.com | grep -i "content-security-policy\|strict-transport-security"
确认 CSP 和 HSTS 头存在且格式正确。
本质上，这不是“Nginx 适配浏览器”，而是 Nginx 协同前端，共同遵守浏览器制定的现代安全契约。证书只是入场券，真正起作用的是协议一致性、头信息声明和资源路径设计。
