NGINX openrestry(指令的执行顺序)

Nginx的指令的执行顺序:

一、post-read

二、server-rewrite

  ngx_rewrite模块的set指令和rewrite指令(前提在server里面配置时)

三、find-config

四、rewrite

  ngx_rewrite模块的set指令和rewrite指令(前提在location里面配置时)

  ngx_set_misc模块的set_unescape_uri指令

  ngx_lua模块的set_by_lua指令

  rewrite tail:

  ngx_headers_more模块的more_set_input_headers指令

  ngx_lua模块的rewrite_by_lua指令

五、post-rewrite

六、preaccess

七、access

  ngx_access模块的allow指令和deny指令(多个指令会按顺序进行执行)

  如果首先匹配的指令是 allow,则会继续执行后续其他模块的指令或者跳到后续的处理阶段;而如果首先满足的是 deny 则会立即中止当前整个请求的处理,并立即返回 403 错误页。

  access tail:

  ngx_lua模块的access_by_lua指令

  tips:指令中return表示该指令就是,继续执行后续的指令。

  tips:ngx_lua模块的ngx.exit(403)函数,直接结束整个请求处理过程,返回403页面。

八、post-access

九、try-files

十、content阶段:

  这个阶段的这么多的指令只能有一种胜出。每一个location只能有一个内容处理程序。

  执行的顺序是:如果1里面有就从里面选择一个执行,如果1里面没有就让2执行,如果2没有或者处理不了就让3执行,如果3没有或者处理不了就让4执行。

1、ngx_echo模块的echo指令、echo_exec指令、echo_location指令

  ngx_proxy模块的proxy_pass指令

  ngx_lua模块的content_by_lua指令

  用一种指令有的可以写几次,比如echo。

location /test {
  echo hello;
  echo world;
}

  ngx_lua模块的ngx.say函数和ngx_echo模块的echo函数是一样的

location /test {
  content_by_lua ‘ngx.say("hello") ngx.say("world")‘;
}

2、ngx_index模块的index指令:

  处理以‘/‘结尾的请求

location / {
  root /var/www/;
  index index.htm index.html;
}

  当用户请求‘/‘地址时,Nginx会自动在/var/www/index.htm目录下寻找这个文件,如果找到,则直接发起内部跳转到新的‘/index.html‘这个新的地址,如果不存在,则继续找/var/www/index.html这个文件,如果找得到,则直接发起内部跳转到‘/index.html‘这个地址,如果不存在,就交给后续的模块进行处理,如果都处理不了,就报403的错误。

内部跳转:

  ngx_index模块的index指令

  echo模块的echo_exec指令

  ngx_rewrite模块的rewrite指令

3、ngx_autoindex模块的autoindex指令:

  处理以‘/‘结尾的请求

  自动生成目录索引页

location / {
root /var/www/;
index index.html;
autoindex on;
}

  当请求到来时,当/var/www/index.html的页面不存在时,会显示/var/www/下的文件目录列表;当index.html的存在时,会优先执行ngx_index模块的index指令,直接发生内部跳转。

4、ngx_static模块的静态资源指令:

  处理不以‘/‘结尾的网页

  专门用来处理和输出静态资源内容的

location / {
}

  因为没有配置 root 指令,所以在访问这个接口时,Nginx 会自动计算出一个缺省的“文档根目录”。该缺省值是取所谓的“配置前缀 prefix路径下的 html/ 子目录。举一个例子,假设配置前缀是 /foo/bar/,则缺省的“文档根目录”便是 /foo/bar/html/。

  当静态资源找不到时会出现404错误。404是指静态资源找不到,而并非location找不到。

十一、log

http头部

输出过滤器

内部跳转

原文地址:https://www.cnblogs.com/erdanyang/p/10771753.html

时间: 2024-10-09 16:17:07

NGINX openrestry(指令的执行顺序)的相关文章

Nginx 配置指令的执行顺序(八)

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

Nginx 配置指令的执行顺序(一)

大多数 Nginx 新手都会频繁遇到这样一个困惑,那就是当同一个 location 配置块使用了多个 Nginx 模块的配置指令时,这些指令的执行顺序很可能会跟它们的书写顺序大相径庭.于是许多人选择了“试错法”,然后他们的配置文件就时常被改得一片狼藉.这个系列的教程就旨在帮助读者逐步地理解这些配置指令背后的执行时间和先后顺序的奥秘. 现在就来看这样一个令人困惑的例子:     ? location /test {    ?     set $a 32;    ?     echo $a;    

Nginx 配置指令的执行顺序(二)

我们前面已经知道,当 set 指令用在 location 配置块中时,都是在当前请求的 rewrite 阶段运行的.事实上,在此上下文中,ngx_rewrite 模块中的几乎全部指令,都运行在 rewrite 阶段,包括 Nginx 变量漫谈(二) 中介绍过的 rewrite 指令.不过,值得一提的是,当这些指令使用在 server 配置块中时,则会运行在一个我们尚未提及的更早的处理阶段,server-rewrite 阶段. Nginx 变量漫谈(二) 中介绍过的 ngx_set_misc 模块

Nginx 配置指令的执行顺序(十一)

紧跟在 post-access 阶段之后的是 try-files 阶段.这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序.由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下. try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对象(文件或者

Nginx 配置指令的执行顺序(七)

来看一个 ngx_static 模块服务磁盘文件的例子.我们使用下面这个配置片段:     location / {        root /var/www/;    } 同时在本机的 /var/www/ 目录下创建两个文件,一个文件叫做 index.html,内容是一行文本 this is my home:另一个文件叫做 hello.html,内容是一行文本 hello world. 同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读. 现在来通过

nginx与Lua执行顺序

Nginx顺序 Nginx 处理每一个用户请求时,都是按照若干个不同阶段(phase)依次处理的,而不是根据配置文件上的顺序. Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是 post-read.server-rewrite.find-config.rewrite.post-rewrite. preaccess.access.post-access.try-files.content.log. post-read: 读取请求内容阶段 Nginx读取并解析完请求头之后就立即

nginx开发笔记_Filter模块执行顺序

Filter模块执行顺序 Filter模块的执行顺序是在执行configure文件时决定的,configure文件执行完成后生成objs/ngx_modules.c,文件中定义了一个数组ngx_module_t *ngx_modules[],数组的顺序就是模块执行顺序的逆序. 一般而言,在模块的config文件中配置ngx_module_type为HTTP_FILTER后生成的默认执行顺序在ngx_http_copy_filter_module之后. 一个典型的ngx_module_t *ngx

Nginx 配置指令location 匹配符优先级和安全问题【转】

Nginx配置指令location匹配符优先级和安全问题 使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可.特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来.配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload.服务器没有任何宕机情况下,实现平稳修改配置.最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全隐患哦),以下是个人学习一

finally,return 的执行顺序

参考:http://blog.csdn.net/qj19842011/article/details/45675057 关于finally,return的执行顺序 例子:  try{     return expression; }finally{    do some work; } 1.执行:expression,计算该表达式,结果保存在操作数栈顶: 2.执行:操作数栈顶值(expression的结果)复制到局部变量区作为返回值: 3.执行:finally语句块中的代码: 4.执行:将第2步