init_by_lua http
set_by_lua server, server if, location, location if rewrite_by_lua
http, server, location, location if access_by_lua http, server,
location, location if content_by_lua location, location if
header_filter_by_lua http, server, location, location if
body_filter_by_lua http, server, location, location if log_by_lua
http, server, location, location if init_by_lua:
在nginx重新載入配置檔案時，執行裡面lua指令碼，常用於全域性變數的申請。
例如lua_shared_dict共享記憶體的申請，只有當nginx重起後，共享記憶體資料才清空，這常用於統計。 set_by_lua:
設定一個變數，常用與計算一個邏輯，然後返回結果 該階段不能執行Output API、Control API、Subrequest
API、Cosocket API rewrite_by_lua: 在access階段前執行，主要用於rewrite
access_by_lua: 主要用於訪問控制，能收集到大部分變數，類似status需要在log階段才有。 這條指令運行於nginx
access階段的末尾，因此總是在 allow 和 deny 這樣的指令之後執行，雖然它們同屬 access 階段。
content_by_lua:
階段是所有請求處理階段中最為重要的一個，執行在這個階段的配置指令一般都肩負著生成內容（content）並輸出HTTP響應。
header_filter_by_lua: 一般只用於設定Cookie和Headers等 該階段不能執行Output
API、Control API、Subrequest API、Cosocket API body_filter_by_lua:
一般會在一次請求中被呼叫多次, 因為這是實現基於 HTTP 1.1 chunked 編碼的所謂“流式輸出”的。
該階段不能執行Output API、Control API、Subrequest API、Cosocket API
log_by_lua:
該階段總是執行在請求結束的時候，用於請求的後續操作，如在共享記憶體中進行統計資料,如果要高精確的資料統計，應該使用body_filter_by_lua。
該階段不能執行Output API、Control API、Subrequest API、Cosocket API 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讀取並解析完請求頭之後就立即開始執行 例如模組 ngx_realip 就在 post-read
階段註冊了處理程式，它的功能是迫使 Nginx 認為當前請求的來源地址是指定的某一個請求頭的值。 server-rewrite
Server請求地址重寫階段 當 ngx_rewrite 模組的set配置指令直接書寫在 server 配置塊中時，基本上都是執行在
server-rewrite 階段 find-config 配置查詢階段 這個階段並不支援 Nginx 模組註冊處理程式，而是由
Nginx 核心來完成當前請求與 location 配置塊之間的配對工作。 rewrite Location請求地址重寫階段 當
ngx_rewrite 模組的指令用於 location 塊中時，便是執行在這個 rewrite 階段。
另外，ngx_set_misc(設定md5、encode_base64等) 模組的指令，還有 ngx_lua 模組的
set_by_lua 指令和 rewrite_by_lua 指令也在此階段。 post-rewrite 請求地址重寫提交階段 由
Nginx 核心完成 rewrite 階段所要求的“內部跳轉”操作,如果 rewrite 階段有此要求的話。 preaccess
訪問許可權檢查準備階段 標準模組 ngx_limit_req 和 ngx_limit_zone
就執行在此階段，前者可以控制請求的訪問頻度，而後者可以限制訪問的併發度。 access 訪問許可權檢查階段 標準模組
ngx_access、第三方模組 ngx_auth_request 以及第三方模組 ngx_lua 的 access_by_lua
指令就執行在這個階段。 配置指令多是執行訪問控制性質的任務，比如檢查使用者的訪問許可權，檢查使用者的來源 IP 地址是否合法
post-access 訪問許可權檢查提交階段 主要用於配合 access 階段實現標準 ngx_http_core 模組提供的配置指令
satisfy 的功能。 satisfy all(與關係) satisfy any(或關係) try-files
配置項try_files處理階段 專門用於實現標準配置指令 try_files 的功能 如果前 N-1
個引數所對應的檔案系統物件都不存在，try-files 階段就會立即發起“內部跳轉”到最後一個引數（即第 N 個引數）所指定的
URI. content 內容產生階段 Nginx 的 content
階段是所有請求處理階段中最為重要的一個，因為執行在這個階段的配置指令一般都肩負著生成“內容” 並輸出 HTTP 響應的使命。