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

1. http 请求 11 个处理阶段介绍

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

typedef enum {    NGX_HTTP_POST_READ_PHASE = 0,       NGX_HTTP_SERVER_REWRITE_PHASE,      NGX_HTTP_FIND_CONFIG_PHASE,         NGX_HTTP_REWRITE_PHASE,             NGX_HTTP_POST_REWRITE_PHASE,        NGX_HTTP_PREACCESS_PHASE,           NGX_HTTP_ACCESS_PHASE,              NGX_HTTP_POST_ACCESS_PHASE,         NGX_HTTP_TRY_FILES_PHASE,           NGX_HTTP_CONTENT_PHASE,             NGX_HTTP_LOG_PHASE              } ngx_http_phases;

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

1.1 POST_READ 阶段

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

1.2 SERVER_REWRITE 和 REWRITE 阶段

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

1.3 FIND_CONFIG 阶段

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

1.4 PREACCESS、ACCESS 和 POST_ACCESS 阶段

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

1.5 TRY_FILES 阶段

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

1.6 CONTENT

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

1.7 LOG 阶段

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

Tips: 所有的 Http请求必须都是从上到下，一个接一个阶段执行的。

2. realip 模块

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

   set_real_ip_from 10.10.10.10;   # real_ip_recursive off;   real_ip_recursive on;   real_ip_header X-Forwarded-For;

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。

3. rewrite 模块

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

3.1 return 指令

Syntax: return code [text];# return code URL;# return URL;Default: —Context: server, location, if

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

return 200 "hello, world"

Syntax:  rewrite regex replacement [flag];Default: --Context: server, location, if

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

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

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

last: 用 replacement 这个 url 进行新的 location 匹配break: break 指令停止当前脚本指令的执行redirect：返回 302 重定向permanent: 返回 301 重定向3.3 if 指令

Syntax:  if (condition) { ... }Default: —Context: server, location

if 指令的条件表达式:

检查变量是否为空或者为 0将变量与字符串做匹配，使用 = 或者 !=将变量与正则表达式做匹配:~ 或者 !~ 大小写敏感~* 或者 !~* 大小写不敏感检查文件是否存在 -f 或者 !-f检查目录是否存在 -d 或者 !-d检查文件、目录、软链接是否存在 -e !-e是否为可执行文件 -x 或者 !-x实例

if ($request_medthod = POST){   return 405;}if($invalid_refer){   return 403;}

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

4.1 location 匹配规则

规则

匹配

=

严格匹配。如果请求匹配这个 location，那么将停止搜索并立即处理此请求

~

区分大小写匹配(可用正则表达式)

~*

不区分大小写匹配(可用正则表达式)

!~

区分大小写不匹配

!~*

不区分大小写不匹配

^~

前缀匹配

@

“@” 定义一个命名的location，使用在内部定向时

/

通用匹配，任何请求都会匹配到

4.2 location 匹配顺序“=” 精准匹配，如果匹配成功，则停止其他匹配普通字符串指令匹配，优先级是从长到短(匹配字符越多，则选择该匹配结果)。匹配成功的location如果使用^~，则停止其他匹配（正则匹配）正则表达式指令匹配，按照配置文件里的顺序(从上到下)，成功就停止其他匹配如果正则匹配成功，使用该结果;否则使用普通字符串匹配结果

有一个简单总结如下：

(location =) > (location 完整路径) > (location ^~ 路径) > (location ,* 正则顺序) > (location 部分起始路径) > (location /)

即：

(精确匹配）> (最长字符串匹配，但完全匹配) >（非正则匹配）>（正则匹配）>（最长字符串匹配，不完全匹配）>（location通配）

5. 实验5.1 realip 模块使用

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

server {    listen 8007;    server_name localhost;    set_real_ip_from 218.19.206.164;    real_ip_recursive off;    # real_ip_recursive on;    real_ip_header X-Forwarded-For;    location / {       return 200 "client real ip： $remote_addr\n";    }}

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

$ curl -H "X-Forwarded-For: 1.1.1.1,218.19.206.164" http://主机ip:8007 client real ip： 218.19.206.164  

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

$ ./nginx -s reload$ curl -H "X-Forwarded-For: 1.1.1.1,218.19.206.164" http://主机ip:8007  client real ip： 1.1.1.1

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

server {    server_name return_and_if.test.com;    listen 8008;    root html;    # 404错误跳转到403.html页面，根路径由root指令指定    error_page 404 /403.html;    # return 405 '405 Not Allowed!\n';    location / {       if ( $request_method = POST ) {          return 200 "Post Request!\n";       }    }}

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

$ curl -XPOST   Post Request!$ curl   403, forbidden!

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

$ curl   405 Not Allowed!

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

server {   server_name rewrite.test.com;   listen 8009;   # 打开rewrite日志，可以看到对应的rewrite结果   rewrite_log on;   error_log logs/rewrite_error.log notice;   root /root/test/;   location /first {      rewrite /first/(.*) /second/$1 last;      return 200 'first!';   }   location /second {      rewrite /second/(.*) /third/$1 break;      # rewrite /second/(.*) /third/$1;      return 200 'second!';   }     location /third {      return 200 'third!';   }}

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

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

$ curl http://主机ip:8009/first/3.txt hello, world

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

$ curl http://主机ip:8009/first/3.txt second!

首先是 /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!'字符串。

5.4 location 匹配

server {   server_name location.test.com;   listen 8010;   location = / {        return 200 "精确匹配/";   }   location ~* /ma.*ch {      return 200 "正则匹配/ma.*ch";   }   location ~ /mat.*ch {      return 200 "正则匹配/match.*";   }   location = /test {      return 200 "精确匹配/test";   }   location ^~ /test/ {      return 200 "前缀匹配/test";   }   location ~ /test/he*o {      return 200 "正则匹配/test/he*o";   }   location / {        return 200 "通配/";   }}

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

# 精确匹配优先级最高$ curl 精确匹配/$ curl  精确匹配/test# 前缀匹配优先级高于正则匹配$ curl  前缀匹配/test# 正则匹配，按照顺序依次匹配，如果同时匹配两个正则，则前面的优先匹配$ curl  正则匹配/ma.*ch# 什么都匹配不到时，最后匹配通配/$ curl  通配/

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