最近，发现主站nginx的log中有很多400的错误，每天有几千万条，故决定对产生400错误的原因进行排查。分析nginx log，发现这种无效的400请求，总是在一个正常访问之后产生，一般出现一个或者几个。log格式如下：

下面对这种情况进行分析：

一，nginx 400状态码含义

A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.

上面是http1.1的rfc关于host部分的解释，从上面我们了解到如果一个http1.1的请求没有host域，那么server应该给client段发送400的状态码，表明这个请求server不能处理。而对于nginx server来说，也遵循这样的方式，说明client发送了一个无效的请求，nginx server无法处理，故返回400的状态码。

参见：http://www.w3.org/Protocols/rfc2616/rfc2616.html

二，重现400请求

1，我使用pc端的chrome和ucweb浏览器，对网站进行访问，发现nginx log中的确会产生400的log，在nginx server端通过netstat看了一下client和server段建立的tcp连接数，每一个请求都是在3个以上。而是用ie和firefox浏览器对网站进行访问，发现不能重现400的log，在nginx server端通过netstat看了一下client和server段建立的tcp连接数，每一个请求都是只有1个。

2，使用telnet登录nginx的80端口

[@zw-81-90 ~]# telnet 10.13.82.96 80
Trying 10.13.82.96...
Connected to 10.13.82.96 (10.13.82.96).
Escape character is '^]'.
Connection closed by foreign host.

使用telnet连接后，直接断开连接即可

三，问题分析

第一种情况：

通过分析nginx的log，发现400请求中chrome和ucweb的ua比较多，通过查看相关的文章发现，这种请求和浏览器的自身策略有关系。

通常我们访问一个网站时，第一个获取的是一个html主文件，而里面链接了网页所需要的css、js、图片等其他媒体资源文件，而一般资源文件和主html文件是在一个域下的，而像chrome这种浏览器就会使用pre-connection，即在获取html之前就与nginx server建立多个的tcp连接，而不是等到获取到html文件之后再去连接服务器获取这个域名下的其他文件，因为连接服务器是需要消耗一些时间的，所以这项技术可以很大程度上加快网页的呈现速度。当然，浏览器同一时间针对同一域名下的请求也是有一定数量限制。

如果网页html链接的资源比较少，或者客户端有缓存，不需要连接下载，那么Chrome浏览器发出的5-6个连接很可能只有1个是需要的，其他的都得关闭掉，这样就产生了一个问题：连接了服务器，而没有发送任何请求，当然也没有host头了。对于这种情况，nginx是当做400错误来处理的，但由于连接已经关闭，错误信息不会发送到客户端，这就产生了日志文件中记录的400错误。

第二种情况：

使用telnet与nginx server建立个tcp连接，但是没有发送任何数据，当然也没有host头，之后四次挥手断开了连接。这种情况，nginx也是当作400的错误来处理的。使用tcpdump抓包，wireshark分析过程的截图如下：

当然，我们发现使用nagios的check_tcp插件对nginx server端口做检测或者使用keepalived的tcp_check功能对后端nginx端口的存活做检测，这两种情况都会在nginx log中产生400的请求。原因也很简单，就是第二种情况的理由，一般tcp check的方式，就是建立tcp连接，然后再reset或者四次挥手断开连接。

四，解决办法

nginx官方提供了一种方法，使用虚拟主机来匹配那些在nginx上没有匹配到host的请求。这样那些空host的请求，会被这个虚拟主机所匹配。如果不加这个虚拟主机的话，如果nginx上的虚拟主机没有对应client请求的host，nginx默认是用nginx.conf中第一个虚拟主机的处理，故400的请求就会出现在第一个虚拟主机的log中。虚拟主机配置如下：

server {

listen 80 default_server;

server_name _;

return 404;

access_log off;

}

总之，目前分析来看这类400的无效请求属于正常现象，可以用虚拟主机来消除400的请求。