07《Nginx 入门教程》Nginx 的 Http 模块介绍（上）

Posted 2023-04-03

参考技术A

本部分内容将详细介绍 nginx 中对 Http请求的 11 个处理阶段，分成 3 个小节讲解并进行相关实验操作。

Nginx 将一个 Http 请求分成多个阶段，以模块为单位进行处理。其将 Http请求的处理过程分成了 11 个阶段，各个阶段可以包含任意多个 Http 的模块并以流水线的方式处理请求。这 11 个 Http 阶段如下所示：

网上有人做了一个非常形象的图片，如下图所示。我们可以看到 11 个阶段的处理顺序，以及每个阶段中涉及到的相关模块以及模块之间的顺序。

POST_READ 阶段是 Nginx 接收到 Http 请求完整头部后的处理阶段，这里主要使用的是 realip 模块获取用户的真实地址，方便后续对该 IP 进行限速或者过滤其请求等。

SERVER_REWRITE 和后面的 REWRITE 阶段一般是使用 rewrite 模块修改 Http请求的 uri，实现请求的控制。

FIND_CONFIG 阶段只是做 location 的匹配项。

PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 请求访问权限相关的阶段。PREACCESS 阶段是在连接之前要做的访问控制, 这个阶段有 limit_conn 和 limit_req 等模块工作。ACCESS 阶段是解决用户能不能访问，比如根据用户名、密码限制用户访问(auth_basic 模块)、根据 ip 限制用户访问(access 模块)以及第三方模块认证限制用户的访问(auth_request模块)。POST_ACCESS 是在 ACCESS 之后要做的一些工作。

TRY_FILES 阶段为访问静态文件资源而设置的。有时候又称之为 PRECONTENT 阶段，即在 CONTENT 阶段之前做的事情。主要是 try_files 模块在此阶段工作。

最重要的 CONTENT 是处理 Http 请求内容的阶段，大部分 HTTP 模块介入这个阶段，比如 index、autoindex、concat 以及反向代理的模块都是在这里生效的。

LOG 是处理完请求后的日志记录阶段，如 access_log 模块。

realip 模块是在 postread 阶段生效的，它的作用是: 当本机的 nginx 处于一个反向代理的后端时获取到真实的用户 ip。 如果没有 realip 模块，Nginx 中的 $remote_addr 可能就不是客户端的真实 ip 了，而是代理主机的 ip。
realip模块的配置实例如下:

set_real_ip_from 是指定我们信任的后端代理服务器，real_ip_header 是告诉 nginx 真正的用户 ip 是存在 X-Forwarded-For 请求头中的。

当 real_ip_recursive 设置为 off 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个 ip 当成真实 ip;

而当 real_ip_recursive 为 on 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个不是信任服务器的 ip (前面设置的set_real_ip_from)当成真实 ip。通过这样的手段，最后拿到用户的真实 ip。

rewrite 模块可以看到它在 SERVER_REWRITE 和 REWRITE 阶段都有介入。rewrite 模块的主要功能是改写请求的 uri。它是 Nginx 默认安装的模块。rewrite 模块会根据正则匹配重写 uri，然后发起内部跳转再匹配 location, 或者直接做30x重定向返回客户端。rewrite 模块的指令有 break, if, return, rewrite, set 等，这些都是我们常用到的。

return 指令返回后，Http 请求将在 return 的阶段终止，后续阶段将无法进行，所以许多模块得不到执行。

1、将 regex 指定的 url 替换成 replacement 这个新的 url,可以使用正则表达式及变量提取。

2、当 replacement 以 http:// 或者 https:// 或者 $schema 开头，则直接返回 302 重定向

3、替换后的 url 根据 flag 指定的方式进行处理

if 指令的条件表达式:

location 匹配是在 FIND_CONFIG 阶段进行的，我们需要掌握 location 的匹配规则和匹配顺序。

有一个简单总结如下：

即：

realip 模块默认没有被编译进 Nginx 的，我们需要在源码编译阶段使用–with-http_realip_module，将 realip 模块编译进来后方可使用。接下来，我们做个简单测试，首先准备一个 server 块如下：

首先，我们将 real_ip_recursive 设置为 off，然后做一次请求:

这里返回的是头部参数 X-Forwarded-For 中最后一个 ip，如果将 real_ip_recursive 设置为 on，此时，由于 set_real_ip_from 中设置218.19.206.164为信任的方向代理 ip，那么 Nginx 会往前找一位，认为 1.1.1.1 是用户的真实ip。

我们写一个简单配置如下：

先测试if指令，当请求方法为 POST 时，我们能得到 ‘post request!’ 这样的字符串输出。GET 请求时候，针对 404 情况，会跳转到/403.html，我们准备一个 403.html 页面，里面写上’403, forbidden!’ 这一行内容，开始下面的 Http 请求:

