服務器中的錯誤記錄類似于這種：

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都調大，可緩解此問題。