Nginx配置文件详解2

1、proxy_set_header 重新定义或者添加转发的请求头

proxy_set_header 的语法：

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

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

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

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

2、获取用户真实ip

2.1、X-Forwarded-For 获取用户真实ip

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，因为$proxy_add_x_forwarded_for 变量只能获取到请求者的ip，当前接收者的ip不会插入进去。所以在 Proxy3 转发给最终的接收者 server 时，server 接收到的请求 X-Forwarded-For 并不会包含 IP3。当然，IP3 可以在 server 服务端通过 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;
    }
}

注意，上面并没有做 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;
        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

2.2、利用 $remote_addr 获取用户真实ip

在实际应用中，我们可能需要获取用户的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;
        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 代理服务器的地址。

上面适用的是只经过了一个代理服务器，如果经过多个代理服务器时，$remote_addr 指的将是上一个代理服务器的 ip 而不是用户的 ip，此时可以像下面这么做。

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

参考：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=tcp
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"方法。

当采用长连接进行健康检查时，需在该指令中添加keep-alive请求头，如："HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n"。
同时，在采用"GET"方法的情况下，请求uri的size不宜过大，确保可以在1个interval内传输完成，否则会被健康检查模块视为后端服务器或网络异常。

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

posted @ 2021-08-04 18:58 wenxuehai 阅读(402) 评论(0) 编辑收藏举报

刷新页面返回顶部

提升自己，才有选择的能力和勇气