如果我们打开 return 405 这行指令，则 error_page 将不会生效，连同后面的 location 匹配也不会生效。无论我们发送如何请求，都会返回405的错误信息。这是因为 server 中的 return 指令是在 SERVER_REWRITE中执行的，而 location 匹配则是在下一个阶段 FIND_CONFIG 中执行的，所以上一个阶段在 return 后，根本不会进入后面的阶段执行。

首先，我们准备环境，首先是新建一个目录 third（全路径为/root/test/third），再该目录下新建一个文件 3.txt, 里面只有一行内容 ‘hello, world’。接下来，我们准备一个 server 块，加到 Http 指令块中:

上述配置中，要打开 rewrite_log指令，这样我们可以看到 rewrite 指令的相应日志，方便查看结果。

当我们在 /second 配置中，使用 break 时，请求命令:

如果是不使用 break 标识，则请求结果如下:

首先是 /first/3.txt 请求在 /first 中匹配，并被替换为 /second/3.txt， last 标识表示将继续进行匹配，在 /second 中，uri 又被 rewrite 成 /third/3.txt, 如果后面跟了 break 标识，表示 rewrite 到此结束，不会执行后面的 return 指令，直接请求静态资源 /third/3.txt,得到其内容’hello, world’;如果是没有 break 标识，则会在执行 return 指令后直接返回，并不会继续执行下去，最后返回’second!\'字符串。

我们按照这样的 location 规则，进行匹配实验，结果如下：

这里介绍了 Nginx 处理 Http 请求的 11 个阶段，并重点介绍了 前三个阶段POST_READ、REWRITE以及FIND_CONFIG以及这些阶段中涉及到的模块和指令。前面讲到的指令都是 Nginx 中的高频指令，必须要熟练掌握。

Nginx常用配置实例

Nginx作为一个HTTP服务器，在功能实现方面和性能方面都表现得非常卓越，完全可以与Apache相媲美，几乎可以实现Apache的所有功能，下面就介绍一些Nginx常用的配置实例，具体包含虚拟主机配置、负载均衡配置、防盗链配置以及日志管理等。

 

一、 虚拟主机配置实例

下面在Nginx中创建三个虚拟主机，需要说明的是，这里仅仅列出了虚拟主机配置部分。 

 

http {  

 server {  

 listen          80;  

 server_name     www.domain1.com;  

 access_log      logs/domain1.access.log main;  

 location / {  

 index index.html;  

 root  /web/www/domain1.com/htdocs;  

 }  

  }  

 server {  

 listen          80;  

 server_name     www.domain2.com;  

 access_log      logs/domain2.access.log main;  

 location / {  

 index index.html;  

 root  /web/www/domain2.com/htdocs;  

 }  

  }  

  include    /opt/nginx/conf/vhosts/www.domain2.com.conf;  

}  

这里用到了include指令，其中/opt/nginx/conf/vhosts/www.domain2.com.conf的内容为：

 

server {  

 listen          80;  

 server_name     www.domain3.com;  

 access_log      logs/domain3.access.log main;  

 location / {  

 index index.html;  

 root  /web/www/domain3.com/htdocs;  

 }  

  }  

二、 负载均衡配置实例

下面通过Nginx的反向代理功能配置一个Nginx负载均衡服务器。后端有三个服务节点，用于提供Web服务，通过Nginx的调度实现三个节点的负载均衡。

http   

{  

  upstream  myserver {  

    server   192.168.12.181:80 weight=3 max_fails=3 fail_timeout=20s;  

    server   192.168.12.182:80 weight=1 max_fails=3 fail_timeout=20s;  

    server   192.168.12.183:80 weight=4 max_fails=3 fail_timeout=20s;  

  }  

  server  

  {  

    listen       80;  

    server_name  www.domain.com 192.168.12.189;  

    index index.htm index.html;  

    root  /ixdba/web/wwwroot;    

location / {  

 proxy_pass http://myserver;  

 proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;  

 include    /opt/nginx/conf/proxy.conf;  

 }  

  }  

}

 在上面这个配置实例中，首先定义了一个负载均衡组myserver，然后在location部分通过“proxy_pass http://myserver”实现负载调度功能，其中proxy_pass指令用来指定代理的后端服务器地址和端口，地址可以是主机名或者IP地址，也可以是通过upstream指令设定的负载均衡组名称。

proxy_next_upstream用来定义故障转移策略，当后端服务节点返回500、502、503、504和执行超时等错误时，自动将请求转发到upstream负载均衡组中的另一台服务器，实现故障转移。最后通过include指令包含进来一个 proxy.conf文件。

