Nginx處理懲罰每一個(gè)用戶請(qǐng)求時(shí)，都是憑據(jù)若干個(gè)差異階段(phase)依次處理懲罰的，而不是按照設(shè)置文件上的順序。
Nginx處理懲罰請(qǐng)求的進(jìn)程一共分別為11個(gè)階段，憑據(jù)執(zhí)行順序依次是post-read、server-rewrite、find-config、rewrite、post-rewrite、 preaccess、access、post-access、try-files、content、log.
1、post-read
讀取請(qǐng)求內(nèi)容階段，nginx讀取并理會(huì)完請(qǐng)求頭之后就當(dāng)即開始運(yùn)行；譬喻模塊 ngx_realip 就在 post-read
階段注冊(cè)了處理懲罰措施，它的成果是迫使 Nginx 認(rèn)為當(dāng)前請(qǐng)求的來(lái)歷地點(diǎn)是指定的某一個(gè)請(qǐng)求頭的值。
2、server-rewrite
server請(qǐng)求地點(diǎn)重寫階段；當(dāng)ngx_rewrite模塊的set設(shè)置指令直接書寫在server設(shè)置塊中時(shí)，根基上都是運(yùn)行在server-rewrite
階段
3、find-config
設(shè)置查找階段，這個(gè)階段并不支持Nginx模塊注冊(cè)處理懲罰措施，而是由Nginx焦點(diǎn)來(lái)完成當(dāng)前請(qǐng)求與location設(shè)置塊之間的配對(duì)事情。
4、rewrite
location請(qǐng)求地點(diǎn)重寫階段，當(dāng)ngx_rewrite指令用于location中，就是再這個(gè)階段運(yùn)行的；別的ngx_set_misc(配置md5、encode_base64等)模塊的指令，尚有ngx_lua模塊的set_by_lua指令和rewrite_by_lua指令也在此階段。
5、post-rewrite
請(qǐng)求地點(diǎn)重寫提交階段，當(dāng)nginx完成rewrite階段所要求的內(nèi)部跳動(dòng)彈作，假如rewrite階段有這個(gè)要求的話；
6、preaccess
會(huì)見權(quán)限查抄籌備階段，ngx_limit_req和ngx_limit_zone在這個(gè)階段運(yùn)行，ngx_limit_req可以節(jié)制請(qǐng)求的會(huì)見頻率，ngx_limit_zone可以節(jié)制會(huì)見的并發(fā)度；
7、access
會(huì)見權(quán)限查抄階段，尺度模塊ngx_access、第三方模塊ngx_auth_request以及第三方模塊ngx_lua的access_by_lua指令就運(yùn)行在這個(gè)階段。設(shè)置指令多是執(zhí)行會(huì)見節(jié)制相關(guān)的任務(wù)，如查抄用戶的會(huì)見權(quán)限，查抄用戶的來(lái)歷IP是否正當(dāng)；
8、post-access
會(huì)見權(quán)限查抄提交階段；主要用于共同access階段實(shí)現(xiàn)尺度ngx_http_core模塊提供的設(shè)置指令satisfy的成果。satisfy
all(與干系),satisfy any(或干系)
9、try-files
設(shè)置項(xiàng)try_files處理懲罰階段；專門用于實(shí)現(xiàn)尺度設(shè)置指令try_files的成果,假如前 N-1
個(gè)參數(shù)所對(duì)應(yīng)的文件系統(tǒng)工具都不存在，try-files 階段就會(huì)當(dāng)即提倡“內(nèi)部跳轉(zhuǎn)”到最后一個(gè)參數(shù)(即第 N
個(gè)參數(shù))所指定的URI.
10、content
內(nèi)容發(fā)生階段，是所有請(qǐng)求處理懲罰階段中最為重要的階段，因?yàn)檫@個(gè)階段的指令凡是是用來(lái)生成HTTP響應(yīng)內(nèi)容并輸出 HTTP
響應(yīng)的使命；
11、log
日志模塊處理懲罰階段；記錄日志
二、Nginx下Lua處理懲罰階段與利用范疇：
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
timer
init_by_lua:
在nginx從頭加載設(shè)置文件時(shí)，運(yùn)行內(nèi)里lua劇本，常用于全局變量的申請(qǐng)。
譬喻lua_shared_dict共享內(nèi)存的申請(qǐng)，只有當(dāng)nginx重起后，共享內(nèi)存數(shù)據(jù)才清空，這常用于統(tǒng)計(jì)。
set_by_lua:
配置一個(gè)變量，常用與計(jì)較一個(gè)邏輯，然后返回功效
該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API
rewrite_by_lua:
在access階段前運(yùn)行，主要用于rewrite
access_by_lua:
主要用于會(huì)見節(jié)制，能收集到大部門變量，雷同status需要在log階段才有。
這條指令運(yùn)行于nginx access階段的末端，因此老是在 allow 和 deny 這樣的指令之后運(yùn)行，固然它們同屬 access
階段。
content_by_lua:
階段是所有請(qǐng)求處理懲罰階段中最為重要的一個(gè)，運(yùn)行在這個(gè)階段的設(shè)置指令一般都負(fù)擔(dān)著生成內(nèi)容(content)并輸出HTTP響應(yīng)。
header_filter_by_lua:
一般只用于配置Cookie和Headers等
該階段不能運(yùn)行Output API、Control API、Subrequest API、Cosocket API