本部分內容將詳細介紹 Nginx 中對 Http請求的 11 個處理階段，分成 3 個小節講解並進行相關實驗操作。
Nginx 將壹個 Http 請求分成多個階段，以模塊為單位進行處理。其將 Http請求的處理過程分成了 11 個階段，各個階段可以包含任意多個 Http 的模塊並以流水線的方式處理請求。這 11 個 Http 階段如下所示：
網上有人做了壹個非常形象的圖片，如下圖所示。我們可以看到 11 個階段的處理順序，以及每個階段中涉及到的相關模塊以及模塊之間的順序。
POST_READ 階段是 Nginx 接收到 Http 請求完整頭部後的處理階段，這裏主要使用的是 realip 模塊獲取用戶的真實地址，方便後續對該 IP 進行限速或者過濾其請求等。
SERVER_REWRITE 和後面的 REWRITE 階段壹般是使用 rewrite 模塊修改 Http請求的 uri，實現請求的控制。
FIND_CONFIG 階段只是做 location 的匹配項。
PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 請求訪問權限相關的階段。PREACCESS 階段是在連接之前要做的訪問控制, 這個階段有 limit_conn 和 limit_req 等模塊工作。ACCESS 階段是解決用戶能不能訪問，比如根據用戶名、密碼限制用戶訪問(auth_basic 模塊)、根據 ip 限制用戶訪問(access 模塊)以及第三方模塊認證限制用戶的訪問(auth_request模塊)。POST_ACCESS 是在 ACCESS 之後要做的壹些工作。
TRY_FILES 階段為訪問靜態文件資源而設置的。有時候又稱之為 PRECONTENT 階段，即在 CONTENT 階段之前做的事情。主要是 try_files 模塊在此階段工作。
最重要的 CONTENT 是處理 Http 請求內容的階段，大部分 HTTP 模塊介入這個階段，比如 index、autoindex、concat 以及反向代理的模塊都是在這裏生效的。
LOG 是處理完請求後的日誌記錄階段，如 access_log 模塊。
realip 模塊是在 postread 階段生效的，它的作用是: 當本機的 nginx 處於壹個反向代理的後端時獲取到真實的用戶 ip。 如果沒有 realip 模塊，Nginx 中的 $remote_addr 可能就不是客戶端的真實 ip 了，而是代理主機的 ip。
realip模塊的配置實例如下:
set_real_ip_from 是指定我們信任的後端代理服務器，real_ip_header 是告訴 nginx 真正的用戶 ip 是存在 X-Forwarded-For 請求頭中的。
當 real_ip_recursive 設置為 off 時，nginx 會把 real_ip_header 指定的 Http頭中的最後壹個 ip 當成真實 ip;
而當 real_ip_recursive 為 on 時，nginx 會把 real_ip_header 指定的 Http頭中的最後壹個不是信任服務器的 ip (前面設置的set_real_ip_from)當成真實 ip。通過這樣的手段，最後拿到用戶的真實 ip。
rewrite 模塊可以看到它在 SERVER_REWRITE 和 REWRITE 階段都有介入。rewrite 模塊的主要功能是改寫請求的 uri。它是 Nginx 默認安裝的模塊。rewrite 模塊會根據正則匹配重寫 uri，然後發起內部跳轉再匹配 location, 或者直接做30x重定向返回客戶端。rewrite 模塊的指令有 break, if, return, rewrite, set 等，這些都是我們常用到的。
return 指令返回後，Http 請求將在 return 的階段終止，後續階段將無法進行，所以許多模塊得不到執行。
1、將 regex 指定的 url 替換成 replacement 這個新的 url,可以使用正則表達式及變量提取。
2、當 replacement 以 http:// 或者 https:// 或者 $schema 開頭，則直接返回 302 重定向
3、替換後的 url 根據 flag 指定的方式進行處理
if 指令的條件表達式:
location 匹配是在 FIND_CONFIG 階段進行的，我們需要掌握 location 的匹配規則和匹配順序。
有壹個簡單總結如下：
即：
realip 模塊默認沒有被編譯進 Nginx 的，我們需要在源碼編譯階段使用–with-http_realip_module，將 realip 模塊編譯進來後方可使用。接下來，我們做個簡單測試，首先準備壹個 server 塊如下：
首先，我們將 real_ip_recursive 設置為 off，然後做壹次請求:
這裏返回的是頭部參數 X-Forwarded-For 中最後壹個 ip，如果將 real_ip_recursive 設置為 on，此時，由於 set_real_ip_from 中設置218.19.206.164為信任的方向代理 ip，那麽 Nginx 會往前找壹位，認為 1.1.1.1 是用戶的真實ip。
我們寫壹個簡單配置如下：
先測試if指令，當請求方法為 POST 時，我們能得到 ‘post request!’ 這樣的字符串輸出。GET 請求時候，針對 404 情況，會跳轉到/403.html，我們準備壹個 403.html 頁面，裏面寫上’403, forbidden!’ 這壹行內容，開始下面的 Http 請求:
如果我們打開 return 405 這行指令，則 error_page 將不會生效，連同後面的 location 匹配也不會生效。無論我們發送如何請求，都會返回405的錯誤信息。這是因為 server 中的 return 指令是在 SERVER_REWRITE中執行的，而 location 匹配則是在下壹個階段 FIND_CONFIG 中執行的，所以上壹個階段在 return 後，根本不會進入後面的階段執行。
首先，我們準備環境，首先是新建壹個目錄 third（全路徑為/root/test/third），再該目錄下新建壹個文件 3.txt, 裏面只有壹行內容 ‘hello, world’。接下來，我們準備壹個 server 塊，加到 Http 指令塊中:
上述配置中，要打開 rewrite_log指令，這樣我們可以看到 rewrite 指令的相應日誌，方便查看結果。
當我們在 /second 配置中，使用 break 時，請求命令:
如果是不使用 break 標識，則請求結果如下:
首先是 /first/3.txt 請求在 /first 中匹配，並被替換為 /second/3.txt， last 標識表示將繼續進行匹配，在 /second 中，uri 又被 rewrite 成 /third/3.txt, 如果後面跟了 break 標識，表示 rewrite 到此結束，不會執行後面的 return 指令，直接請求靜態資源 /third/3.txt,得到其內容’hello, world’;如果是沒有 break 標識，則會在執行 return 指令後直接返回，並不會繼續執行下去，最後返回’second!'字符串。
我們按照這樣的 location 規則，進行匹配實驗，結果如下：
這裏介紹了 Nginx 處理 Http 請求的 11 個階段，並重點介紹了 前三個階段POST_READ、REWRITE以及FIND_CONFIG以及這些階段中涉及到的模塊和指令。前面講到的指令都是 Nginx 中的高頻指令，必須要熟練掌握。