其中/opt/nginx/conf/proxy.conf的内容为：

 proxy_redirect off;  

proxy_set_header Host $host;  

proxy_set_header X-Real-IP $remote_addr;  

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  

proxy_connect_timeout 90;  

proxy_send_timeout 90;  

proxy_read_timeout 90;  

proxy_buffer_size  4k;  

proxy_buffers 4 32k;  

proxy_busy_buffers_size 64k;  

proxy_temp_file_write_size 64k;  

Nginx的代理功能是通过http proxy模块来实现的。默认在安装Nginx时已经安装了http proxy模块因此可直接使用http proxy模块。下面详细解释proxy.conf文件中每个选项代表的含义。

? proxy_set_header：设置由后端的服务器获取用户的主机名或者真实IP地址，以及代理者的真实IP地址。

? client_body_buffer_size：用于指定客户端请求主体缓冲区大小，可以理解为先保存到本地再传给用户。

? proxy_connect_timeout：表示与后端服务器连接的超时时间，即发起握手等候响应的超时时间。

? proxy_send_timeout：表示后端服务器的数据回传时间，即在规定时间之内后端服务器必须传完所有的数据，否则，Nginx将断开这个连接。

? proxy_read_timeout：设置Nginx从代理的后端服务器获取信息的时间，表示连接建立成功后，Nginx等待后端服务器的响应时间，其实是Nginx已经进入后端的排队之中等候处理的时间。

? proxy_buffer_size：设置缓冲区大小， 默认,该缓冲区大小等于指令proxy_buffers设置的大小。 

? proxy_buffers：设置缓冲区的数量和大小。nginx从代理的后端服务器获取的响应信息，会放置到缓冲区。

? proxy_busy_buffers_size：用于设置系统很忙时可以使用的proxy_buffers大小，官方推荐的大小为proxy_buffers*2。

? proxy_temp_file_write_size：指定proxy缓存临时文件的大小。

 

三、 防盗链配置实例

 Nginx的防盗链功能也非常强大。在默认情况下，只需要进行简单的配置，即可实现防盗链处理。请看下面的这个实例：

 

location ~* \.(jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar)$ {  

        valid_referers none blocked *.ixdba1.net ixdba1.net;  

        if ($invalid_referer) {  

        rewrite ^/ http://www.ixdba.net/img/error.gif;  

        #return 403;  

       }  

        }  

        location /images {  

        root /opt/nginx/html;  

        valid_referers none blocked *.ixdba1.net ixdba1.net;  

        if ($invalid_referer) {  

                   return   403;  

                                }  

                        }  

在上面这段防盗链设置中，分别针对不同文件类型和不同的目录进行了设置，读者可以根据自己的需求进行类似的设定。

“jpg|gif|png|swf|flv|wma|wmv|asf|mp3|mmf|zip|rar”表示对以jpg、gif、png、swf、flv、wma、wmv、asf、mp3、mmf、zip和rar为后缀的文件实行防盗链处理。

“*.ixdba1.net ixdba1.net”表示这个请求可以正常访问上面指定的文件资源。

if{}中的内容的意思是：如果地址不是上面指定的地址就跳转到通过rewrite指定的地址，也可以直接通过return返回403错误。

要做更加复杂的防盗链处理，可以使用Nginx的HttpAccessKeyModule，通过这个模块可以实现功能更强大的防盗链处理，更详细的参考官方文档。

 

四、 日志分割配置实例

Nginx没有类似Apache的cronolog日志分割处理的功能，但是，可以通过nginxNginx的信号控制功能利用脚本来实现日志的自动切割。请看下面的一个实例。

Nginx对日志进行处理的脚本：

 
#/bin/bash  
savepath_log=‘/home/nginx/logs‘ 
nglogs=‘/opt/nginx/logs‘ 
mkdir -p  $savepath_log/$(date +%Y)/$(date +%m)  
mv $nglogs/access.log  $savepath_log/$(date +%Y)/$(date +%m)/access.$(date +%Y%m%d).log  
mv  $nglogs/error.log  $savepath_log/$(date +%Y)/$(date +%m)/error.$(date +%Y%m%d).log  
kill -USR1 `cat /opt/nginx/logs/nginx.pid` 

将这段脚本保存后加入到Linux的crontab守护进程，让此脚本在每天凌晨0点执行，就可以实现日志的每天分割功能了。

其中，变量savepath_log指定分割后的日志存放的路径，而变量nglogs指定Nginx日志文件的存放路径。最后一行，通过Nginx的信号“USR1”实现了日志的自动切换功能。

 

本文出自http://ixdba.blog.51cto.com/2895551/798913