Nginx服务器中414错误和504错误的配置解决方法

 更新时间:2015年12月30日 17:36:02   作者:mood  
这篇文章主要介绍了Nginx服务器中414错误和504错误的配置解决方法,分别对应Request-URI Too Large和Gateway Time-out这样的错误提示,需要的朋友可以参考下

414 Request-URI Too Large

#客户端请求头缓冲区大小,如果请求头总长度大于小于128k,则使用此缓冲区,
#请求头总长度大于128k时使用large_client_header_buffers设置的缓存区
client_header_buffer_size 128k;

#large_client_header_buffers 指令参数4为个数,128k为大小,默认是8k。申请4个128k。
large_client_header_buffers 4 128k;

当http 的URI太长或者request header过大时会报414 Request URI too large或400 bad request错误。

可能原因

场景1.cookie中写入的值太大造成的,因为header中的其他参数的size一般比较固定,只有cookie可能被写入较大的数据

场景2.请求参数太长,比如发布一个文章正文,用urlencode后,使用get方式传到后台。

GET http://www.264.cn/ HTTP/1.1
Host: www.264.cn
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31 
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: bdshare_firstime=1363517175366; 
If-Modified-Since: Mon, 13 May 2013 13:40:02 GMT

当请求头过大时,超过large_client_header_buffer时,
nginx可能返回"Request URI too large" (414)或者"Bad-request"(400)错误,

如上例HTTP请求头由多行构成,
其中"GET http://www.264.cn/ HTTP/1.1"表示Request line

当Request line的长度大于large_client_header_buffer的一个buffer(128k)时,nginx会返回"Request URI too large" (414)错误,对应上面的场景2。

请求投中最长的一行也要小于large_client_header_buffer,当不是Request line的最长行大于一个buffer(128k)时,会返回"Bad-request"(400)错误,对应上面的场景1。

解决办法:这时可以调大上述两个值。

client_header_buffer_size 512k;
large_client_header_buffers 4 512k;

504 Gateway Time-out
之前网站一直是使用nginx做代理后端的apache运行php来提供服务。

apache经常会不定期不定时间的出现不能服务失去响应,然后nginx出现"504 Gateway Time-out"

查看错误日志也看不到任何东西,以为是apache的bug(其实不是,下面会说原因)。

也许年龄大了人就不爱折腾,愿意保持原状不动,使用监控工具,每次收到报警后都重新启动apache勉强维持着。

终于有一天我烦了,不就是处理php吗,我不用apache总行了吧,一怒之下使用源安装php-fpm转移到php-fpm来运行php。

安装php并不麻烦,使用源安装还是很顺利的,唯一需要做的就是设置php worker工作进程的日志输出php错误日志。


一切准备就绪后把原来的proxy_pass换成fastcgipass就可以了。

upstream apachephp {
  server www.quancha.cn:8080; #Apache1
}

....
proxy_pass http://apachephp;

替换成成

upstream php {
    server 127.0.0.1:9000;
}

...
fastcgi_pass php;

就可以把apache上跑的php迁移到php-fpm上来跑。

原以为这样就可以高枕无忧了,迁移完成是也确实没什么问题,但是如果你不去分析问题的根本原因在哪。

问题还是会找上门来,第二天nginx又报了504的gateway timeout。

这回没apache什么事了吧,apache总算撇清了关系。

那应该还是在nginx和php-fpm身上,查看nginx的错误日志,可以看到

[error] 6695#0: *168438 upstream timed out (110: Connection timed out) while reading response header from upstream,
...
request: "GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.quancha.cn"

看到这里基本上就排除了nginx嫌疑,nginx是在等待php处理"GET /kd/open.php?company=chinapost&number=PA24977020344 HTTP/1.1"超时退出了。

马上重启php-fpm,问题没有了,网站可以访问了。

再次访问该页面,依然没有响应,但同时访问别的页面正常,该页面刷新几次后,整个网站都是bad gateway timeout了。

问题就缩小到这个php脚本上了。

netstat -napo |grep "php5-fpm" | wc -l

查看php工作进程已经达到了配置文件里的上限10,有种感觉就是大家都被open.php这个脚本卡住了。

这个脚本是干什么的呢?这个脚本就是采集快递信息的,里面用到了php_curl。

PHP脚本如果执行时间超过php.ini中的配置项max_execution_time不出结果就会强制退出。

