Nginx日誌分析--路徑匹配篇

Nginx配置以後，有可能發生無法正常訪問網頁的情況。如果是路徑匹配方面的問題，可以通過它的錯誤記錄檔來分析解決。

Nginx的錯誤記錄檔在nginx.conf裡配置：

error_log  logs/error.log debug;

上述聲明在nginx安裝目錄下的logs目錄裡產生了一個error.log，記錄層級為debug級（最詳細級）。注意Nginx的配置是一個階層體系（參見Nginx設定檔解析），因此如果該聲明在HTTP結點下，則對所有http請求有效；如果在server結點下，則對該server的所有請求有效；如果在location結點下，則只對該location的請求有效。在做路徑匹配錯誤分析時，至少要配置到server結點或者以上，而不能配置在location上。否則，一旦因conf檔案書寫錯誤而某location應該匹配而沒有匹配上，就不會有任何日誌輸出，起不到調試的作用。

假設http://www.lotus-scent.com/blog/index.php/web技術/布署和最佳化/nginx錯誤記錄檔分析-路徑匹配篇/無法正常請求到頁面，分析如下:

下載樣本日誌

Nginx對上述請求的處理從日誌的第974行開始，這裡的關鍵詞是"http request line"。注意這一行輸出的URL是編碼之後的地址，接下來975行輸出瞭解碼後的地址：/blog/index.php/web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"。由於地址包含中文，因此顯示為亂碼。

第976行，Nginx繼續處理請求，解析出該請求沒有http args。對於請求"GET  /blog?user=aaron"，則此處會輸出"user=aaron"。

接下來到989行，Nginx對該請求的http header的分析結束。這裡的關鍵詞是"http header done"。

接下來Nginx處理地址匹配，注意988行的rewrite phase 0輸出。從日誌輸出可以看出，Nginx先後測試了5個location塊，最後使用/blog塊的配置對該請求進行處理：

2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "/"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "develop"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "ckeditor"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: "blog"
2011/09/19 23:54:54 [debug] 27343#0: *417 test location: ~ "/blog/.*\.(?:ico|css|js|gif|jpe?g|png)$"
2011/09/19 23:54:54 [debug] 27343#0: *417 using configuration "/blog"

注意這裡的關鍵詞"using configuration"。

從第999行進入rewrite phase第2階段，即在配置"/blog"塊中進行處理：

第1001行，取得URI原始字串：/usr/www/blog/index.php/web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"

第1003行，此行應該是檢查該URI是否直接對應伺服器上的某個檔案。1004行尋找失敗，直接進入1005行的rewrite匹配。此時匹配上Regex"^/blog/index.php/(.+)$"，並擷取子匹配"web鎶€鏈?javascript寮€鍙?娣卞害浣撻獙javascript-妯″潡璁捐妯″紡/"。接下來就是根據已經擷取的資訊調用/blog/index.php?q=$1"，由此進入下一輪內部地址重新導向。注意if語句塊中有一個break語句，表明執行到此處後，跳過後面的處理。

1013行進入第三輪地址重新導向，此輪請求的URI是”/blog/index.php?q=..”。1020行顯示匹配上配置/blog。注意該配置在上一輪中就匹配上了，但此輪以不同的參數調用再次匹配。

1027行，此處結果為false，意即/usr/www/blog/index.php為伺服器上存在的一個檔案。這樣整個if語句塊被跳過，直接進入到fastcgi的部分。行1041開始擷取QUERY_STRING,REQUEST_METHOD,SCRIPT_NAME等fastcgi參數，最後交php引擎處理以產生頁面，返回給用戶端。1120開始的幾行應該是Nginx從php獲得輸出後填充HTTP訊息響應時的日誌輸出。運行到此外也意味著Nginx對該http請求的處理基本結束。