一、问题描述
搭了一个开源图床,因为备案的原因部署在海外。访问速度太慢准备上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
}
}