nginx

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > nginx > nginx反向代理重定向

nginx反向代理后无限重定向的问题解决方法

作者:LYX6666

这篇文章主要为大家介绍了nginx反向代理后无限重定向的问题解决方法详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

先说说奇葩的需求: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反向代理重定向的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文