当前位置首页 > Nginx知识

Nginx配置文件详解2

阅读次数:281 次  来源:admin  发布时间:

1、proxy_set_header

roxy_set_header 的语法:

# 语法。在http.server.location中设置
proxy_set_header field value;

#默认值
proxy_set_header Host $proxy_host;
proxy_set_header Connection close;

roxy_set_header 允许重新定义或者添加发往后端服务器的请求头。value 可以包含文本、变量或者它们的组合。 当且仅当当前配置级别中没有定义 proxy_set_header 指令时,会从上面的级别继承配置。 proxy_set_header 就是可设置请求头,并将头信息传递到服务器端。不属于请求头的参数中也需要传递时重定义下就行啦。

在 java 端可以使用 request.getHeader(field) 方法来获取 获取 proxy_set_header 设置的参数的值,一般在用来获取真实 ip 地址时会用到。

2、获取用户真实ip 2.1、通过 X-Real-Ip 获取用户真实i

在实际应用中,我们可能需要获取用户的ip地址,比如统计 ip 访问次数等。通常情况下我们使用 request.getRemoteAddr() 就可以获取到客户端ip,但是当我们使用了nginx作为反向代理后,直接使用 request.getRemoteAddr() 获取到的就一直是 nginx 服务器的 ip 的地址,那这时应该怎么办?

比如架构如下:

Nginx配置文件详解2

如果我们在 130 的服务器上直接通过 request.getRemoteAddr() 获取 ip 地址,实际上获取到的是 128 Nginx 服务器的 ip,而不是用户的 32.1 的ip。在 130 的两台服务器上获取不到用户的真实 ip,但实际上在 128 Nginx 服务器上是可以通过 $remote_addr 变量获取到用户的真实 ip 的。

我们可以在 128 代理服务器上做以下配置(上面架构只需在 128 配置 x-real-ip,130无需配置):

upstream nginxServer {
        hash $http_x_forwarded_for;   #这里是为了会话保持

        server 192.168.32.130:80;
        server 192.168.32.130:81;
}

server {
    listen       80;
    server_name  localhost;

    location / {
        proxy_pass http://nginxServer;
        real_ip_header X-Forwarded-For;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
    }
}

其实 X-Real-Ip 只是一个自定义的变量名,X-Real-Ip目前并不属于任何标准,代理和 Web 应用之间可以约定用任何自定义头来传递这个信息。上面配置完,用户的真实 ip 就被放在 X-Real-IP 这个变量里了,然后在web端可以这样获取:request.getAttribute("X-Real-IP")。

我们在 128 和两台 130 服务器上修改 Nginx 日志输出格式如下,可以通过日志输出来看到 130 服务器上的 $http_x_real_ip 有输出用户的真实 ip:

http {
    ...
    log_format  main  '$http_x_forwarded_for|$http_x_real_ip|$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  logs/access.log  main;  #注意,必须添加这句,没有这句上面的配置不会起作用
   ...
}

128 服务器的日志:

Nginx配置文件详解2

可以看到,$remote_addr 变量输出了用户的真实 ip 地址。

130 服务器的日志:

Nginx配置文件详解2

可以看到,在 $http_x_real_ip 变量中可以看到用户真实的 ip 地址,并且 $remote_addr 指向的是 128 代理服务器的地址。

上面适用的是只经过了一个代理服务器,如果经过多个代理服务器时,可以像下面这么做。当一个请求通过多个代理服务器时,用户的IP将会被代理服务器IP覆盖:

#在第一个代理服务器中设置
set x_real_ip=$remote_addr
#最后一个代理服务器中获取
$x_real_ip=IP1

参考:https://blog.csdn.net/qq_34556414/article/details/78185057

2.1.1、解决配置 realip 模块报错问题

如果我们没有配置 realip,而在 Nginx 配置中使用 real_ip_header 的配置,则可能会报以下错误:

Nginx配置文件详解2

此时可参考:https://blog.csdn.net/qq_33101675/article/details/79013248。注意,链接中方法是重新安装了一个 Nginx,链接中的方法指定了安装的新的 Nginx 在 /usr/cmcc/nginx/conf 目录下,所以我们应该使用该目录下的 Nginx,如果我们还用旧的 Nginx 的话可能会报同样的错误。

realip模块的作用是:当本机的nginx处于一个反向代理的后端时获取到真实的用户IP。

如果没有realip模块,nginx的access_log里记录的IP会是反向代理服务器的IP,PHP中$_SERVER[‘REMOTE_ADDR’]的值也是反向代理的IP。而安装了realip模块,并且配置正确,就可以让nginx日志和php的REMOTE_ADDR都变成真实的用户IP。

2.2、X-Forwarded-For 获取用户真实i

X-Forwarded-For 是一个 HTTP 扩展头部。HTTP/1.1(RFC 2616)协议并没有对它的定义,它最开始是由 Squid 这个缓存代理软件引入,用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准,被各大 HTTP 代理、负载均衡等转发服务广泛使用,并被写入 RFC 7239(Forwarded HTTP Extension)标准之中。

