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框架自身實現。