Nginx的配置指令执行不是按照配置的先后顺序执行，二十分为11 个阶段post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、try-files、content 以及 log ， Nginx
配置文件中的所有指令是按照上面11个阶段的顺讯执行。
set_real_ip_from的值可以是一个ip，也可以是一个ip段，表示当
请求是某一个ip时，使用real_ip_header的值替换 realip_remote_addr 和 realip_remote_port中。
运行命令
查看日志其中的remote_addr 已经改为 192.2.2.2,而 $realip_remote_addr 是127.0.0.1。 当Header IP是非法的
IP地址，则remote_addr 不改变。
** 注意 real_ip_header 的默认值为 X-Real-IP
下面我们着重看一下 real_ip_recursive（默认值为off）
1） real_ip_header 的http header中仅有一个ip时，则直接替换remote_addr。
2） real_ip_header 的http header 中有多个ip时
- real_ip_recursive 为off时， 则用第一个ip替换remote_addr
- real_ip_recursive 为on时， 则用第一个不在set_real_ip_from 的ip替换remote_addr
例如nginx配置如下：
请求命令为
remote_addr 被替换为 192.168.2.3 （注意这里的顺序是从右至左）。当real_ip_recursive为off时 remote_addr被替换为 192.178.2.2
例如nginx有以下配置
访问/first之后，日志中输出 Hello world； 这是因为 set $b "Hello"; 定义在server模块下，所以在server-rewrite阶段已经执行。所以在location块中定义的才能执行的结果才是正确的。
后面再rewrite阶段会详细讲解这几个命令。
下面我们详细看一下ngx_rewrite中的7个指令：
1） rewrite （基本语法： rewrite regex replacement [flag]; 可以配置在server，location和if配置块下）
regex是RCPE风格的，如果regex匹配URI，nameURI就会被替换成replacement，replacement就是新的URI，如果同一个配置块下有多个rewrite配置指令，匹配并不会终止，而是继续用新的URI（也就是上一次匹配到的replacement）继续进行匹配，直至返回最后一个匹配。如果在匹配到之后想要停止匹配直接返回，可是使用flag参数（将其设置为break）。
注意 ： 如果匹配到replacement中有关于协议的东西，例如http://或者https://等，处理将终止，直接返回客户端302（Temporary redirect）。
如果Nginx返回给客户端30x，浏览器在接收到这个状态码时，会根据response中的Location响应头再发起一次请求；如果不是30x状态码，所有的跳转只是在nginx内部完成，有兴趣的可以将nginx的日志调为debug看一下整个跳转过程。
举一个例子
当请求 curl -I
http://localhost:8080/first 时，nginx接到请求之后，匹配到/first 根据第一个rewrite指令，将URI替换为/test, 然后继续执行第二个rewrite指令，将URI替换为/index.html，之后继续执行第三个指令，返现regex（/test）与新的URI（/index.html）并不匹配，所以最终我们将会看到index.html的返回结果。开启debug日志，可以看到详细的跳转过程。
再举一例
当请求 curl -I
http://localhost:8080/first 时，首先会执行server块下的rewrite，所有请求都返回302 （Location：
https://127.0.0.1:8080/first ）。
下面讲一下rewrite的第三个参数flag：
1.1 ） last
如果有last参数，那么停止处理任何rewrite相关的指令，立即用替换后的新URI开始下一轮的location匹配。
1.2) break
停止处理任何rewrite的相关指令，就如同break 指令本身一样。
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永久重定向
虽说URI有了新的，但是要拼接成完整的URL还需要当前请求的scheme，以及由server_name_in_redirect和port_in_redirect指令决定的HOST和PORT.
还有一个比较有意思的应用，就是如果replacement中包含请求参数，那么默认情况下旧URI中的请求参数也会拼接在replacement后面作为新的URI，如果不想这么做，可以在replacement的最后面加上?。
2） break (基本语法： break; 可以配置在server，location 和if配置块下)
停止任何处理rewrite的相关指令。如果出现在location里面，name所有后面的rewrite模块都不会执行，也不发起内部重定向，而是直接用新的URI处理请求。
例如有如下配置
访问 curl -I
http://localhost:8080/server/break ，将返回404；
请求 curl -I
http://localhost:8080/server/last 将返回index.html
访问 curl -I
http://localhost:8080/hello ，将返回 404；
请求 curl -I
http://localhost:8080/hello1 ，将返回index.html。
综合以上的实验，可以肯定的是在server中配置块中如果使用break指令，下面所有的location将不会执行，而last会进行下一次内部跳转。location中的break则是直接退出，返回URI的结果； last 进入下一次内部跳转，该location内的rewrite配置指令不再执行。
3） if (基本语法：if(condition) {....}) 可以配置在server和location配置块中
根据condition是true和false决定是否加载 花括号中的配置，花括号中的配置可以继承外面的配置，也可以对外面的指令进行重写。
condition 可以是自定义变量或者系统变量本身，也可以是表达式：
a. condition 为变量本身时， 0： false 非0 ： true
b. 变量可以通过"=" 、"!=" 与字符串比较
c. 匹配
正则表达式 ~ !~ （大小写敏感） ~* !~* （大小写不敏感）
d. -f -d -e -x !-f !-d !-e !-x 等检验文件或者目录存在或者文件属性
4） return (基本语法： return code [text]; return code URL; return URL; 可以配置在server，location和if配置块中)
停止任何的进一步处理，并且将指定状态码返回给客户端。如果状态码为444(此状态码是非标准的)，那么直接关闭此TCP连接。
return的参数有四种形式：
5） set (基本语法： set $var value; 可以配置在server，location和if配置块中)
这个指令可以用来自定义变量，也可以改变系统变量的值。
6） rewrite_log (基本语法： rewrite_log on | off; 可以配置在http，server，location和if配置块中)
如果开启on，name当rewrite时，会产生一个notice基本的日志；否则不产生日志。可以在调试的时候将其设置为on。
请求 curl -I
http://localhost:8080/first 时，先找到 /first location，在 /first location中rewrite URI 为/index.html进入post-rewrite阶段，进行一次内部跳转，回到find-config阶段，使用新的/index.html做为URI重新匹配location至 location / 。
这里有一个问题，为什么不在rewrite阶段执行内部跳转？答案就是为了在一个location中支持反复改写URI。试想一下如果有以下配置。
如果在rewrite阶段直接做内部跳转，那么 第二个rewrite将不能执行，我们必须再声明一个 /second location进行URI 重写。
想证实这一点很简单，我们做一个简单的例子：
请求 curl
http://localhost:8080/first 之后将得到 "third content"相应值，同时可以在日志中看到如下日志。
注意一下，server配置块下的rewrite命令在server-rewrite阶段执行。
nginx限制请求是一个比较复杂的模块，后面会单独解说。
在接口/post_access 中同时配置了ngx_access 和ngx_lua两个模块，这样access阶段就由两个模块一起检查，其中deny all 会让ngx_access模块处理程序拒绝当前请求，而语句access_by_lua 'ngx.exit(ngx.OK)' ; 则总是允许访问。当satify指令为all时，当前的请求会被拒绝，返回403（forbidden）。