nginx將一個HTTP請求分爲11個處理階段,這樣做讓每個HTTP模塊可以僅僅專注於完成一個獨立,簡單的功能。而一個請求的完整處理過程可以由多個HTTP模塊共同合作完成。可以極大的提高多個模塊合作的協同性,可測試性,可擴展性。換言之,nginx在處理每一個http請求,和配置文件上的順序沒有關係。
1 post-read
接受到完整的http頭部後,讀取請求內容階段,nginx讀取並解析完請求頭之後就立即開始執行;
2 server-rewrite
在uri與location匹配之前修改請求的URI(重定向),在server塊中的請求地址重寫階段;
3 find-config
配置查找階段,根據請求uri匹配location表達式,這個階段不支持nginx模塊註冊處理程序,而是由ngx_http_core_module模塊來完成當前請求與location配置快之間的配對工作;
4 rewrite
location塊中的請求地址重寫階段,當rewrite指令用於location中,即運行。另外,ngx_lua模塊中的set_by_lua指令和rewrite_by_lua指令也在此階段;
5 post-rewrite
請求地址重寫提交階段,防止遞歸修改uri造成死循環,(一個請求執行10次就會被nginx認定爲死循環)該階段只能由ngx_http_core_module模塊實現
6 preaccess
訪問權限檢查準備階段,http模塊介入處理階段,標準模塊ngx_limit_req和ngx_limit_zone就運行在此階段,前置可以控制訪問的頻率,後者限制訪問的併發度
7 access
訪問權限檢查階段,標準模塊ngx_access,第三方模塊nginx_auth_request以及第三方模塊ngx_lua的access_by_lua 指令運行在此階段,配置指令多是執行訪問控制性質的任務,比如檢查用戶的訪問權限,檢查用戶的來源IP地址是否合法;
8 post-access
訪問權限檢查提交階段;如果請求不被允許訪問nginx服務器,該階段負責向用戶返回錯誤響應;
9 try-files
配置項try_files處理階段
如果http請求訪問靜態文件資源,try_files配置項可以使這個請求順序地訪問多個靜態文件資源,直到某個靜態文件資源符合選取條件;
10 content
內容產生階段,大部分HTTP模塊會介入該階段,是所有請求處理階段中最重要的階段,因爲這個階段的指令通常是用來生成HTTP響應內容的;
11 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這四個階段是不允許HTT模塊加入自己的ngx_http_handler_py方法處理用戶請求的,他們僅由HTTP框架自身實現。