Nginx 的 11 个执行阶段详解

很多运维在配置 nginx 过程中,会遇到很多不理解的问题,那是因为对 nginx 执行的过程了解不够深入,今天带大叫了脚下 nginx 的 11 个执行阶段

在了解 nginx 的执行阶段前,先看一个例子

对 echo 不熟悉的,可以先看文章Nginx调试必备了解下 echo 扩展

回到上面这个例子,在 server 块中配置这样的 location,你觉得输出是什么样子?

按照正常的逻辑,输出应该是 32 56,我们请求下,看下 nginx 处理的结果

两次输出都是 56,颠覆认知。这就是因为 set 和 echo 处在 nginx 不同的执行阶段,在 nginx 中,处在不同阶段的配置,和配置文件顺序没有任何关系

Nginx 处理请求过程总共划分为 11 个阶段,按顺序依次是 post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、precontent、content 以及 log

看一下 nginx 源码中的定义,在 http/ngx_http_core_module.h 中

我这里是 1.17.7 版本的 nginx,我看了 nginx1.16.0 版本一样,老一点的版本内容预处理阶段是 try_files 阶段

下面结合测试详细说一下每个阶段

post-read 阶段

该阶段是 nginx 接收完请求头之后的第一个阶段,它位于 uri 重写之前,该阶段很少用,很少有模块会注册在该阶段,默认情况下,该阶段被跳过,但是有个两个标准函数是注册在这个阶段的,set_real_ip_from、real_ip_header

看到 real_ip 有没有很熟悉,通常 nginx 日志或者后端需要获取客户端真实 IP 的时候,需要把 cdn 或者你前端的 nginx 或者代理的 ip 改写之后来获取,就会用到这个,下面看例子

通过 curl -H 添加 header 头请求,然后查看结果

通常多级代理,后端要获取真实 IP 就是通过这种自定义 header 的方式去获取

server-rewrite 阶段

该阶段是 server 级别的 uri 重写阶段,该阶段执行处于 server 块内,location 块外的重写指令,在读取请求头的过程中 nginx 会根据 host 及端口找到对应的虚拟主机配置

该阶段不只是执行 rewrite 指令,通常该阶段包含标准函数 ngx_rewrite、set,看例子

这里在 server 块内,location 块外 set 一个变量 $a,在 location 中引用,因为 server-rewrite 阶段在前面,所以 $a 变量会先赋值,查看结果

find-config 阶段

该阶段是寻找 location 配置阶段,该阶段使用重写之后的 uri 来查找对应的 location,如果匹配到的 location 中有重写指令的话,该阶段会再次执行,直到匹配到最终的 location

这个阶段的匹配工作是由 nginx 核心模块来完成的,并不支持 nginx 模块注册处理程序

这个阶段不太好整例子,想来想去没有想到可以体现的例子,但是 debug 日志可以体现,用上一个阶段的例子的请求日志看下

很直观,在执行完上个阶段的 set $a 之后,就开始匹配 location,最终匹配到 test,接着执行下面的阶段

rewrite 阶段

该阶段是 location 级别的 uri 重写阶段,该阶段执行 location 基本的重写指令,同样也可能被指定多次

直接写个跳转看日志

通过 curl -L 跟随跳转请求看下结果

查看 debug 日志

仍然是先执行 server 块内的 set,之后匹配到 rewrite 的 location,然后执行 location 内的 rewrite

post-rewrite 阶段

该阶段是 location 级别重写的后一个阶段,用来检查上阶段是否有 uri 重写,并根据结果跳转到合适的阶段

这个阶段紧接上一个阶段,是由 nginx 核心完成 rewrite 阶段所要求的跳转,即内部跳转

内部跳转本质上其实就是把当前的请求处理阶段跳回到 find-config 阶段,类似于条件分支循环,这也就是上面说到 find-config 阶段会被多次执行的原因。把上阶段的 rewrite 请求跳转到 find-config 阶段,重新进行请求 uri 和 location 配置块的配对,这个过程可以从上面阶段的后续 debug 日志可以看出来

