一、问题描述
搭了一个开源图床，因为备案的原因部署在海外。访问速度太慢准备上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就挂了，原因：重定向次数过多。
于是分析了一下，这么干确实有问题：
- nginx反向代理是用的http，对apache来说它收到了http请求，于是302重定向到https的页面。
- 然后CDN就访问重定向的https的页面，但是nginx收到之后又代理到http。
于是乎，CDN和apache之间就产生了某种误会，导致302死循环诞生！因此，这么干不行！得另寻它法。
那么现在的问题就产生了：如何圆润的以https的方式访问到docker内部的资源？
方案一：nginx和apache改成https通信
这个方案要做的工作：
- 手动生成https证书
- 在apache内部署https
- nginx和apache通过https代理
apache不熟悉，看了https部署比nginx要麻烦一些，而且内部通信也用https对性能有影响，所以就不考虑了（虽然这个方法可能比较有效，但是内心比较排斥apache，甚至想把docker中的apache换掉都不想用它配置https）。
方案二：使用nginx的sub_filter替换http为https
验证了一下，不可行，因为实际上返回到客户端的资源文件都是相对文件目录，不是http的全路径资源。
于是就崩了，百度了几天也没有办法解决。最后，在google上搜，竟然一下就找到了解决方案。
二、完美解决方案
设置http头部X-Forwarded-Proto，这个头部的作用是用于识别协议（HTTP 或 HTTPS），主要针对内部访问重定向时的协议。因此，只要在反向代理时添加以下配置就好了：
proxy_set_header X-Forwarded-Proto $scheme;$scheme是nginx的内部变量，表明当前访问的协议，当前如果是https，那么转发到后台服务的时候就是https。这样问题就解决了。
2 条评论
没有配置图，不知道在哪里加的。
在nginx反向代理的配置里面加的：
server {
location / {
# 其他配置
# proxy_set_header X-Forwarded-Proto $scheme
}
}