主要还是 Nginx 的执行阶段知识了,都是因为 OR 才会那么深刻, 它有些自己的阶段。
主要还是参照 春哥的 Nginx 教程 请多读几遍,如果不清楚nginx的执行阶段就无法充分利用 openresty 提供的强大功能。
罗列
从上到下的顺序执行每个阶段。
NGX_HTTP_POST_READ_PHASE:
#读取请求内容阶段
NGX_HTTP_SERVER_REWRITE_PHASE:
#Server请求地址重写阶段
NGX_HTTP_FIND_CONFIG_PHASE:
#配置查找阶段:
NGX_HTTP_REWRITE_PHASE:
#Location请求地址重写阶段,常用
NGX_HTTP_POST_REWRITE_PHASE:
#请求地址重写提交阶段
NGX_HTTP_PREACCESS_PHASE:
#访问权限检查准备阶段
NGX_HTTP_ACCESS_PHASE:
#访问权限检查阶段,常用
NGX_HTTP_POST_ACCESS_PHASE:
#访问权限检查提交阶段
NGX_HTTP_TRY_FILES_PHASE:
#配置项try_files处理阶段
NGX_HTTP_CONTENT_PHASE:
#内容产生阶段 最常用
NGX_HTTP_LOG_PHASE:
#日志模块处理阶段 常用
OpenResty 结合指令的阶段概念
解释
下面是一些笔记, 有些阶段是支持 Nginx 模块注册处理程序
,有些阶段并不可以。Nginx 的conf中指令的书写顺序和执行顺序是两码事,切记
。 有些指令虽然在同一个阶段,执行的顺序也可能是无法预测的,使用之前请认真阅读文档和测试。
最常用的是 rewrite
阶段,access
阶段 以及 content
阶段,不支持 Nginx 模块注册处理程序
的阶段 find-config
, post-rewrite
, post-access
, 主要是 Nginx 核心完成自己的一些逻辑。
rewrite
这个阶段常用来改写 url等
-
set
,set_unescape_uri
,set_by_lua
这几条指令会依次按照书写的顺序执行 -
rewrite_by_lua
指令运行在 rewrite 阶段的末尾
标准 ngx_rewrite 模块的应用是如此广泛,所以能够和它的配置指令混合使用的第三方模块是幸运的。事实上,上面提到的这些第三方模块都采用了特殊的技术,将它们自己的配置指令“注入”到了 ngx_rewrite 模块的指令序列中(它们都借助了 Marcus Clyne 编写的第三方模块 ngx_devel_kit)。换句话说,更多常规的在 Nginx 的 rewrite 阶段注册和运行指令的第三方模块就没那么幸运了。这些“常规模块”的指令虽然也运行在 rewrite 阶段,但其配置指令和 ngx_rewrite 模块(以及同一阶段内的其他模块)都是分开独立执行的。在运行时,不同模块的配置指令集之间的先后顺序一般是不确定的(严格来说,一般是由模块的加载顺序决定的,但也有例外的情况)。比如 A 和 B 两个模块都在 rewrite 阶段运行指令,于是要么是 A 模块的所有指令全部执行完再执行 B 模块的那些指令,要么就是反过来,把 B 的指令全部执行完,再去运行 A 的指令。除非模块的文档中有明确的交待,否则用户一般不应编写依赖于此种不确定顺序的配置。
在单个请求处理阶段内部,一般也会以 Nginx 模块为单位进一步地划分出内部子阶段
access
这个阶段常用来做权限验证
-
allow
和deny
指令 -
access_by_lua
指令运行在 access 阶段末位
content
这个阶段是产生响应内容的阶段,最常用的阶段。
-
content_by_lua
如果使用这个命令,就无法在进行proxy_pass
了 -
echo
指令
每一个 location 只能有一个“内容处理程序”,因此,当在 location 中同时使用多个模块的 content 阶段指令时,只有其中一个模块能成功注册“内容处理程序”
post-read
最先执行的 post-read 阶段在 Nginx 读取并解析完请求头(request headers)之后就立即开始运行
-
ngx_realip
模块
server-rewrite
- 写在 server 块中的
set
指令
preaccess
-
ngx_limit_req
模块 -
ngx_limit_zone
模块
输出过滤器
不属于11个阶段中,可以对输出内容进行改写
- echo 模块的指令
echo_before_body
和echo_after_body
可以对 content 阶段产生响应体
进行改写