折腾nginx反向代理的记录

什么是反向代理?

反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个反向代理服务器。

我们换个方式理解,就是当外部网络对内部网络器是不能直接访问的,要通过一个代理服务器才能进行访问,而外部网络看到的只是代理服务器,反馈也是由代理服务器返回的,外部网络对于代理服务器与内部网络直接的具体情况是不可见的。

正向代理和反向代理什么区别?

正向代理是一个位于客户端和原始服务器(origin server)之间的服务器,为了从原始服务器取得内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。

这里有一个最显著的区别是:(可以看下面的图示来感受)

  • 正向代理是客户端知道目的服务器在哪里,然后通过代理服务器去访问客户端不能直接访问的目标服务器,而目标服务器并不知道客户端通过什么来访问的, 即 正向代理代理的是客户端
  • 反向代理中,外部网络对于内部网络具体的情况是不可见的,而代理服务器来代理内部网络来返回所要的数据(当然静态文件可以放在Nginx,这个静动分离再说),而服务端知道请求的来源以及数据 反向代理代理的是服务端 。
    Nginx正反向代理图示

反向代理的好处

  1. 保护了真实的web服务器,web服务器对外不可见,外网只能看到反向代理服务器,而反向代理服务器上并没有真实数据,因此,保证了web服务器的资源安全。
  2. 反向代理为基础产生了动静资源分离以及负载均衡的方式,减轻web服务器的负担,加速了对网站访问速度(动静资源分离和负载均衡会以后说)
  3. 节约了有限的IP地址资源,企业内所有的网站共享一个在internet中注册的IP地址,这些服务器分配私有地址,采用虚拟主机的方式对外提供服务;

反向代理在Nginx.conf的简单配置

server {
        listen       8182;
        server_name  localhost;
        ...
        location / {
	    proxy_pass http://localhost:8082;  
	    ...
        }
        
    }
复制代码

server块可以理解为一个虚拟主机,此时我们如果调用的是http://localhost:8182时,会将这个请求转发到http://localhost:8082,因此实际处理这个请求的是http://localhost:8082

使用Nginx后web服务器如何获得真实的用户IP

问题:

当使用Nginx后,web服务器中request.getRemoteAddr(),得到的是Nginx的ip,而不是真实用户的ip

解决方案:

在nginx.conf的的中的location中添加一些赋值操作

server {
        ...
        location / {
            ...
            proxy_set_header    Host $host;
            proxy_set_header    X-real-ip $remote_addr;
            proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        }
        
    }
复制代码

然后web服务端就可以可以通过request.getHeader(“X-Forwarded-For”);来获得真实的用户ip

最后记得重启nginx

systemctl restart nginx

负载均衡的示例

        #设定负载均衡的服务器列表
        #weigth参数表示权值,权值越高被分配到的几率越大
        upstream Mos{
            server 192.168.1.106:80 weight=3;  
            server 192.168.1.143:80 weight=1;  
            #server localhost:80 weight=1; #本机
        }

        server {
            listen       80;
            server_name  localhost;
            index index.html index.htm index.php;
            root /mnt/web/hyicnoa;

            location / {
                if (!-e $request_filename){
                    rewrite ^/(.*)$ /index.php?s=/$1 last;
                    }
                proxy_pass http://Mos ;  #在这里设置一个代理,和upstream的名字一样
                }
            location ~ .*.(php|php5)?$
            {
                #fastcgi_pass  unix:/tmp/php-cgi.sock;
                fastcgi_pass  127.0.0.1:9000;
                fastcgi_index index.php;
                include fastcgi.conf;
            }
            location ~ .php$ 
            {
                proxy_pass  http://192.168.1.106; #此处限制访问 php 文件时,跳转到192.168.1.106 服务器解析
            }
            location ~ .*.(js|css)?$
            {
            expires 1h;
            }
        }

不同文件分发到不同服务器进行解析

location ~ .php$ 
            {
                proxy_pass  http://192.168.1.106; #此处限制访问php文件时,跳转到192.168.1.106服务器解析
            }
location ~* .(jpg|jpeg|gif|png|swf)$ {
         if (-f $request_filename) {
             root /date/wwwroot/linuxtone/;
             expires            1d;
             break;
            }
     }

 

不同目录分发到不同服务器解析

 location /zmPro/ {
        proxy_pass http://192.168.1.143; #当访问zmPro目录时,由该IP服务器进行解析
        }

