http/https混合访问、跨域等问题的核心解决方案：反向代理

【问题描述】

• 在https下访问一个网页，然后在该网页中访问一个http后端接口，则会显示错误：
  Mixed Content: The page at https://* was loaded over HTTPS, but requested an insecure XMLHttpReque
  大意就是：https协议下不能访问http的资源，因为这样不安全
• 同理，浏览器中，在一个域名的网页中访问另一个域名的资源，也会存在跨域问题（CROS）

【问题解析】

• 以上问题，本质上是同一个问题：浏览器有着比较严格的审查机制，会对从服务器发回的信息进行重新审查。
• 当返回的协议信息是http时，就禁止https用户访问
• 当返回的域名与当前不相同时，就禁止该域名用户访问

【解决思路】

• 采用反向代理，隐藏服务器的真实信息
• 正向代理：在客户端到服务端的传输之间增加一个代理，从而篡改客户端的信息。如：VPN。
• 类似的，反向代理：在服务端到客户端的传输之间增加一个代理，从而篡改、隐藏服务器的信息。
• 因此，在前端服务器中，使用Nginx进行反向代理，即可解决以上问题。

【参考方法】

• 假设前端地址为https://a.com/，需要访问http://b.com/。
• 在Nginx配置文件中，增加

location /url/ {
        proxy_pass http://b.com/;
    }

• 其中，url为前端服务器名义上访问的子目录，http://b.com/为实际访问的服务器。
• 比如，定义一个地址https://a.com/url/any，此时，这个新地址则可以代表着http://b.com/any，后面的参数也会自动跟随。

【解决拓展】

• proxy_pass的匹配逻辑：最后有/时，代表绝对路径，不包含匹配部分；否则包含匹配部分。

假设下面分别用 http://a.com/proxy/any 进行访问。

• 第一种：
  location /proxy/ {
  proxy_pass http://b.com/;
  }
  代理到URL：http://b.com/any

• 第二种
  location /proxy/ {
  proxy_pass http://b.com;
  }
  代理到URL：http://b.com/proxy/any

【解决反思】

• 在尝试解决过程中，也尝试了重定向的方法。该方法显式地修改了地址，一定程度上也能解决问题，但是会造成整个路径的重新定向跳转。