Nginx实战：解决HTTPS站点HTTP资源加载问题-Noname

在实际业务对接中，常会遇到与老旧第三方系统协作的场景，需引用其提供的图片、接口、静态文件等资源。我方站点已全面部署HTTPS协议，而第三方因系统限制，仅支持HTTP协议且短期内无法升级。受浏览器混合内容拦截机制影响，这类HTTP资源会被直接拦截，导致页面展示异常、功能报错，严重影响用户体验。针对该问题，通过Nginx几行核心配置即可快速解决，兼顾业务需求与安全性。

一、先搞懂：为啥HTTPS站点不能加载HTTP资源？

不是浏览器“故意刁难”，是出于安全考虑的“混合内容拦截”机制。简单说：

HTTPS是加密传输，数据在网络上跑不会被篡改、偷窥；但HTTP是明文传输，安全性没保障。如果HTTPS站点里混着HTTP资源，就像给加密的房间留了个没锁的窗户，整个站点的安全等级会被拉低，所以浏览器默认会拦截这类HTTP资源，控制台会报“混合内容”错误。

核心需求：不改变第三方资源的存储位置（对方改HTTPS不现实），也不让前端改太多代码，实现HTTP资源“无缝”在HTTPS站点里加载。

二、核心思路：用Nginx做“中转代理”

咱们自己的服务器有HTTPS证书，就让Nginx当一个“中间商”，帮前端搞定协议转换，逻辑很简单：

前端不直接请求第三方HTTP资源，而是请求咱们自己服务器的Nginx（HTTPS协议）；
Nginx收到请求后，解析出要访问的第三方HTTP资源地址；
Nginx以HTTP协议去请求第三方资源，拿到资源后，再用HTTPS协议返回给前端；
对前端来说，全程都是HTTPS请求，浏览器不拦截；对第三方来说，只是收到了Nginx的HTTP请求，完全无感知。

整个过程是“透明”的，前端和第三方都不用做额外改动，只需要配置Nginx就行，这也是企业里最低成本、最稳妥的方案。

三、实战Nginx配置

# 核心：HTTP资源转HTTPS代理（路径/through/可自定义，前后端统一即可）
location /through/ {
    # 限制允许的目标域名：仅放行a.example.com、b.example.com，同时解析URL
    if ($args ~* ^transfer=(https*://)?(a\.example\.com|b\.example\.com)(/?.*)$) {
        set $temp_args $1$2$3;  # 拼接完整的目标资源URL（含协议、域名、路径）
        set $temp_name $2;     # 提取白名单内的目标域名（用于设置请求头）
    }
    
    # 空值校验：若未匹配到有效URL（非白名单/参数错误），直接返回403禁止访问
    if ($temp_args = "") {
        return 403;
    }
    
    # 传递关键请求头，确保第三方站点正常响应
    proxy_set_header Host $temp_name; 
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 

    # 反向代理到目标资源地址，完成协议转换
    proxy_pass $temp_args; 
}

配置核心作用：通过白名单限制和空值校验防止代理被恶意调用，同时完成HTTP→HTTPS协议转换，下面直接看前端实战用法。

四、实战使用示例

原来前端的HTTP资源（仅支持a/b.example.com域名）：

<img src="http://a.example.com/static/img/logo.jpg">

改成代理路径请求，将资源URL作为transfer参数传入：

<img src="https://咱们的域名/through/?transfer=http://a.example.com/static/img/logo.jpg">

JS、CSS、接口请求用法一致，仅改资源地址，前端无需额外开发；若传非白名单域名（如c.example.com），会直接返回403。

五、总结

优化后的配置核心优势的是“简洁+安全”：仅用几行代码，既解决HTTPS站点加载HTTP资源的问题，又通过内置白名单、空值校验，从源头规避代理滥用风险，完全适配企业级生产环境。

目录CONTENT

Nginx实战：解决HTTPS站点HTTP资源加载问题