未分类
从400错误看Nginx常见故障与修复
众所周知，Nginx是目前最流行的Web Server之一，也广泛应用于负载均衡、反向代理等服务，使用过程中可能因为对Nginx工作原理、变量含义、参数大小等问题的理解错误，导致Nginx工作异常。因此，本文将从一个Nginx错误代码400引发的故障入手，谈谈如何分析和修复常见的Nginx异常。 故障简述 小明某天中午在线优化一个敏感服务的Nginx配置时，发现5分钟内Nginx errorlog里出现了大量400错误，于是迅速回滚了Nginx配置。 故障详情 原来的Nginx配置存在重复或者需废弃的内容，于是在多次diff了新旧两份配置内容后，小明认为最新配置是不影响业务的，因此在线推送更新配置后，直接reload了Nginx，出于double check原则，在线观察了5分钟Nginx日志： 发现出现大量类似下面的400错误： 400错误的产生，很可能影响服务端或客户端的后续业务逻辑判断，因此需要引起重视。 处理过程 节点1 当时回滚配置后，小明先在搜索引擎查找了Nginx 400错误的可能原因和解决办法，初步确定有下面两种可能：1是空主机头，2是请求包头过大。 小明跟客户端同学确认了客户端请求方式，发现他们使用的是类似telnet的方式发起的http请求，类似下面的： 为了方便后续排查，小明参考线上环境临时搭建了一套Nginx测试环境，重现了故障： 后来小明了解到原来客户端不是从代码的http库调用， 而是按照上面的方式走TCP/telnet传递http参数来调用服务端http接口。但是为什么一样的客户端请求方式，旧配置完全ok，新配置则会出现大量400错误？ 节点2至此，小明怀疑自己没有完全diff出新旧两份配置的差别，于是他使用vimdiff再次对比新旧两份配置。下面仅贴出关键配置： 旧配置： 新配置： 本次排查中，小明考虑的重点是新配置里遗漏了某些配置，于是他把location ~ (.*)的相关逻辑加上，发现问题依旧： 节点3 既然前面往缺失配置的思路走不通，下面就按照新增配置的思路排查，结果发现新配置增加了一些包头信息，小明怀疑是请求包过大，于是优先排查了Nginx针对包头大小的设置，其中有这么几个配置： client_header_buffer_size：默认是1k，所以header小于1k的话是不会出现问题的。 large_client_header_buffers：该命令用于设置客户端请求的Header头缓冲区的大小，默认值为4KB。 客户端请求行不能超过large_client_header_buffers指令设置的值，客户端请求的Header头信息不能大于large_client_header_buffers指令设置的缓冲区大小，否则会报“Request URL too large”（414）或者“Bad-request”(400)错误，如果客户端Cookie信息较大，则须增加缓冲区大小。于是小明将client_header_buffer_size和large_client_header_buffers都设置为128k。结果问题也重现了。 接下来，小明发现新配置中多了“proxy_set_header Host $http_host;”查找了Nginx官方文档发现跟$http_host类似功能的还有$server_name和$host等变量，在他将$http_host更换成$host后，问题修复了。 原因分析 根据Nginx官方文档介绍，400状态码含义如下： 上面是http1.1的rfc关于host部分的解释，从上面我们了解到如果一个http1.1的请求没有host域，那么server应该给client段发送400的状态码，表明这个请求server不能处理。而对于Nginx server来说，也遵循这样的方式，说明client发送了一个无效的请求，Nginx server无法处理，于是返回了400的状态码。 另外，关于$host和$http_host这两个变量的区别如下： 本次故障中，客户端的调用方式没有使用host 参数，传递了空的Host头给服务端，一旦Nginx设置了proxy_set_header Host $http_host，空Host头就传给了后端。然而，在http 1.1的规范中，Host只要出现空，就会返回400，所以出现了这个故障。而对于需要在Host字段里带上端口信息的，则仍需要配置proxy_set_header Host $http_host。 最后，需要注意的是，400错误不一样会影响业务，需要看具体的业务处理逻辑，比如使用nagios的check_tcp插件对Nginx Read more…