Nginx配置文件详解2
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 的地址,那这时应该怎么办?
比如架构如下:
如果我们在 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 服务器的日志:
可以看到,$remote_addr 变量输出了用户的真实 ip 地址。
130 服务器的日志:
可以看到,在 $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 的配置,则可能会报以下错误:
此时可参考: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,即:
那么按照 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,但原理都一样。
假设架构如下:
在 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 服务器的日志:
130 服务器的日志:
可以看到,在 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 服务器日志:
130 服务器日志:
可以看到,在 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