反向代理后session的问题,使用memcache或者redis进行

php_value session.gc_maxlifetime 3600
php_value session.save_handler "memcache"  
php_value session.save_path  "tcp://192.168.10.11:1211"  

反向代理后session的问题,另一个解决办法,使用ip_hash

nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端,这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session,ip_hash是在upstream配置中定义的:

upstream backend {
  server 127.0.0.1:8080 ;
  server 127.0.0.1:9090 ;
   ip_hash;
}

ip_hash是容易理解的,但是因为仅仅能用ip这个因子来分配后端,因此ip_hash是有缺陷的,不能在一些情况下使用:

1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器,否则nginx得不到正确ip,就不能根据ip作hash。譬如使用的是squid为最前端,那么nginx取ip时只能得到squid的服务器ip地址,用这个地址来作分流是肯定错乱的。

2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡,将请求又通过另外的方式分流了,那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来,nginx后端只能直接指向应用服务器,或者再搭一个squid,然后指向应用服务器。最好的办法是用location作一次分流,将需要session的部分请求通过ip_hash分流,剩下的走其它后端去。

nginx 的 upstream目前支持 4 种方式的分配 
1)、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
2)、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
2)、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
3)、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
4)、url_hash(第三方)

 

知识点介绍:

  • proxy_set_header X-real-ip $remote_addr;
    这里的X-real-ip是一个自定义名,名字随意,效果是可以将 ip 就被放在 X-real-ip 这个变量里了,可以通过request.getHeader(“X-real-ip “)获取当前的值,与X-Forwarded-For,下文会进行解释
  • proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

首先我们要知道什么是X-Forwarded-For?

X-Forwarded-For:简称XFF头,它代表客户端,也就是HTTP的请求端真实的IP,只有在通过了HTTP 代理或者负载均衡服务器时才会添加该项。用于识别通过HTTP代理或负载平衡器原始IP一个连接到Web服务器的客户机地址的非rfc标准,

当Nginx有进行X-Forwarded-For设置的话,每次经过proxy转发都会有记录,格式就是client1, proxy1,proxy2,以逗号隔开各个地址,而且由于他是非rfc标准,所以默认是没有的,需要强制添加,通过Proxy转达的时候,后端服务器看到的远程ip是Proxy的ip,也就是说如果直接使用request.getHeader(“X-Forwarded-For”)是获取不到用户ip的,那我们要如何设置获得用户ip呢?

此时就需要在nginx配置的location块中添加

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for
复制代码

注意这里的意思是增加到X-Forwarded-For中,不是覆盖,而增加后的格式就是之前说的“client1,proxy1….”,默认的时候X-Forwarded-For是空的,如果有两个nginx,并且都配置了上面这个命令,则会在web服务器的request.getHeader(“X-Forwarded-For”)获得的是“用户ip,第一个nginx的ip”,分别对应之前的格式。

proxy_add_forwarded_for包含着两个格式,前面一部分是请求头的X-Forwarded-For,而后面$remote_addr,也就是说是远程用户的ip

我们来个图浅显的解释下:

反向代理X-Forwarded_For图解

X-real-ip与X-Forwarded-For的区别

X-real-ip是覆盖,而X-Forwarded-For是后面添加举个例子,请求由1.1.1.1发出,经过三层代理,第一层是2.2.2.2,第二层是3.3.3.3,而本次请求的来源IP4.4.4.4是第三层代理,

而X-Real-IP,没有相关标准,上面的例子,如果配置了X-Read-IP,可能会有两种情况

最后一跳是正向代理,可能会保留真实客户端IP:X-Real-IP: 1.1.1.1// 最后一跳是反向代理,比如Nginx,一般会是与之直接连接的客户端IP:X-Real-IP: 3.3.3.3
复制代码

而X-Forwarded-For的结果则是

X-Forwarded-For:1.1.1.1, 2.2.2.2, 3.3.3.3
复制代码

所以如果只有一层代理,则两个值是一样的

 

强烈建议匹配不同内容时,注意访问的可行性,以及文件的同步性,建议可参考文章 nginx 反向代理配置及优化

附录

1). 推荐文章

2). 参考文章

木易的技术记录 » 折腾nginx反向代理的记录

顶 (0)

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

置顶文章