Nginx處理http請求的11個階段

nginx將一個HTTP請求分爲11個處理階段，這樣作讓每一個HTTP模塊能夠僅僅專一於完成一個獨立，簡單的功能。而一個請求的完整處理過程能夠由多個HTTP模塊共同合做完成。能夠極大的提升多個模塊合做的協同性，可測試性，可擴展性。換言之，nginx在處理每個http請求，和配置文件上的順序沒有關係。

post-read

接受到完整的http頭部後，讀取請求內容階段，nginx讀取並解析完請求頭以後就當即開始執行；

server-rewrite

在uri與location匹配以前修改請求的URI（重定向），在server塊中的請求地址重寫階段；

find-config

配置查找階段，根據請求uri匹配location表達式，這個階段不支持nginx模塊註冊處理程序，而是由ngx_http_core_module模塊來完成當前請求與location配置快之間的配對工做；

rewrite

location塊中的請求地址重寫階段，當rewrite指令用於location中，即運行。另外，ngx_lua模塊中的set_by_lua指令和rewrite_by_lua指令也在此階段；

post-rewrite

請求地址重寫提交階段，防止遞歸修改uri形成死循環，（一個請求執行10次就會被nginx認定爲死循環）該階段只能由ngx_http_core_module模塊實現

preaccess

訪問權限檢查準備階段，http模塊介入處理階段，標準模塊ngx_limit_req和ngx_limit_zone就運行在此階段，前置能夠控制訪問的頻率，後者限制訪問的併發度

access

訪問權限檢查階段，標準模塊ngx_access,第三方模塊nginx_auth_request以及第三方模塊ngx_lua的access_by_lua 指令運行在此階段，配置指令可能是執行訪問控制性質的任務，好比檢查用戶的訪問權限，檢查用戶的來源IP地址是否合法；

post-access

訪問權限檢查提交階段；若是請求不被容許訪問nginx服務器，該階段負責向用戶返回錯誤響應；

try-files

配置項try_files處理階段

若是http請求訪問靜態文件資源，try_files配置項可使這個請求順序地訪問多個靜態文件資源，直到某個靜態文件資源符合選取條件；

content

內容產生階段，大部分HTTP模塊會介入該階段，是全部請求處理階段中最重要的階段，由於這個階段的指令一般是用來生成HTTP響應內容的；

log

日誌模塊處理階段，記錄日誌；

以上階段中，有些階段是必備的，有些階段是可選的，各個階段能夠容許多個HTTP模塊同時介入，nginx會按照各個HTTP模塊的ctx_index順序執行這些模塊的hadler方法。

可是ngx_http_find_config_phase,nginx_http_post_rewrite_phase,nginx_http_post_access_phase,ngx_http_try_files_phase這四個階段是不容許HTTP模塊加入本身的ngx_http_handler_py方法處理用戶請求的，他們僅由HTTP框架自身實現。