Nginx处理请求的11个阶段（agentzh的Nginx 教程学习记录）

Nginx 处理请求的过程一共划分为 11 个阶段，按照执行顺序依次是 post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、try-files、content 以及 log。

一、post-read

最早执行的 post-read 阶段在 Nginx 读取并解析完请求头（request headers）以后就当即开始运行。例如：使用了  ngx_realip 模块提供的  set_real_ip_from 和  real_ip_header 这两条配置指令

二、server-rewrite

因为 server-rewrite 阶段位于 post-read 阶段以后，因此 server 配置块中的  set 指令也就老是运行在  ngx_realip 模块改写请求的来源地址以后。

三、find-config

这个阶段并不支持 Nginx 模块注册处理程序，而是由 Nginx 核心来完成当前请求与 location 配置块之间的配对工做。换句话说，在此阶段以前，请求并无与任何 location 配置块相关联。所以，对于运行在 find-config 阶段以前的 post-read 和 server-rewrite 阶段来讲，只有 server 配置块以及更外层做用域中的配置指令才会起做用。这就是为何只有写在 server 配置块中的  ngx_rewrite 模块的指令才会运行在 server-rewrite 阶段，这也是为何前面全部例子中的  ngx_realip 模块的指令也都特地写在了 server 配置块中，以确保其注册在 post-read 阶段的处理程序可以生效。

四、rewrite

因为 Nginx 已经在 find-config 阶段完成了当前请求与 location 的配对，因此从 rewrite 阶段开始，location 配置块中的指令即可以产生做用。当  ngx_rewrite 模块的指令用于 location 块中时，即是运行在这个 rewrite 阶段。

五、post-rewrite

这个阶段也像 find-config 阶段那样不接受 Nginx 模块注册处理程序，而是由 Nginx 核心完成 rewrite 阶段所要求的“内部跳转”操做（若是 rewrite 阶段有此要求的话）。例如：经过  rewrite 指令把当前请求的 URI 无条件地改写为 /bar，同时发起一个“内部跳转”，最终跳进了 location /bar 中。这里比较有趣的地方是“内部跳转”的工做原理。“内部跳转”本质上其实就是把当前的请求处理阶段强行倒退到 find-config 阶段，以便从新进行请求 URI 与 location 配置块的配对。

六、preaccess

该阶段在 access 阶段以前执行，故名 preaccess.标准模块  ngx_limit_req 和  ngx_limit_zone 就运行在此阶段，前者能够控制请求的访问频度，然后者能够限制访问的并发度。

七、access

标准模块  ngx_access、第三方模块  ngx_auth_request 以及第三方模块  ngx_lua 的  access_by_lua 指令就运行在这个阶段。

八、 post-access

这个阶段也和 post-rewrite 阶段相似，并不支持 Nginx 模块注册处理程序，而是由 Nginx 核心本身完成一些处理工做。post-access 阶段主要用于配合 access 阶段实现标准  ngx_http_core 模块提供的配置指令  satisfy 的功能。对于多个 Nginx 模块注册在 access 阶段的处理程序，  satisfy 配置指令能够用于控制它们彼此之间的协做方式。好比模块 A 和 B 都在 access 阶段注册了与访问控制相关的处理程序，那就有两种协做方式，一是模块 A 和模块 B 都得经过验证才算经过，二是模块 A 和模块 B 只要其中任一个经过验证就算经过。第一种协做方式称为 all 方式（或者说“与关系”），第二种方式则被称为 any 方式（或者说“或关系”）。默认状况下，Nginx 使用的是 all 方式。

九、try-files

这个阶段专门用于实现标准配置指令  try_files 的功能，并不支持 Nginx 模块注册处理程序。 try_files 指令接受两个以上任意数量的参数，每一个参数都指定了一个 URI. 这里假设配置了 N 个参数，则 Nginx 会在 try-files 阶段，依次把前 N-1 个参数映射为文件系统上的对象（文件或者目录），而后检查这些对象是否存在。一旦 Nginx 发现某个文件系统对象存在，就会在 try-files 阶段把当前请求的 URI 改写为该对象所对应的参数 URI（但不会包含末尾的斜杠字符，也不会发生 “内部跳转”）。若是前 N-1 个参数所对应的文件系统对象都不存在，try-files 阶段就会当即发起“内部跳转”到最后一个参数（即第 N 个参数）所指定的 URI.经过  root 配置指令所指定的“文档根目录”进行映射。例如，当“文档根目录”是 /var/www/ 的时候，请求 URI /foo/bar 会被映射为文件 /var/www/foo/bar，而请求 URI /foo/baz/ 则会被映射为目录 /var/www/foo/baz/. 注意这里是如何经过 URI 末尾的斜杠字符是否存在来区分“目录”和“文件”的。

十、content

Nginx 的 content 阶段是全部请求处理阶段中最为重要的一个，由于运行在这个阶段的配置指令通常都肩负着生成“内容”（content）并输出 HTTP 响应的使命。正由于其重要性，这个阶段的配置指令也异常丰富。echo、  Nginx 变量漫谈（二） 中接触到的  echo_exec 指令，  Nginx 变量漫谈（三） 中接触到的  proxy_pass 指令， Nginx 变量漫谈（五） 中介绍过的  echo_location 指令，以及  Nginx 变量漫谈（七） 中介绍过的  content_by_lua。

十一、log

log阶段处理，好比记录访问量/统计平均响应时间。log_by_lua

 

参考资料： https://openresty.org/download/agentzh-nginx-tutorials-zhcn.html