服务器日志里出现大量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