您好,登錄后才能下訂單哦!
這篇文章主要介紹“Linux服務器nginx訪問日志里出現大量http 400錯誤怎么解決”的相關知識,小編通過實際案例向大家展示操作過程,操作方法簡單快捷,實用性強,希望這篇“Linux服務器nginx訪問日志里出現大量http 400錯誤怎么解決”文章能幫助大家解決問題。
服務器中的錯誤記錄類似于這種:
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訪問日志里出現大量http 400錯誤怎么解決”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識,可以關注億速云行業資訊頻道,小編每天都會為大家更新不同的知識點。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。