HTTPS页面无法直接调用HTTP接口是因混合内容策略拦截，而非跨域；Nginx反向代理可将HTTP后端伪装为HTTPS同源路径，前端请求https://app.example.com/api/经Nginx转发至http://192.168.1.10:8080/，响应协议一致，彻底规避混合内容风险。
HTTPS 页面无法直接调用 HTTP 接口，不是因为“跨域”本身被浏览器阻止，而是因为混合内容（Mixed Content）策略被严格拦截——现代浏览器会直接阻止 HTTPS 页面中加载 HTTP 资源（包括 AJAX 请求），连 OPTIONS 预检请求都不会发出。Nginx 本身不解决混合内容问题，但可通过反向代理将 HTTP 接口“伪装”成同协议路径，让前端无感调用 HTTPS 域下的接口，从而绕过浏览器限制。
核心思路：用 Nginx 反向代理把 HTTP 接口转为 HTTPS 同源路径
关键不在加 CORS 头，而在消除协议差异。前端只访问自己的 HTTPS 域名（如 https://app.example.com），Nginx 将匹配的 API 路径（如 /api/）代理到后端 HTTP 服务（如 http://192.168.1.10:8080），整个过程对浏览器透明：
- 前端发起请求：https://app.example.com/api/users
- Nginx 拦截该路径，转发至：http://192.168.1.10:8080/users
- 响应返回时，协议、域名、端口均与页面一致，无混合内容风险
Nginx 配置示例（含必要安全细节）
以下配置部署在 HTTPS 站点 server 块内，假设你的 HTTPS 已通过 Let’s Encrypt 或其他方式就绪：
location ^~ /api/ {
proxy_pass http://192.168.1.10:8080/; # 注意末尾斜杠：保证 /api/users → /users
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme; # 透传协议，后端可识别 HTTPS
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
<pre class="brush:php;toolbar:false;"># 防止代理缓存敏感响应
proxy_cache off;
proxy_no_cache $http_pragma $http_authorization;
proxy_cache_bypass $http_pragma $http_authorization;
# 超时调优（按后端实际响应时间调整）
proxy_connect_timeout 10s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;}
注意：若后端接口返回 302 重定向，需额外配置 proxy_redirect 重写跳转地址，否则可能暴露内部 HTTP 地址。
为什么不能只加 CORS 头？
CORS 头（如 Access-Control-Allow-Origin）仅作用于真正的跨域请求（协议、域名、端口任一不同）。而 HTTPS 页面加载 HTTP 接口属于混合内容，浏览器在发起网络请求前就主动拦截，根本不会发送 OPTIONS 或 GET，CORS 完全无效。这是安全策略层级的不同：CORS 是资源访问控制，混合内容是传输层强制阻断。
补充建议：前后端协作更稳妥
- 后端接口应支持 X-Forwarded-Proto 判断真实协议，生成正确跳转 URL 或 HATEOAS 链接
- 前端发请求时统一用相对路径（/api/xxx），避免硬编码协议和域名
- 开发环境可用本地 Nginx 或 Webpack DevServer 代理模拟，保持环境一致性
- 如需调试，可在 Chrome 地址栏输入 chrome://flags/#unsafely-treat-insecure-origin-as-secure 临时放开（仅测试，不可用于生产）
真正堵住问题的不是 CORS，而是让浏览器认为“没跨协议”。Nginx 反向代理是最轻量、最可控的落地方式，既不改前端逻辑，也不强求后端升级 HTTPS，同时规避了证书管理、性能损耗等替代方案的副作用。
