nginx 11个阶段

POST_READ
SERVER_REWRITE
FIND_CONFIG
REWIRTE
POST_REWIRITE
PRE_ACCESS
ACCESS
POST_ACCESS
PRECONTENT
CONTENT
LOG

 

 

 POST_READ

该阶段是在Nginx读取并解析完请求头（request headers）之后就立即开始执行的

readip  x_forward_for module 

当 remote_addr ip为以下网段时进行 realip设置
set_real_ip_from  192.168.1.0/24;   
set_real_ip_from  192.168.2.1;
set_real_ip_from  2001:0db8::/32;


real_ip_header    X-Forwarded-For;
real_ip_recursive on;  控制是否有访问ip链条的生成。

[root@node3 nginx]# curl 192.168.122.13 -H 'X-Forwarded-For: 101.10.10.10,192.168.122.13' -H 'Host: zz.com.cn'
real ip is 101.10.10.10 
[root@node3 nginx]# !cat 
cat vhost/realip.conf 
server {
   listen 80;
   server_name zz.com.cn;
   set_real_ip_from 192.168.122.13;
   real_ip_header X-Forwarded-For;
   real_ip_recursive  on;
   
   location / {
     return 200 "real ip is $remote_addr \n";
   }

}

[root@node3 nginx]# curl 192.168.122.13 -H 'X-Forwarded-For: 101.10.10.10,192.168.122.13' -H 'Host: zz.com.cn'
real ip is 101.10.10.10 

 

 

server_rewrite

return

error_page

rewrite

break

set

rewrite_log

[root@node3 vhost]# ls
realip.conf  server_rewrite.conf
[root@node3 vhost]# cat server_rewrite.conf 
server {
   listen 80;
   server_name rewrite.com.cn;
      
   return 403 'server return \n ';  server阶段的 rewrite 

   location / {
     return 403 " location return \n";
   }

}

 

rewrite_log on | off

打开 rewrite 日志进行重定向分析

 

 find_config

location匹配流程详见 文档地址

 

REWITE 

rewrite阶段又可以分为两个小的阶段
1> 在server配置块中，按照顺序执行ngx_rewrite模块的指令
2> 在find-config阶段，nginx内核根据server配置块中所有location的配置为请求匹配到合适的location配置块，在rewrite阶段，location配置块中的配置的ngx_rewrite模块的指令将被执行。

 

 

下面讲一下rewrite的第三个参数flag：
1.1 ） last
如果有last参数，那么停止处理任何rewrite相关的指令，立即用替换后的新URI开始下一轮的location匹配。类似continue语法，此时请求依然处在nginx 11阶段循环中只是跳出本次循环。

1.2) break
停止处理任何rewrite的相关指令，就如同break 指令本身一样。 类似于goto + break 实现使得请求直接达到 content 阶段然后终止循环

last的break的相同点在于，立即停止执行所有当前上下文的rewrite模块指令；不同点在于last参数接着用新的URI马上搜寻新的location，而break不会搜寻新的location，直接用这个新的URI来处理请求，这样能避免重复rewite。因此，在server上下文中使用last，而在location上下文中使用break。

以上两种不会让客户端重新发起请求，下面两种则会引起客户端的一个重新请求

1.3) redirect
replacement 如果不包含协议，仍然是一个新的的URI，那么就用新的URI匹配的location去处理请求，不会返回30x跳转。但是redirect参数可以让这种情况也返回30x(默认302)状态码，就像新的URI包含http://和https://等一样。这样的话，浏览器看到302，就会再发起一次请求，真正返回响应结果的就是这第二个请求

1.4） permanent
和redirect参数一样，只不过直接返回301永久重定向

复制自链接：https://www.jianshu.com/p/da7a6e628bb4

 

POSTREWRITE

就是执行完成rewrite 之后会继续匹配规则

 

PREACCESS

主要需用于流控，http_limit_req_module

ACCESS

allow  deny

basic auth

auth_request 

三个模块可以进行认证动作 

location / {
    satisfy any;

    allow 192.168.1.0/32;
    deny  all;

    auth_basic           "closed site";
    auth_basic_user_file conf/htpasswd;
}

 

POSTACESS

Allows access if all (all) or at least one (any) of the ngx_http_access_module, ngx_http_auth_basic_module, ngx_http_auth_request_module, or ngx_http_auth_jwt_module modules allow access. 当有超过一个 access 阶段同时被定义是 可以用了协调判断关系

 

location / {
    satisfy any;

    allow 192.168.1.0/32;
    deny  all;

    auth_basic           "closed site";
    auth_basic_user_file conf/htpasswd;
}

 

 

PRECONTENT

try_files

mirror 镜像流量

 

CONTENT

content阶段主要是处理内容输出的阶段，是整个模型中比较靠后的阶段，但这个阶段是非常重要的一个阶段，有大量的模块与指令，例如proxy，三方的echo，content_by_lua等模块都是在这个阶段执行。注意Nginx 模块在向 content 阶段注册配置指令时，其实就是向location 配置块中注册所谓的“内容处理程序”（content handler）。每一个 location 只能有一个“内容处理程序”，因此，当在 location 中同时使用多个模块的 content 阶段指令时，只有其中一个模块能成功注册“内容处理程序”。例如 echo 和 content_by_lua 如果同时注册，最终只会有一个生效，但具体是哪一个生效是不稳定的。

LOG

记录日志