加载中…
版权声明
本博客文章皆系原创,版权所有,保留所有权利。

如需转载,请留言或发邮件至 agentzh@gmail.com 问询。未经同意,擅自使用者,博主保留诉讼权。
个人资料
agentzh
agentzh
  • 博客等级:
  • 博客积分:0
  • 博客访问:165,580
  • 关注人气:353
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
个人简介
OpenResty 应用服务器的缔造者,活跃的 Nginx 第三方开源模块开发者,Nginx 贡献者。关注高性能 Web 应用的构建技术。
评论
加载中…
留言
加载中…
访客
加载中…
博文
标签:

it

分类: Nginx配置指令的执行顺序

    紧跟在 post-access 阶段之后的是 try-files 阶段。这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序。由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下。


    try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对象(文件或者目录),然后检查这些对象是否存在。一旦 Nginx 发现某个文件系统对象存在,就会在 try-files 阶段把当前请求的 URI 改写为该对象所对应的参数 URI(但不会包含末尾的斜杠字符,也不会发生 “内部跳转”)。如果前 N-1 个参数所对应的

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    运行在 post-rewrite 阶段之后的是所谓的 preaccess 阶段。该阶段在 access 阶段之前执行,故名 preaccess.


    标准模块 ngx_limit_reqngx_limit_zone 就运行在此阶段,前者可以控制请求的访问频度,而后者可以限制访问的并发度。这里我们仅仅和它们打个照面,后面还会有机会专门接触到这两个模块。


    前面反复提到的标准模块 ngx_realip 其实也在这个阶段注册了处理程序。有些读者可能会问:“这是为什么呢?它不是已经在 post-read 阶段注册处理程序了吗?”我们不妨通过下面这个例子来揭晓答案:

     
阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

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


    当 Nginx 在 find-config

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    前面我们详细讨论了 rewriteaccesscontent 这三个最为常见的 Nginx 请求处理阶段,在此过程中,也顺便介绍了运行在这三个阶段的众多 Nginx 模块及其配置指令。同时可以看到,请求处理阶段的划分直接影响到了配置指令的执行顺序,熟悉这些阶段对于正确配置不同的 Nginx 模块并实现它们彼此之间的协同工作是非常必要的。所以接下来我们接着讨论余下的那些阶段。


    前面在 (一) 中提到,Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是 post-readserver-rewritefind-configrewritepost-rewritepreaccessaccesspost-accesstry-filescontent 以及 log.


    最先执行的 post-read 阶段在 Nginx 读取并解析完请求头(request headers)之后就立即开始运行。这个阶段像前面介绍过的

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    来看一个 ngx_static 模块服务磁盘文件的例子。我们使用下面这个配置片段:

     location / {
root /var/www/;
}

同时在本机的 /var/www/ 目录下创建两个文件,一个文件叫做 index.html,内容是一行文本 this is my home;另一个文件叫做 hello.html,内容是一行文本 hello world. 同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读。


    现在来通过 HTTP 协议请求一下这两个文件所对应的 URI:

   &
阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

    下面以教程系列为单位,列举出了已经发表和计划发表的连载教程:


  • Nginx 新手起步
  • Nginx 是如何匹配 URI 的
  • Nginx 变量漫谈
  • Nginx 配置指令的执行顺序
  • Nginx 的 if 是邪恶的
  • Nginx 子请求
  • Nginx 静态文件服务
  • Nginx 的日志服务
  • 基于 Nginx 的应用网关
  • 基于 Nginx 的反向代理
  • Nginx 与 Memcached
  • Nginx 与 Redis
  • Nginx 与 MySQL
  • Nginx 与 PostgreSQL
  • 基于 Nginx 的应用缓存
  • Nginx 中的安全与访问控制
  • 基于 Nginx 的 Web Service
  • Nginx 驱动的 Web 2.0 应用
  • 测试 Nginx 及其应用的性能
  • 借助 Nginx 社区的力量

这些系列的名字和最终我的 Nginx 书中的“章”名可以粗略地对应上,但不会等同。同时未发表的系列的名字也可能发生变化,同时实际发

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    前面我们在 (五) 中提到,在一个 location 中使用 content 阶段指令时,通常情况下就是对应的 Nginx 模块注册该 location 中的“内容处理程序”。那么当一个 location 中未使用任何 content 阶段的指令,即没有模块注册“内容处理程序”时,content 阶段会发生什么事情呢?谁又来担负起生成内容和输出响应的重担呢?答案就是那些把当前请求的 URI 映射到文件系统的静态资源服务模块。当存在“内容处理程序”时,这些静态资源服务模块并不会起作用;反之,请求的处理权就会自动落到这些模块上。


    Nginx 一般会在 content 阶段安排三个这样的静态资源服务模块(除非你的 Nginx 在构造时显式禁用了这三个模块中的一个或者多个,又或者启用了这种类型的其他模块)。按照它们在 content 阶段的运行顺序,依次是 ngx_index 模块,

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    Nginx 的 content 阶段是所有请求处理阶段中最为重要的一个,因为运行在这个阶段的配置指令一般都肩负着生成“内容”(content)并输出 HTTP 响应的使命。正因为其重要性,这个阶段的配置指令也异常丰富,例如前面我们一直在示例中广泛使用的 echo 指令,在 Nginx 变量漫谈(二) 中接触到的 echo_exec 指令, Nginx 变量漫谈(三) 中接触到的 proxy_pass 指令,Nginx 变量漫谈(五) 中介绍过的 echo_location 指令,以及

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    ngx_lua 模块提供了配置指令 access_by_lua,用于在 access 请求处理阶段插入用户 Lua 代码。这条指令运行于 access 阶段的末尾,因此总是在 allowdeny 这样的指令之后运行,虽然它们同属 access 阶段。一般我们通过 access_by_luangx_access 这样的模块检查过客户端 IP 地址之后,再通过 Lua 代码执行一系列更为复杂的请求验证操作,比如实时查询数据库或者其他后端服务,以验证当前用户的身份或权限。


    我们来看一个简单的例子,利用

阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
标签:

it

分类: Nginx配置指令的执行顺序

    如前文所述,除非像 ngx_set_misc 模块那样使用特殊技术,其他模块的配置指令即使是在 rewrite 阶段运行,也不能和 ngx_rewrite 模块的指令混合使用。不妨来看几个这样的例子。


    第三方模块 ngx_headers_more 提供了一系列配置指令,用于操纵当前请求的请求头和响应头。其中有一条名叫 more_set_input_headers 的指令可以在 rewrite 阶段改写指定的请求头(或者在请求头不存在时自动创建)。这条指令总是运行在 rewrite 阶段的末尾,该指令的文档中有这么一行标记:

     phase: rewrite tail 
阅读  ┆ 评论  ┆ 转载 ┆ 收藏 
  

新浪BLOG意见反馈留言板 不良信息反馈 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有