nginx 處理請求的過程一共劃分為 11 個階段，按照執行順序依次是 post-read、server-rewrite、find-config、rewrite、post-rewrite、preaccess、access、post-access、try-files、content 以及 log。
最先執行的 post-read 階段在 nginx 讀取並解析完請求頭（request headers）之後就立即開始執行。例如：使用了 ngx_realip 模組提供的 set_real_ip_from 和 real_ip_header 這兩條配置指令
由於 server-rewrite 階段位於 post-read 階段之後，所以 server 配置塊中的 set 指令也就總是執行在 ngx_realip 模組改寫請求的**位址之後。
這個階段並不支援 nginx 模組註冊處理程式，而是由 nginx 核心來完成當前請求與 location 配置塊之間的配對工作。換句話說，在此階段之前，請求並沒有與任何 location 配置塊相關聯。因此，對於執行在 find-config 階段之前的 post-read 和 server-rewrite 階段來說，只有 server 配置塊以及更外層作用域中的配置指令才會起作用。這就是為什麼只有寫在 server 配置塊中的 ngx_rewrite 模組的指令才會執行在 server-rewrite 階段，這也是為什麼前面所有例子中的 ngx_realip 模組的指令也都特意寫在了 server 配置塊中，以確保其註冊在 post-read 階段的處理程式能夠生效。
由於 nginx 已經在 find-config 階段完成了當前請求與 location 的配對，所以從 rewrite 階段開始，location 配置塊中的指令便可以產生作用。當 ngx_rewrite 模組的指令用於 location 塊中時，便是執行在這個 rewrite 階段。
這個階段也像 find-config 階段那樣不接受 nginx 模組註冊處理程式，而是由 nginx 核心完成 rewrite 階段所要求的「內部跳轉」操作（如果 rewrite 階段有此要求的話）。例如：通過 rewrite 指令把當前請求的 uri 無條件地改寫為 /bar，同時發起乙個「內部跳轉」，最終跳進了 location /bar 中。這裡比較有趣的地方是「內部跳轉」的工作原理。「內部跳轉」本質上其實就是把當前的請求處理階段強行倒退到 find-config 階段，以便重新進行請求 uri 與 location 配置塊的配對。
該階段在 access 階段之前執行，故名 preaccess.標準模組 ngx_limit_req 和 ngx_limit_zone 就執行在此階段，前者可以控制請求的訪問頻度，而後者可以限制訪問的併發度。
標準模組 ngx_access、第三方模組 ngx_auth_request 以及第三方模組 ngx_lua 的 access_by_lua 指令就執行在這個階段。
這個階段也和 post-rewrite 階段類似，並不支援 nginx 模組註冊處理程式，而是由 nginx 核心自己完成一些處理工作。post-access 階段主要用於配合 access 階段實現標準 ngx_http_core 模組提供的配置指令 satisfy 的功能。對於多個 nginx 模組註冊在 access 階段的處理程式， satisfy 配置指令可以用於控制它們彼此之間的協作方式。比如模組 a 和 b 都在 access 階段註冊了與訪問控制相關的處理程式，那就有兩種協作方式，一是模組 a 和模組 b 都得通過驗證才算通過，二是模組 a 和模組 b 只要其中任乙個通過驗證就算通過。第一種協作方式稱為 all 方式（或者說「與關係」），第二種方式則被稱為 any 方式（或者說「或關係」）。預設情況下，nginx 使用的是 all 方式。
這個階段專門用於實現標準配置指令 try_files 的功能，並不支援 nginx 模組註冊處理程式。try_files 指令接受兩個以上任意數量的引數，每個引數都指定了乙個 uri. 這裡假設配置了 n 個引數，則 nginx 會在 try-files 階段，依次把前 n-1 個引數對映為檔案系統上的物件（檔案或者目錄），然後檢查這些物件是否存在。一旦 nginx 發現某個檔案系統物件存在，就會在 try-files 階段把當前請求的 uri 改寫為該物件所對應的引數 uri（但不會包含末尾的斜槓字元，也不會發生 「內部跳轉」）。如果前 n-1 個引數所對應的檔案系統物件都不存在，try-files 階段就會立即發起「內部跳轉」到最後乙個引數（即第 n 個引數）所指定的 uri.通過 root 配置指令所指定的「文件根目錄」進行對映。例如，當「文件根目錄」是 /var/www/ 的時候，請求 uri /foo/bar 會被對映為檔案 /var/www/foo/bar，而請求 uri /foo/baz/ 則會被對映為目錄 /var/www/foo/baz/. 注意這裡是如何通過 uri 末尾的斜槓字元是否存在來區分「目錄」和「檔案」的。
nginx 的 content 階段是所有請求處理階段中最為重要的乙個，因為執行在這個階段的配置指令一般都肩負著生成「內容」（content）並輸出 http 響應的使命。正因為其重要性，這個階段的配置指令也異常豐富。echo、 nginx 變數漫談（二） 中接觸到的 echo_exec 指令， nginx 變數漫談（三） 中接觸到的 proxy_pass 指令，nginx 變數漫談（五） 中介紹過的 echo_location 指令，以及 nginx 變數漫談（七） 中介紹過的 content_by_lua。
log階段處理，比如記錄訪問量/統計平均響應時間。log_by_lua
Nginx處理請求的流程
nginx處理請求過程 nginx使用乙個多程序模型來對外提供服務，乙個master程序和多個worker程序，master程序負責管理nginx本身和其他worker程序。所有實際上的業務處理邏輯都在worker程序。worker程序中有乙個函式，執行無限迴圈，不斷處理收到的來自客戶端的請求，並進...
NGINX多階段處理
nginx實際把請求處理流程劃分為了11個階段，這樣劃分的原因是將請求的執行邏輯細分，各階段按照處理時機定義了清晰的執行語義，開發者可以很容易分辨自己需要開發的模組應該定義在什麼階段，下面介紹一下各階段 接收完請求頭之後的第乙個階段，它位於uri重寫之前，實際上很少有模組會註冊在該階段，預設的情況下...
Nginx請求處理流程
因為 nginx 執行在企業內網的最外層也就是邊緣節點，那麼他處理的的流量是其他應用伺服器處理流量的數倍，甚至幾個數量級，我們知道任何一種問題在不同的數量級下，他的解決方案是完全不同的，所以在 nginx 它所處理的應用場景中，所有的問題都會被放大，所以我們必須要去理解，為什麼 nginx 採用 m...