由于它是非 rfc 标准,所以默认情况下是没有该请求头的,即 X-Forwarded-For 的值在默认情况下是空的。现在我们需要利用该请求头来记录用户的真实 ip,此时需要我们手动在nginx添加配置:proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for

X-Forwarded-For 请求头的最后显示的格式:

X-Forwarded-For: client, proxy1, proxy2

可以看到,XFF 的内容由逗号 , 隔开的多个部分组成,最开始的是离服务端最远的设备 IP,然后是每一级代理设备的 IP。

假设一个 HTTP 请求到达服务器之前,经过了三个代理 Proxy1、Proxy2、Proxy3,IP 分别为 IP1、IP2、IP3,用户真实 IP 为 IP0,即:

Nginx配置文件详解2

那么按照 XFF 标准,服务端最终会收到以下信息:

X-Forwarded-For: IP0, IP1, IP2

Proxy3 直连服务器,它会给 XFF 追加 IP2,表示它是在帮 Proxy2 转发请求。列表中并没有 IP3,IP3 可以在服务端通过 Remote Address 字段获得。不同语言获取 Remote Address 的方式不一样,例如 php 是 $_SERVER["REMOTE_ADDR"],Node.js 是 req.connection.remoteAddress,但原理都一样。

假设架构如下:

Nginx配置文件详解2

在 128 代理服务器上做以下配置:

upstream nginxServer {
        hash $http_x_forwarded_for;   #这里是为了会话保持

        server 192.168.32.130:80;
        server 192.168.32.130:81;
}

server {
    listen       80;
    server_name  localhost;

    location / {
        proxy_pass http://nginxServer;
        real_ip_header X-Forwarded-For;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
    }
}

注意,上面并没有做 X-Forwarded-For 的配置。我们在 128 和两台 130 服务器上修改 Nginx 日志输出格式如下,这样就可以通过日志输出的 $http_x_forwarded_for 看到 X-Forwarded-For 请求头的值。

http {
    ...
    log_format  main  '$http_x_forwarded_for|$http_x_real_ip|$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  logs/access.log  main;  #注意,必须添加这句,没有这句上面的配置不会起作用
   ...
}

128 服务器的日志:

Nginx配置文件详解2

130 服务器的日志:

Nginx配置文件详解2

可以看到,在 128 和 130 上都没有 X-Forwarded-For 请求头的数据,也就说明在默认情况下是没有 X-Forwarded-For 请求头的,我们需要主动在 Nginx 上配置。

由此我们在 128 服务器上添加配置 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for,最后配置如下:

upstream nginxServer {
    hash $http_x_forwarded_for;

    server 192.168.32.130:80;
    server 192.168.32.130:81;
}

server {
    listen       80;
    server_name  localhost;

    location / {
        proxy_pass http://nginxServer;
        real_ip_header X-Forwarded-For;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;   #添加了X-Forwarded-For配置
    }
}

重启服务器发出请求再次查看日志如下:

128 服务器日志:

Nginx配置文件详解2

130 服务器日志:

Nginx配置文件详解2

可以看到,在 128 服务器上仍然没有 X-Forwarded-For 请求头的数据(这是正常的),但在 130 服务器可以看到 X-Forwarded-For 请求头的数据,指向的确实是用户的真实 ip。如果经过多个代理,你会发现 X-Forwarded-For 请求头是 client, proxy1, proxy2 的格式。

参考:https://blog.csdn.net/qq_34556414/article/details/78185057

3、upstream

upstream rtpserver {
        #server 192.168.32.128:8081;
        server 192.168.32.128:8082;
        check_interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "GET / HTTP/1.1\r\nConnection:keep-alive\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx http_4xx;
        keepalive 100;
}

指令:

Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]

Default: 如果没有配置参数,默认值是:interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tc

Context: upstream

该指令可以打开后端服务器的健康检查功能

指令后面的参数意义是:

interval:向后端发送的健康检查包的间隔。 fall(fall_count): 如果连续失败次数达到fall_count,服务器就被认为是down。 rise(rise_count): 如果连续成功次数达到rise_count,服务器就被认为是up。 timeout: 后端健康请求的超时时间。 default_down: 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的。 type:健康检查包的类型,现在支持以下多种类型 tcp:简单的tcp连接,如果连接成功,就说明后端正常。 ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包。 http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活。 mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活。 ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活。 port: 指定后端服务器的检查端口。你可以指定不同于真实服务的后端服务器的端口,比如后端提供的是443端口的应用,你可以去检查80端口的状态来判断后端健康状况。默认是0,表示跟后端server提供真实服务的端口一样。该选项出现于Tengine-1.4.0。

Syntax: check_http_send http_packet

Default: "GET / HTTP/1.0\r\n\r\n"

Context: upstream

该指令可以配置http健康检查包发送的请求内容。为了减少传输数据量,推荐采用"HEAD"方法。

Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]

Default: http_2xx | http_3xx

Context: upstream

该指令指定HTTP回复的成功状态,默认认为2XX和3XX的状态是健康的。

https://tengine.taobao.org/document_cn/http_upstream_check_cn.html

上一篇:apache模块合并多个js/css提高网页加载速度
下一篇:CentOS7.3CDH5.10.0Druid0.12.4安装记录