从400错误引发的故障入手，谈谈如何分析和修复常见的Nginx异常(2)

本次故障中,客户端的调用方式没有使用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 server端口做检测或者使用keepalived的tcp_check功能对后端Nginx端口的存活做检测,这两种情况都会在Nginx errorlog中产生400的请求.

原因也很简单,就是一般tcp check的方式,就是建立tcp连接,但是没有发送任何数据,当然也没有Host头,然后再reset或者四次挥手断开连接.

经验教训

运维规范

细心的同学会发现本次配置更新是在大中午操作,而且也没有在测试环境测试通过,这在流程上是不严谨的.虽然Nginx等web服务的配置更新基本上通过热更就可以了,但没有灰度测试或者在测试环境测试,一是无法提前发现问题,二是无法控制业务影响.所以,在运维规范上看,即使是热更也应当在测试环境测试正常后再同步到线上,其他的更新则应在业务低谷时操作.

技术学习方法

本次故障的产生,很大程度上就是运维同学不理解Nginx变量的定义和区别,直接从搜索引擎上找了些配置,检查觉得正确就推到了线上.这里仍需要重申的是,以官方文档为准!互联网上很多知识或者配置有各种各样的问题,随时都有暗坑在里边,只有啃过官方文档才能避免误读.

Web日志分析

针对这里的Nginx错误日志查看,我们看到小明是用在线命令查看的,其实现在有很多web日志分析工具或系统,比如ELK(ElacticSearch+LogStash+Kibana),只需要配置好grok正则,是可以通过可视化界面实时监控web服务质量的.

引申

上面介绍了Nginx 400错误的可能原因和解决办法,但实际工作中,我们遇到的可不止这么一点.于是,由此引申出去的是,针对那些Nginx常见错误如何去排查和解决.

403错误

403是很常见的错误代码,一般就是未授权被禁止访问的意思.

可能的原因有两种：
Nginx程序用户无权限访问web目录文件
Nginx需要访问目录,但是autoindex选项被关闭

修复方法：
授予Nginx程序用户权限读取web目录文件
设置autoindex目录为on

413错误

在上传时Nginx返回了413错误：“413 Request Entity Too Large”,这一般就是上传文件大小超过Nginx配置引起.

修复方法：
在Nginx.conf增加client_max_body_size的设置,这个值默认是1M,可以增加到8M以提高文件大小限制；
如果运行的是php,那么还要检查php.ini,这个大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大,这样就不会因为提交数据大小不一致出现的错误.

post_max_size = 8M
upload_max_filesize = 2M

502错误

Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)没有执行完毕而导致PHP-CGI进程终止.一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关.

修复方法：
1、查看FastCGI进程是否已经启动

ps -aux | grep php-cgi

2、检查系统Fastcgi进程运行情况

除了第一种情况,fastcgi进程数不够用、php执行时间长、或者是php-cgi进程死掉也可能造成Nginx的502错误.

运行以下命令判断是否接近FastCGI进程,如果fastcgi进程数接近配置文件中设置的数值,表明worker进程数设置太少.

netstat -anpo | grep “php-cgi” | wc -l

3、FastCGI执行时间过长

根据实际情况调高以下参数值

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

504错误

Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到,简单来说就是没有请求到可以执行的PHP-CGI.

Nginx 504 Gateway Time-out一般与Nginx.conf的设置有关.

头部太大这种情况可能是由于Nginx默认的fastcgi进程响应的缓冲区太小造成的,这将导致fastcgi进程被挂起,如果你的fastcgi服务对这个挂起处理的不好,那么最后就极有可能导致504 Gateway Time-out.

默认的fastcgi进程响应的缓冲区是8K,可以调大以下参数：

fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;
fastcgi_busy_buffers_size 由 128K 改为 256K；
fastcgi_temp_file_write_size 由 128K 改为 256K.

此外,也可能是php-cgi的问题,需要修改php.ini的配置：

将max_children由之前的10改为30,这样操作是为了保证有充足的php-cgi进程可以被使用.
将request_terminate_timeout由之前的0秒改成60秒,这样使php-cgi进程处理脚本的超时时间提高到60秒,可以防止进程被挂起以提高利用效率.

参考资料

原文出处：http://dbaplus.cn/news-21-1129-1.html
Nginx 400状态码排查
http://www.68idc.cn/help/jiabenmake/qita/20140707115201.html
Nginx变量大全
https://openresty.org/download/agentzh-Nginx-tutorials-en.html
Nginx报502、504、400、413错误
http://blog.csdn.net/miltonzhong/article/details/9195855

（编辑：ASP站长网）