nginx實(shí)際把http請(qǐng)求處理流程劃分為了11個(gè)階段，這樣劃分的原因是將請(qǐng)求的執(zhí)行邏輯細(xì)分，以模塊為單位進(jìn)行處理，各個(gè)階段可以包含任意多個(gè)http模塊并以流水線的方式處理請(qǐng)求。這樣做的好處是使處理過程更加靈活、降低耦合度。可以讓每個(gè)HTTP模塊可以僅僅專注于完成一個(gè)獨(dú)立，簡(jiǎn)單的功能。而一個(gè)請(qǐng)求的完整處理過程可以由多個(gè)HTTP模塊共同合作完成?？梢詷O大的提高多個(gè)模塊合作的協(xié)同性，可測(cè)試性，可擴(kuò)展性。換言之，nginx在處理每一個(gè)http請(qǐng)求，和配置文件上的順序沒有關(guān)系。這11個(gè)http階段如下所示：
1）ngx_http_post_read_phase：
接收到完整的http頭部后處理的階段，它位于uri重寫之前，實(shí)際上很少有模塊會(huì)注冊(cè)在該階段，默認(rèn)的情況下，該階段被跳過。
最先執(zhí)行的 post-read 階段在 Nginx 讀取并解析完請(qǐng)求頭（request headers）之后就立即開始運(yùn)行。例如：使用了 ngx_realip 模塊提供的 set_real_ip_from 和 real_ip_header 這兩條配置指令
2）ngx_http_server_rewrite_phase：
uri與location匹配前，修改uri的階段，用于重定向，也就是該階段執(zhí)行處于server塊內(nèi)，location塊外的重寫指令，在讀取請(qǐng)求頭的過程中nginx會(huì)根據(jù)host及端口找到對(duì)應(yīng)的虛擬主機(jī)配置。
由于 server-rewrite 階段位于 post-read 階段之后，所以 server 配置塊中的 set 指令也就總是運(yùn)行在 ngx_realip 模塊改寫請(qǐng)求的來源地址之后。
3）ngx_http_find_config_phase：
根據(jù)uri尋找匹配的location塊配置項(xiàng)階段，該階段使用重寫之后的uri來查找對(duì)應(yīng)的location，值得注意的是該階段可能會(huì)被執(zhí)行多次，因?yàn)橐部赡苡衛(wèi)ocation級(jí)別的重寫指令。
這個(gè)階段并不支持 Nginx 模塊注冊(cè)處理程序，而是由 Nginx 核心來完成當(dāng)前請(qǐng)求與 location 配置塊之間的配對(duì)工作。換句話說，在此階段之前，請(qǐng)求并沒有與任何 location 配置塊相關(guān)聯(lián)。因此，對(duì)于運(yùn)行在 find-config 階段之前的 post-read 和 server-rewrite 階段來說，只有 server 配置塊以及更外層作用域中的配置指令才會(huì)起作用。這就是為什么只有寫在 server 配置塊中的 ngx_rewrite 模塊的指令才會(huì)運(yùn)行在 server-rewrite 階段，這也是為什么前面所有例子中的 ngx_realip 模塊的指令也都特意寫在了 server 配置塊中，以確保其注冊(cè)在 post-read 階段的處理程序能夠生效。
4）ngx_http_rewrite_phase：
上一階段找到location塊后再修改uri，location級(jí)別的uri重寫階段，該階段執(zhí)行l(wèi)ocation基本的重寫指令，也可能會(huì)被執(zhí)行多次。
由于 Nginx 已經(jīng)在 find-config 階段完成了當(dāng)前請(qǐng)求與 location 的配對(duì)，所以從 rewrite 階段開始，location 配置塊中的指令便可以產(chǎn)生作用。當(dāng) ngx_rewrite 模塊的指令用于 location 塊中時(shí)，便是運(yùn)行在這個(gè) rewrite 階段。
5）ngx_http_post_rewrite_phase：
防止重寫url后導(dǎo)致的死循環(huán)，location級(jí)別重寫的后一階段，用來檢查上階段是否有uri重寫，并根據(jù)結(jié)果跳轉(zhuǎn)到合適的階段。
這個(gè)階段也像 find-config 階段那樣不接受 Nginx 模塊注冊(cè)處理程序，而是由 Nginx 核心完成 rewrite 階段所要求的“內(nèi)部跳轉(zhuǎn)”操作（如果 rewrite 階段有此要求的話）。例如：通過 rewrite 指令把當(dāng)前請(qǐng)求的 URI 無(wú)條件地改寫為 /bar，同時(shí)發(fā)起一個(gè)“內(nèi)部跳轉(zhuǎn)”，最終跳進(jìn)了 location /bar 中。這里比較有趣的地方是“內(nèi)部跳轉(zhuǎn)”的工作原理。“內(nèi)部跳轉(zhuǎn)”本質(zhì)上其實(shí)就是把當(dāng)前的請(qǐng)求處理階段強(qiáng)行倒退到 find-config 階段，以便重新進(jìn)行請(qǐng)求 URI 與 location 配置塊的配對(duì)。
6）ngx_http_preaccess_phase：
下一階段之前的準(zhǔn)備，訪問權(quán)限控制的前一階段，該階段在權(quán)限控制階段之前，一般也用于訪問控制，比如限制訪問頻率，鏈接數(shù)等。
該階段在 access 階段之前執(zhí)行，故名 preaccess.標(biāo)準(zhǔn)模塊 ngx_limit_req 和 ngx_limit_zone 就運(yùn)行在此階段，前者可以控制請(qǐng)求的訪問頻度，而后者可以限制訪問的并發(fā)度。
7）ngx_http_access_phase：
讓http模塊判斷是否允許這個(gè)請(qǐng)求進(jìn)入nginx服務(wù)器，訪問權(quán)限控制階段，比如基于ip黑白名單的權(quán)限控制，基于用戶名密碼的權(quán)限控制等。
標(biāo)準(zhǔn)模塊 ngx_access、第三方模塊 ngx_auth_request 以及第三方模塊 ngx_lua 的 access_by_lua 指令就運(yùn)行在這個(gè)階段。
8）ngx_http_post_access_phase：
訪問權(quán)限控制的后一階段，該階段根據(jù)權(quán)限控制階段的執(zhí)行結(jié)果進(jìn)行相應(yīng)處理，向用戶發(fā)送拒絕服務(wù)的錯(cuò)誤碼，用來響應(yīng)上一階段的拒絕。
這個(gè)階段也和 post-rewrite 階段類似，并不支持 Nginx 模塊注冊(cè)處理程序，而是由 Nginx 核心自己完成一些處理工作。post-access 階段主要用于配合 access 階段實(shí)現(xiàn)標(biāo)準(zhǔn) ngx_http_core 模塊提供的配置指令 satisfy 的功能。對(duì)于多個(gè) Nginx 模塊注冊(cè)在 access 階段的處理程序， satisfy 配置指令可以用于控制它們彼此之間的協(xié)作方式。比如模塊 A 和 B 都在 access 階段注冊(cè)了與訪問控制相關(guān)的處理程序，那就有兩種協(xié)作方式，一是模塊 A 和模塊 B 都得通過驗(yàn)證才算通過，二是模塊 A 和模塊 B 只要其中任一個(gè)通過驗(yàn)證就算通過。第一種協(xié)作方式稱為 all 方式（或者說“與關(guān)系”），第二種方式則被稱為 any 方式（或者說“或關(guān)系”）。默認(rèn)情況下，Nginx 使用的是 all 方式。
9）ngx_http_try_files_phase：
為訪問靜態(tài)文件資源而設(shè)置，try_files指令的處理階段，如果沒有配置try_files指令，則該階段被跳過。
這個(gè)階段專門用于實(shí)現(xiàn)標(biāo)準(zhǔn)配置指令 try_files 的功能，并不支持 Nginx 模塊注冊(cè)處理程序。try_files 指令接受兩個(gè)以上任意數(shù)量的參數(shù)，每個(gè)參數(shù)都指定了一個(gè) URI. 這里假設(shè)配置了 N 個(gè)參數(shù)，則 Nginx 會(huì)在 try-files 階段，依次把前 N-1 個(gè)參數(shù)映射為文件系統(tǒng)上的對(duì)象（文件或者目錄），然后檢查這些對(duì)象是否存在。一旦 Nginx 發(fā)現(xiàn)某個(gè)文件系統(tǒng)對(duì)象存在，就會(huì)在 try-files 階段把當(dāng)前請(qǐng)求的 URI 改寫為該對(duì)象所對(duì)應(yīng)的參數(shù) URI（但不會(huì)包含末尾的斜杠字符，也不會(huì)發(fā)生 “內(nèi)部跳轉(zhuǎn)”）。如果前 N-1 個(gè)參數(shù)所對(duì)應(yīng)的文件系統(tǒng)對(duì)象都不存在，try-files 階段就會(huì)立即發(fā)起“內(nèi)部跳轉(zhuǎn)”到最后一個(gè)參數(shù)（即第 N 個(gè)參數(shù)）所指定的 URI.通過 root 配置指令所指定的“文檔根目錄”進(jìn)行映射。例如，當(dāng)“文檔根目錄”是 /var/www/ 的時(shí)候，請(qǐng)求 URI /foo/bar 會(huì)被映射為文件 /var/www/foo/bar，而請(qǐng)求 URI /foo/baz/ 則會(huì)被映射為目錄 /var/www/foo/baz/. 注意這里是如何通過 URI 末尾的斜杠字符是否存在來區(qū)分“目錄”和“文件”的。
10）ngx_http_content_phase：
處理http請(qǐng)求內(nèi)容的階段，大部分http模塊介入這個(gè)階段，內(nèi)容生成階段，該階段產(chǎn)生響應(yīng)，并發(fā)送到客戶端。
Nginx 的 content 階段是所有請(qǐng)求處理階段中最為重要的一個(gè)，因?yàn)檫\(yùn)行在這個(gè)階段的配置指令一般都肩負(fù)著生成“內(nèi)容”（content）并輸出 HTTP 響應(yīng)的使命。正因?yàn)槠渲匾裕@個(gè)階段的配置指令也異常豐富。如echo、 echo_exec 指令， proxy_pass 指令， echo_location 指令，content_by_lua。
11）ngx_http_log_phase：
log階段處理，比如記錄訪問量/統(tǒng)計(jì)平均響應(yīng)時(shí)間。log_by_lua
處理完請(qǐng)求后的日志記錄階段，該階段記錄訪問日志。
以上11個(gè)階段中，http無(wú)法介入的階段有4個(gè)：
3）ngx_http_find_config_phase
5）ngx_http_post_rewrite_phase
8）ngx_http_post_access_phase
9）ngx_http_try_files_phase
剩余的7個(gè)階段，http模塊均能介入，每個(gè)階段可介入模塊的個(gè)數(shù)也是沒有限制的，多個(gè)http模塊可同時(shí)介入同一階段并作用于同一請(qǐng)求。
參考博客：https://www.cnblogs.com/zhenyuyaodidiao/p/9288430.html
https://www.cnblogs.com/vinsent/p/12259287.html
聯(lián)系客服