rewrite 被改写到 test,然后开始重新匹配 uri 为 test 的 location

接着执行 find-config 阶段的匹配过程,然后执行后面的阶段

preaccess 阶段

该阶段是访问权限控制的前一阶段,预控制阶段。该阶段在权限控制阶段之前,一般也用于访问控制,比如 limit 的限制速率、限制连接数等

该阶段包含的标准函数 ngx_limit_req、ngx_limit_zone 等

实例结合后面的下个阶段一起看

access 阶段

该阶段是权限访问控制阶段,比如基于 IP 黑白名单的权限控制,基于用户名密码的权限控制等

该阶段包含的标准函数 ngx_access、ngx_auth_request 函数等

结合 preaccess,我们在同一个 location 中配置 limit 和 access,如下

然后请求 access 看下结果

看下 debug 日志,分析处理阶段

先处理 limit,然后接着处理 access 部分

post-access 阶段

该阶段是访问控制的后一阶段,和 post-rewrite 阶段类似,不支持 nginx 模块注册处理程序,由 nginx 核心自己完成处理工作,主要是配合 access 阶段实现后续处理

这里常用的指令是 satisfy,它的功能类似 if 判断中的“与”、“或”关系,在 access 阶段可以注册多个 nginx 模块,比如上面提到的 access 模块和 auth 认证模块,如果两个模块都注册了,那么是执行哪个?按哪个匹配结果来执行,这个时候就用到 satisfy,它就是让多个控制之间彼此协作

比如上面两个模块都在 access 阶段注册了与访问控制相关的处理程序,那就有两种协作方式,一是模块 access 和 auth 都通过验证才算通过,另外一种是只要其中任一通过验证就算通过。第一种方式为 all 方式,也就是“与”关系,第二种方式为 any 方式,也就是“或”关系,默认情况下 nginx 使用的是 all 方式

precontent 阶段

该阶段为生成内容的前一阶段,主要是用于处理 try_files 指令的配置,如果没有配置 try_files 指令,这个阶段会跳过,该阶段不支持 nginx 模块注册处理程序

try_files 指令接受两个以上任意数量的参数,每个参数都指定一个 uri,比如设置 N 个参数,nginx 会在 precontent 阶段依次把前 N-1 个参数映射为文件系统上的文件或目录,逐个检查这些文件或目录是否存在。一旦 Nginx 匹配到某个文件或目录存在,就会在 precontent 阶段,把当前请求的 uri 改写为该对象所对应的参数 uri,如果前 N-1 个参数所对应的文件或目录都不存在,则 precontent 阶段会发起内部跳转,按照最后一个参数所指定的 uri 进行 find-config 阶段

配置个 try_files 来看下执行过程

请求 try,看下结果

并没有执行 echo uri 部分,而是到 test 的 location 了,看下 debug 日志

可以看到和我们上面说的结果一致

content 阶段

该阶段是所有阶段中最重要的一个阶段,该阶段负责内容生成,并输出 http 响应。通过 nginx 配置文件中的配置指令,生成响应内容,返回给客户端,这个阶段的配置指令例如 echo、proxy_pass 等

日志体现该阶段

log 阶段

该阶段就是日志记录阶段,根据 log 配置写入日志文件,比如 log 级别,日志格式 logformat 等,包含 nginx 的 access_log 和 error_log 等

在 debug 日志中也有记录

请求返回给客户端后,记录日志,然后保持 keepalive,如果是不需要 keepalive 的时候,直接 close 连接

以上就是 nginx 处理请求的 11 个阶段,熟悉之后,对 nginx 的了解更深

本文作者: InfoQ

余下全文(1/3)
分享这篇文章:

请关注我们:

共有 1 条讨论

  1. admin  这篇文章, 并对这篇文章的反应是俺的神呀赞一个

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注