查看了php.ini中max_execution_time确实配了,值为30。

万能google派上用场了,经过不断google后得到下面这句话

set_time_limit()函数和配置指令max_execution_time只影响脚本本身执行的时间。任何发生在诸如使用system()的系统调用,流操作,数据库操作等的脚本执行的最大时间不包括其中,当该脚本已运行。

就是说如果脚本中执行了其它操作的时间是不计在脚本运行时间当中的,如果你没设置超时,那么php就会一直等待调用的结果。

查看open.php源文件一看,果然没有设置curl的超时时间。

增加如下两行,重新刷新,后问题解决了。

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10); //timeout on connect
curl_setopt($ch, CURLOPT_TIMEOUT, 10); //timeout on response

当然,除了这种方法外,php-fpm里也提供参数供我们强制杀死长时间无结果的进程,只是该参数默认没打开。

php-fpm的配置文件里可以设置一个参数request_terminate_timeout,请求终止的超时时间,当请求执行超过这个时间就会被kill。

同时它还有个参数request_slowlog_timeout,用来记录慢请求日志的。

命令行运行php的话,可以使用这段代码

$real_execution_time_limit = 60; //时间限制

if (pcntl_fork())
{
// some long time code which should be
// terminated after $real_execution_time_limit seconds passed if it's not
// finished by that time
}
else
{
sleep($real_execution_time_limit);
posix_kill(posix_getppid(), SIGKILL);
}

相关文章

  • nginx 内置变量详解及隔离进行简单的拦截

    nginx 内置变量详解及隔离进行简单的拦截

    这篇文章主要介绍了nginx 隔离进行简单的拦截详解的相关资料,这里对nginx内置变量进行了简单的介绍并对隔离拦截进行了详解, 需要的朋友可以参考下
    2016-12-12
  • WordPress中开启多站点支持及Nginx的重写规则配置

    WordPress中开启多站点支持及Nginx的重写规则配置

    这篇文章主要介绍了WordPress中开启多站点支持及Nginx的重写规则配置方法,在同一个WordPress软件中开启的多个站点如果需要绑定不同域名的话也可以使用WordPress MU Domain Mapping插件,需要的朋友可以参考下
    2016-03-03
  • Nginx中定义404页面并且返回404状态码的正确方法

    Nginx中定义404页面并且返回404状态码的正确方法

    这篇文章主要介绍了Nginx中定义404页面并且返回404状态码的正确方法,本文在一次AJAX调用时发现了这个问题,服务器返回了一个404页页但没有返回404状态码,需要的朋友可以参考下
    2014-08-08
  • 从Nginx切换到Tengine的步骤分享

    从Nginx切换到Tengine的步骤分享

    由淘宝网发起的Web服务器 Tengine 可以被看作一个更好的Nginx,或者是Nginx的超集。它在Nginx的基础上,针对大访问量网站的需求,添加了很多高级功能和特性
    2012-11-11
  • Nginx为已安装nginx动态添加模块

    Nginx为已安装nginx动态添加模块

    本篇文章主要介绍了Nginx之为已安装nginx动态添加模块的方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-04-04
  • nginx反向代理导致session失效的问题解决

    nginx反向代理导致session失效的问题解决

    这篇文章主要介绍了nginx反向代理导致session失效的问题解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-06-06
  • Debian7编译安装nginx简明教程

    Debian7编译安装nginx简明教程

    这篇文章主要介绍了Debian7编译安装nginx简明教程,本文直接给出操作命令和步骤,需要的朋友可以参考下
    2015-03-03
  • nginx 如何实现if嵌套的方法示例

    nginx 如何实现if嵌套的方法示例

    这篇文章主要介绍了nginx 如何实现if嵌套的方法示例,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2019-11-11
  • 在Nginx服务器下配置StartSSL和SSL的教程

    在Nginx服务器下配置StartSSL和SSL的教程

    这篇文章主要介绍了在Nginx服务器下配置StartSSL和SSL的教程,其中申请证书的步骤确实比较麻烦一些,不过出于安全考虑:p需要的朋友可以参考下
    2015-07-07
  • Nginx的安装和多域名配置的实现方法

    Nginx的安装和多域名配置的实现方法

    这篇文章主要介绍了Nginx的安装和多域名配置的实现方法,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-09-09

最新评论