踩坑记录：CDN开启强制https之后返回重定向次数过多的问题

一、问题描述

搭了一个开源图床，因为备案的原因部署在海外。访问速度太慢准备上CDN（有一个已备案的域名），但是在部署CDN的途中就出现了各种问题。鼓捣了几天终于解决了，记录下踩坑记录和解决方案。

软件环境：

图床是直接用docker部署了，没有再手动去折腾lnmp环境了，别人已经准备好的docer环境拿过来就直接用了。

用一个nginx作为CDN和图床服务的代理客户端，不直接把图床暴露出来了，也是一般服务的部署方式。

平常的服务大部分都是这么干的，用起来很舒服。

这个部署在http环境下是没有问题的，能正常使用。但是把http改成https的时候就出问题了，一开始的问题就是跨域：

因为nginx是配置的http反向代理：proxy_pass http://127.0.0.1:xxxx，到docker中的也是http，所以它返回到前端的js/css资源也是http的。而此时CDN开启了强制https，浏览器中已经是https，跨域就这么产生了。

为了解决这个问题，就在docker的web环境中也加一个强制https跳转，想着apache也强制https，那么就不会返回http资源，跨域解决。

想象是美好的，现实是残酷的，这么一配置之后，CDN就挂了，原因：重定向次数过多。

于是分析了一下，这么干确实有问题：

1. nginx反向代理是用的http，对apache来说它收到了http请求，于是302重定向到https的页面。
2. 然后CDN就访问重定向的https的页面，但是nginx收到之后又代理到http。

于是乎，CDN和apache之间就因为nginx的存在而产生了某种误会，导致302死循环诞生！因此，这么干不行！得另寻它法。

那么现在的问题就产生了：如何圆润的以https的方式访问到docker内部的资源？

方案一：nginx和apache改成https通信

这个方案要做的工作：

1. 手动生成https证书
2. 在apache内部署https
3. nginx和apache通过https代理

apache不熟悉，看了https部署比nginx要麻烦一些，而且内部通信也用https对性能有影响，所以就不考虑了（虽然这个方法可能比较有效，但是内心比较排斥apache，甚至想把docker中的apache换掉都不想用它配置https）。

方案二：使用nginx的sub_filter替换http为https

验证了一下，不可行，因为实际上返回到客户端的资源文件都是相对文件目录，不是http的全路径资源。

于是就崩了，百度了几天也没有办法解决。最后，在google上搜，竟然一下就找到了解决方案。

二、完美解决方案

设置http头部X-Forwarded-Proto，这个头部的作用是用于识别协议（HTTP 或 HTTPS），主要针对内部访问重定向时的协议。因此，只要在反向代理时添加以下配置就好了：

$scheme是nginx的内部变量，表明当前访问的协议，当前如果是https，那么转发到后台服务的时候就是https。这样问题就解决了。