服務器日誌裏出現大量http400錯誤不必定是網站問題

服務器中的錯誤記錄相似於這種：

124.65.133.242 – – [27/Oct/2014:14:30:51 +0800] 「-」 400 0 「-」 「-」
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] 「-」 400 0 「-」 「-」
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] 「-」 400 0 「-」 「-」
124.65.133.242 – – [27/Oct/2014:14:31:45 +0800] 「-」 400 0 「-」 「-」

踩點

通過分析nginx的log文件，發現都是在一次正常訪問以後產生的數個400錯誤，每次有大概連續出現1-6個不等，並且也並非每次客戶訪問都會產生400錯誤。

再觀察產生400錯誤的前一次訪問是很正常的，200狀態碼，正常的文件，正常的來路，正常的User-Agent… 一切都很和諧，那400是腫麼來的呢？

經過仔細觀察發現，全部產生400錯誤的前一次訪問的User-Agent都是Google Chrome瀏覽器留下的，也就是說400錯誤是由Chrome瀏覽器產生的。可是通過本地抓包發現，chrome是沒有向服務器發送異常請求或者數據包的。

在抓包分析中發現，Chrome在訪問服務器時發起的鏈接不止一個，通常有5到6個不等，而若是請求的資源不須要那麼多鏈接時，Chrome就會關閉未用的鏈接，這項技術叫作pre-connection「預先鏈接」。

一般咱們訪問一個網站時，第一個獲取的是一個html主文件，而裏面連接了網頁所須要的css、js、圖片等其餘媒體資源文件，而通常資源文件和主 html文件是在一個域下的，預先鏈接就是在獲取html以前就創建不少的tcp鏈接，而不是等到獲取到html文件以後再去鏈接服務器獲取其餘的文件， 由於鏈接服務器是須要消耗一些時間的，因此這項技術能夠很大程度上加快網頁的呈現速度。

若是網頁html連接的資源比較少，或者客戶端有緩存，不須要鏈接下載，那麼Chrome瀏覽器發出的5-6個鏈接極可能只有1個是須要的，其餘的 都得關閉掉，這樣就產生了一個問題：鏈接了服務器，而沒有發送任何請求。對於這種狀況，nginx是當作400錯誤來處理的，但因爲鏈接已經關閉，錯誤信 息不會發送到客戶端，這就產生了日誌文件中記錄了錯誤，而抓包分析中什麼也看不到的現象。

測試

要驗證上面的分析結果很簡單，打開命令行cmd.exe，在裏面輸入telnet serverip 80，等待鏈接成功以後直接關掉cmd，這時去查看nginx的log文件中就多了一條400錯誤記錄。

一句評論

pre-connection的優勢已經很清楚了，可是它也是有缺點的，若是站長作了優化，使用了Cookie-free技術，或者網頁和靜態資源 使用不一樣的服務器，那麼網頁須要的css、js資源就和主html不在同一個域下，也可能不在同一個IP上，那麼pre-connection不只是雞 肋，並且會對主html服務器產生沒必要要的負擔。

其它緣由

網上不少人寫過相關的文章，大多的人的緣由是由於 header 的頭部大小超了，引發響應 400 告訴是 bad request.但其實還有一種可能，就是象端口測試工具，只是檢查端口是不是活的。像 LVS 之類什麼的，也會引發這種問題，而後日誌中會出現大量的 400 錯誤。

對於上述問題能夠在nginx.conf中，將client_header_buffer_size和large_client_header_buffers都調大，可緩解此問題。

轉載請註明：愛分享 » Linux服務器nginx訪問日誌裏出現大量http400錯誤的請求分析
原文地址：http://www.ihref.com/read-16479.html