Linux服務(wù)器nginx訪問日志里出現(xiàn)大量http 400錯(cuò)誤怎么解決

這篇文章主要介紹“Linux服務(wù)器nginx訪問日志里出現(xiàn)大量http 400錯(cuò)誤怎么解決”的相關(guān)知識(shí)，小編通過實(shí)際案例向大家展示操作過程，操作方法簡(jiǎn)單快捷，實(shí)用性強(qiáng)，希望這篇“Linux服務(wù)器nginx訪問日志里出現(xiàn)大量http 400錯(cuò)誤怎么解決”文章能幫助大家解決問題。

服務(wù)器中的錯(cuò)誤記錄類似于這種：

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 “-” “-”

踩點(diǎn)

經(jīng)過分析nginx的log文件，發(fā)現(xiàn)都是在一次正常訪問之后產(chǎn)生的數(shù)個(gè)400錯(cuò)誤，每次有大概連續(xù)出現(xiàn)1-6個(gè)不等，而且也并不是每次客戶訪問都會(huì)產(chǎn)生400錯(cuò)誤。

再觀察產(chǎn)生400錯(cuò)誤的前一次訪問是很正常的，200狀態(tài)碼，正常的文件，正常的來路，正常的user-agent… 一切都很和諧，那400是腫么來的呢？

通過仔細(xì)觀察發(fā)現(xiàn)，所有產(chǎn)生400錯(cuò)誤的前一次訪問的user-agent都是google chrome瀏覽器留下的，也就是說400錯(cuò)誤是由chrome瀏覽器產(chǎn)生的。但是經(jīng)過本地抓包發(fā)現(xiàn)，chrome是沒有向服務(wù)器發(fā)送異常請(qǐng)求或者數(shù)據(jù)包的。

在抓包分析中發(fā)現(xiàn)，chrome在訪問服務(wù)器時(shí)發(fā)起的連接不止一個(gè)，一般有5到6個(gè)不等，而如果請(qǐng)求的資源不需要那么多連接時(shí)，chrome就會(huì)關(guān)閉未用的連接，這項(xiàng)技術(shù)叫做pre-connection“預(yù)先連接”。

通常我們?cè)L問一個(gè)網(wǎng)站時(shí)，第一個(gè)獲取的是一個(gè)html主文件，而里面鏈接了網(wǎng)頁所需要的css、js、圖片等其他媒體資源文件，而一般資源文件和主 html文件是在一個(gè)域下的，預(yù)先連接就是在獲取html之前就建立很多的tcp連接，而不是等到獲取到html文件之后再去連接服務(wù)器獲取其他的文件， 因?yàn)檫B接服務(wù)器是需要消耗一些時(shí)間的，所以這項(xiàng)技術(shù)可以很大程度上加快網(wǎng)頁的呈現(xiàn)速度。

如果網(wǎng)頁html鏈接的資源比較少，或者客戶端有緩存，不需要連接下載，那么chrome瀏覽器發(fā)出的5-6個(gè)連接很可能只有1個(gè)是需要的，其他的 都得關(guān)閉掉，這樣就產(chǎn)生了一個(gè)問題：連接了服務(wù)器，而沒有發(fā)送任何請(qǐng)求。對(duì)于這種情況，nginx是當(dāng)做400錯(cuò)誤來處理的，但由于連接已經(jīng)關(guān)閉，錯(cuò)誤信 息不會(huì)發(fā)送到客戶端，這就產(chǎn)生了日志文件中記錄了錯(cuò)誤，而抓包分析中什么也看不到的現(xiàn)象。

測(cè)試
要驗(yàn)證上面的分析結(jié)果很簡(jiǎn)單，打開命令行cmd.exe，在里面輸入telnet serverip 80，等待連接成功之后直接關(guān)掉cmd，這時(shí)去查看nginx的log文件中就多了一條400錯(cuò)誤記錄。

一句評(píng)論
pre-connection的優(yōu)點(diǎn)已經(jīng)很清楚了，但是它也是有缺點(diǎn)的，如果站長做了優(yōu)化，使用了cookie-free技術(shù)，或者網(wǎng)頁和靜態(tài)資源 使用不同的服務(wù)器，那么網(wǎng)頁需要的css、js資源就和主html不在同一個(gè)域下，也可能不在同一個(gè)ip上，那么pre-connection不僅是雞 肋，而且會(huì)對(duì)主html服務(wù)器產(chǎn)生不必要的負(fù)擔(dān)。

其它原因

網(wǎng)上很多人寫過相關(guān)的文章，大多的人的原因是因?yàn)?header 的頭部大小超了，引起響應(yīng) 400 告訴是 bad request.但其實(shí)還有一種可能，就是象端口測(cè)試工具，只是檢查端口是否是活的。像 lvs 之類什么的，也會(huì)引起這種問題，然后日志中會(huì)出現(xiàn)大量的 400 錯(cuò)誤。

對(duì)于上述問題可以在nginx.conf中，將client_header_buffer_size和large_client_header_buffers都調(diào)大，可緩解此問題。

關(guān)于“Linux服務(wù)器nginx訪問日志里出現(xiàn)大量http 400錯(cuò)誤怎么解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)，可以關(guān)注億速云行業(yè)資訊頻道，小編每天都會(huì)為大家更新不同的知識(shí)點(diǎn)。