标签:
it |
分类: Nginx配置指令的执行顺序 |
post-access
阶段之后的是
try-files
阶段。这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序。由于 try_files 指令在许多 FastCGI
应用的配置中都有用到,所以我们不妨在这里简单介绍一下。
N
个参数,则 Nginx 会在 try-files
阶段,依次把前 N-1
个参数映射为文件系统上的对象(文件或者目录),然后检查这些对象是否存在。一旦
Nginx 发现某个文件系统对象存在,就会在 try-files
阶段把当前请求的 URI
改写为该对象所对应的参数 URI(但不会包含末尾的斜杠字符,也不会发生 “内部跳转”)。如果前 N-1
个参数所对应的
标签:
it |
分类: Nginx配置指令的执行顺序 |
post-rewrite
阶段之后的是所谓的
preaccess
阶段。该阶段在 access
阶段之前执行,故名
preaccess
.
post-read
阶段注册处理程序了吗?”我们不妨通过下面这个例子来揭晓答案:
标签:
it |
分类: Nginx配置指令的执行顺序 |
server-rewrite
阶段后边的是
find-config
阶段。这个阶段并不支持 Nginx 模块注册处理程序,而是由 Nginx
核心来完成当前请求与 location
配置块之间的配对工作。换句话说,在此阶段之前,请求并没有与任何
location
配置块相关联。因此,对于运行在 find-config
阶段之前的 post-read
和 server-rewrite
阶段来说,只有
server
配置块以及更外层作用域中的配置指令才会起作用。这就是为什么只有写在
server
配置块中的 ngx_rewrite
模块的指令才会运行在 server-rewrite
阶段,这也是为什么前面所有例子中的 ngx_realip
模块的指令也都特意写在了 server
配置块中,以确保其注册在
post-read
阶段的处理程序能够生效。
find-config
标签:
it |
分类: Nginx配置指令的执行顺序 |
rewrite
、access
和 content
这三个最为常见的 Nginx
请求处理阶段,在此过程中,也顺便介绍了运行在这三个阶段的众多 Nginx
模块及其配置指令。同时可以看到,请求处理阶段的划分直接影响到了配置指令的执行顺序,熟悉这些阶段对于正确配置不同的 Nginx
模块并实现它们彼此之间的协同工作是非常必要的。所以接下来我们接着讨论余下的那些阶段。
post-read
、server-rewrite
、find-config
、rewrite
、post-rewrite
、preaccess
、access
、post-access
、try-files
、content
以及 log
.
post-read
阶段在 Nginx
读取并解析完请求头(request headers)之后就立即开始运行。这个阶段像前面介绍过的
标签:
it |
分类: Nginx配置指令的执行顺序 |
ngx_static
模块服务磁盘文件的例子。我们使用下面这个配置片段:
同时在本机的 /var/www/
目录下创建两个文件,一个文件叫做
index.html
,内容是一行文本
this
;另一个文件叫做
hello.html
,内容是一行文本 hello
.
同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读。
&
标签:
it |
这些系列的名字和最终我的 Nginx 书中的“章”名可以粗略地对应上,但不会等同。同时未发表的系列的名字也可能发生变化,同时实际发
标签:
it |
分类: Nginx配置指令的执行顺序 |
location
中使用 content
阶段指令时,通常情况下就是对应的 Nginx 模块注册该 location
中的“内容处理程序”。那么当一个
location
中未使用任何 content
阶段的指令,即没有模块注册“内容处理程序”时,content
阶段会发生什么事情呢?谁又来担负起生成内容和输出响应的重担呢?答案就是那些把当前请求的 URI
映射到文件系统的静态资源服务模块。当存在“内容处理程序”时,这些静态资源服务模块并不会起作用;反之,请求的处理权就会自动落到这些模块上。
content
阶段安排三个这样的静态资源服务模块(除非你的 Nginx
在构造时显式禁用了这三个模块中的一个或者多个,又或者启用了这种类型的其他模块)。按照它们在 content
阶段的运行顺序,依次是 ngx_index 模块,
标签:
it |
分类: Nginx配置指令的执行顺序 |
content
阶段是所有请求处理阶段中最为重要的一个,因为运行在这个阶段的配置指令一般都肩负着生成“内容”(content)并输出 HTTP
响应的使命。正因为其重要性,这个阶段的配置指令也异常丰富,例如前面我们一直在示例中广泛使用的 echo 指令,在 Nginx
变量漫谈(二) 中接触到的 echo_exec 指令, Nginx
变量漫谈(三) 中接触到的 proxy_pass 指令,Nginx
变量漫谈(五) 中介绍过的 echo_location 指令,以及
标签:
it |
分类: Nginx配置指令的执行顺序 |
access
请求处理阶段插入用户 Lua 代码。这条指令运行于 access
阶段的末尾,因此总是在 allow 和
deny
这样的指令之后运行,虽然它们同属 access
阶段。一般我们通过 access_by_lua
在 ngx_access 这样的模块检查过客户端
IP 地址之后,再通过 Lua
代码执行一系列更为复杂的请求验证操作,比如实时查询数据库或者其他后端服务,以验证当前用户的身份或权限。
标签:
it |
分类: Nginx配置指令的执行顺序 |
rewrite
阶段运行,也不能和 ngx_rewrite 模块的指令混合使用。不妨来看几个这样的例子。
rewrite
阶段改写指定的请求头(或者在请求头不存在时自动创建)。这条指令总是运行在
rewrite
阶段的末尾,该指令的文档中有这么一行标记:
phase: rewrite tail