nginx phases 介紹

如果把重寫指令放到location中，那麼就進入了rewrite phase，這個階段是location級別的uri重寫階段，重寫指令也可能會被執行多次；

重寫指令有HttpRewriteModule 的set指令,rewrite指令，HttpLuaModule的set_by_lua指令, ngx_set_misc模組的set_unescape_uri指令，另外HttpRewriteModule的幾乎所有指令都屬於rewrite階段。

到此，思考一個問題： 既然不用module的不同重寫指令到可以在這個phase，那麼這些指令是否可以在同一個location並存，如果可以，那麼他們的執行順序是怎麼樣的？

範例1 ：
思考下面範例的輸出的結果是什麼？

 location /test {
        set $a 32;
        set $b 56;
        set_by_lua $c "return ngx.var.a + ngx.var.b";
        set $d "$a + $b = $c";
        echo $d;
    }

當我們造訪 http://localhost/test時，輸出結果為 32 + 56 = 88 ，應該是和我們預期一致的。

但是這並不能證明所有屬於同一個phases的不同的module的指令在一個phase中並存時一定是按照順序執行下來的。 事實上，上述的這些第三方模組都採用了特殊的技術，將它們自己的配置指令「注入」到了 HttpRewriteModule的指令序列中（它們都藉助了 Marcus Clyne 編寫的第三方模組 ngx_devel_kit）。換句話說，更多常規的在 Nginx 的 rewrite 階段註冊和運行指令的第三方模組就沒那麼幸運了。這些「常規模組」的指令雖然也運行在 rewrite 階段，但其配置指令和 HttpRewriteModule（以及同一階段內的其他模組）都是分開獨立執行的。在運行時，不同模組的配置指令集之間的先後順序一般是不確定的（嚴格來說，一般是由模組的載入順序決定的，但也有例外的情況）。例如A 和B 兩個模組都在rewrite 階段運行指令，於是要嘛是A 模組的所有指令全部執行完再執行B 模組的那些指令，要嘛就是反過來，把B 的指令全部執行完，再去運行A的指令。除非模組的文檔中有明確的交待，否則使用者一般不應編寫依賴於此種不確定順序的配置。還有不少第三方模組，ngx_array_var 以及用於加解密使用者會話（session）的 ngx_encrypted_session，也都可以和HttpRewriteModule的指令無縫混合工作。標準 HttpRewriteModule的應用是如此廣泛，所以能夠和它的配置指令混合使用的第三方模組是幸運的。不能和HttpRewriteModule混合使用的指令在實際使用的過程要引起注意，它的輸出是不確定的，這與他們在設定檔中的順序無關。

結論：作用域為同一個phase的不同modules的指令，如果modules之間做了特殊的兼容，則它們按照指令在配置文件中出現的順序依次執行下來

例子2：
思考下面這個輸出什麼？

location /test {
        set $value dog;
        more_set_input_headers "X-Species: $value";
        set $value cat;
        echo "X-Species: $http_x_species";
    }

说明：第三方模块 ngx_headers_more 提供了一系列配置指令，用于操纵当前请求的请求头和响应头。其中有一条名叫 more_set_input_headers 的指令可以在 rewrite 阶段改写指定的请求头（或者在请求头不存在时自动创建）。该指令的文档中有这么一行标记 phase： rewrite tail,是说这条指令总是运行在 rewrite 阶段的末尾。显然，写在 more_set_input_headers 指令之后的 set $value cat 语句却先执行了。也就是说属于HttpRewriteModule的set指令先执行完了，才执行ngx_header_more 的set_input_headers指令。
结论：即使运行在同一个请求处理阶段，分属不同模块的配置指令也可能会分开独立运行（除非像 ngx_set_misc 等模块那样针对 ngx_rewrite 模块提供特殊支持）。换句话说，在单个请求处理阶段内部，一般也会以 Nginx 模块为单位进一步地划分出内部子阶段。下面的例子3同例子2：

例子3：

location /test {
         set $a 1;
         rewrite_by_lua "ngx.var.a = ngx.var.a + 1";
         set $a 56;    
         echo $a;
     }

说明：HttpLuaModule的rewrite_by_lua 指令也是处在 rewrite tail phase，它也会在rewrite 阶段的末尾执行。因此HttpRewriteModule的所有set执行完后，才执行它。
显然，rewrite_by_lua 指令的行为不同于我们前面在 （二） 中介绍过的 set_by_lua 指令。
小伙伴们可能要问，既然 more_set_input_headers 和 rewrite_by_lua 指令都运行在 rewrite 阶段的末尾，那么它们之间的先后顺序又是怎样的呢？答案是：不一定。我们应当避免写出依赖它们二者间顺序的配置。

结论：作用域在同一个phase的不同modules的指令，如果没有做特殊兼容处理，则它们指令的执行顺序与指令在配置中出现的顺序无关，结果具有不确定性

    location /hello {
        allow 127.0.0.1;
        deny all; 
        echo "hello world";
    }

    location /hello {
        deny all; 
        allow 127.0.0.1;
        echo "hello world";
    }

try_files $uri $uri/ /index.php?q=$uri&$args

 location /test {
          set $a 123;
          set $b 456;
          echo $b;
          content_by_lua '
             ngx.say(ngx.var.a)
           ';
    }

 location /test_echo {
          content_by_lua '
             ngx.say(ngx.var.a)
           ';
          set $a 123;
          set $b 456;
    }