nginx反向代理后无限重定向的问题解决方法
作者:LYX6666
先说说奇葩的需求:https转其他网站的http
在项目里用iframe内嵌其他网站,这个“其他网站”不是我们开发的,并且是http,
但浏览器会默认阻止从https网站向http地址发起请求
因此初步的解决方案是:用我们自己的服务器nginx转发一次,虽然服务器到“其他网站”的传输还是明文,但至少可以做到甩锅(至少用户到我们的服务器的传输是SSL......)
然后这个“其他网站”就出现了无限重定向问题。
另外,根据以往的经历,在给WordPress加https的时候,也可能会遇到无限重定向的问题。
原因
本质上是因为:“其他网站”的服务程序具有请求头校验。
通常来说,nginx转发的请求,是带有原始请求头信息的请求。
比如:
nginx服务器的地址是https://server1.domin:1111
生产服务器的地址是http://server2.domin:2222
浏览器向https://server1.domin:1111发起请求
此时,虽然nginx把请求代理到了http://server2.domin:2222但由于一系列的参数设置,http请求头中的信息还是https://server1.domin:1111
这种情况下,如果“其他网站”的服务程序(Apache或nginx)中加入了请求头校验,也就是说,如果端口不是2222,就重定向;
如果地址不是server2.domin,就重定向。
而我们的nginx已经把请求头改成了原始信息,自然不能通过他们的验证,所以就会被强制重定向了。
如图,它把我的38004端口的请求重定向到了默认的443,说明对方服务器有地址校验,而且重定向只改变了端口。
而如果我的nginx恰好也用的443,就会无限重定向了。
解决
我们先来看看通常使用的nginx的重写参数:
server { listen 38002 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host $host; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_pass http://server2.domin:2222/; } }
这种情况下,就是直接在代理的请求中,加入原始请求头信息
那么我们怎么改呢?
我们要让对方服务器认为,nginx发过去的请求不是代理过去的,而是直接发过去的。
再换种方式说,此时nginx的作用不再是反向代理,而是正向代理,目的是隐藏真正的请求信息,让对方服
务器认为就是nginx直接请求的对方服务器。
所以我们要把ip、端口等等参数直接写死。
server { listen 443 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host server2.domin; // 对方服务器的域名 proxy_set_header X-Real-IP 123.123.123.123; // 对方服务器的真实地址,从控制台中找到 proxy_set_header X-Forwarded-For $123.123.123.123:80; proxy_set_header X-Forwarded-Host server2.domin; // 对方服务器的域名 proxy_set_header X-Forwarded-Port 80; // 对方服务器的端口 proxy_pass http://server2.domin:2222/; } }
于是代理过程就变成了这样:
总结
在我们不得不用nginx代理,并且无法让对方配合的情况下
只要把http中的请求头信息替换为对方网站的请求头信息(而不是使用原始信息)
就可以通过对方服务器的host验证了。
时间仓促,有些地方可能说的不准,但目前能用,如有错误欢迎指正。
以上就是nginx反向代理后无限重定向的问题解决方法的详细内容,更多关于nginx反向代理重定向的资料请关注脚本之家其它相关文章!