博客访问： 622804
博文数量： 130
博客积分： 4192
博客等级： 上校
技术积分： 1212
注册时间：
认证徽章：
梦想还是要有的，万一实现 了呢？
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
我在做nginx+php网站测试时，发现错误信息如下：
curl localhost/2.php
nginx/1.2.9
在百度上查找错误信息：nginx+php 错误502 bad gateway时，也没有找到好的方法，
这时我分析我的nginx日志文件，我的nginx日志文件存放在/usr/local/nginx/logs/nginx_error.log,发现有如下一行的错误：
15:12:26 [crit] 2967#0: *9
connect() to unix:/tmp/php-fcgi.sock
failed (13: Permission denied) while connecting to upstream, client:
127.0.0.1, server: localhost, request: "GET /2.php HTTP/1.1",
upstream: "fastcgi://unix:/tmp/php-fcgi.sock:", host:
"localhost"
特别是：connect() to unix:/tmp/php-fcgi.sock failed (13: Permission denied) while connecting to upstream出错，
然后我检查我的nginx的sock文件的权限：
srwxrwxrwx 1 mysql mysql&&& 0 Feb 22 00:58 mysql.sock
drwxr-xr-x 3 root& root& 4096
Feb 16 13:59 pear
srw-rw---- 1 root& root&&&&
0 Feb 22 00:58 php-fcgi.sock
修改后的权限
[root@centos3 nginx]# chmod 777
/tmp/php-fcgi.sock
[root@centos3 nginx]# ll /tmp
srwxrwxrwx 1 mysql mysql&&& 0 Feb 22 00:58 mysql.sock
drwxr-xr-x 3 root& root&
4096 Feb 16 13:59 pear
srwxrwxrwx 1 root& root&&&&
0 Feb 22 00:58 php-fcgi.sock
显示的结果：
# curl localhost/2.php
This is a test
[root@centos3 nginx]#
这时nginx的502错误已解决了；
阅读(590) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。adpanshi 的BLOG
用户名：adpanshi
文章数：85
评论数：-1
访问量：25760
注册日期：
阅读量：5863
阅读量：12276
阅读量：327537
阅读量：1036002
51CTO推荐博文
排除进程数不够，php执行超时的原因。查看日志发现有502记录的错误，修改错误级别，改为error级error_log 级别分为 debug, info, notice, warn, error, crit &默认为crit, 该级别在日志名后边定义格式如下：error_log 级别分为 debug, info, notice, warn, error, crit &默认为crit, 该级别在日志名后边定义格式如下：error_log &/your/path/error. &crit 记录的日志最少，而debug记录的日志最多。如果你的nginx遇到一些问题，比如502比较频繁出现，但是看默认的error_log并没有看到有意义的信息，那么就可以调一下错误日志的级别，当你调成error级别时，错误日志记录的内容会更加丰富。 查看错误日志connect() to unix:/tmp/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstreamUnix域Socket因为不走网络，的确可以提高Nginx和php-fpm通信的性能，但在高并发时会不稳定。Nginx会频繁报错：connect() to unix:/dev/shm/php-fcgi.sock failed (11: Resource temporarily unavailable) while connecting to upstream将socket改为端口，最好是起两个实例upstream php{server 127.0.0.1:9001;server 127.0.0.1:9002;} location ~ .*\.(php|php5)?$ & &{ & & & fastcgi_pass & & & & fastcgi_index index. & & & fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_ & & & include fastcgi_ & &}/data/nginx/sbin/nginx -t/data/nginx/sbin/nginx -e reload再次观察错误日志，没发现502了，问题解决。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)当前位置：&>&&>&
Nginx 502错误原因和解决方法总结
时间： 08:10:01    来源：服务器之家    投稿：root
一、NGINX 502错误排查
NGINX 502 Bad Gateway错误是FastCGI有问题，造成NGINX
502错误的可能性比较多。将网上找到的一些和502 Bad
Gateway错误有关的问题和排查方法列一下，先从FastCGI配置入手：
1.FastCGI进程是否已经启动
2.FastCGI worker进程数是否不够
运行 netstat -anpo | grep “php-cgi” | wc -l
判断是否接近FastCGI进程，接近配置文件中设置的数值，表明worker进程数设置太少
3.FastCGI执行时间过长
根据实际情况调高以下参数值
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
4.FastCGI Buffer不够
nginx和apache一样，有前端缓冲限制，可以调整缓冲参数
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
5.Proxy Buffer不够
如果你用了Proxying，调整
proxy_buffer_size&& 16k;
proxy_buffers && 4 16k;
6.https转发配置错误
正确的配置方法
location /myproj/repos {
set $fixed_destination $http_
if ( $http_destination ~* ^https(.*)$ )
set $fixed_destination http$1;
proxy_set_header Host $
proxy_set_header X-Real-IP $remote_
proxy_set_header Destination $fixed_
proxy_pass http://subversion_
当然，还要看你后端用的是哪种类型的FastCGI，我用过的有php-fpm，流量约为单台机器40万PV(动态页面),
现在基本上没有碰到502。
7.php脚本执行时间过长
将php-fpm.conf的&value
name="request_terminate_timeout"&0s&/value&的0s改成一个时间
二、Nginx 413错误的排查:修改上传文件大小限制
在上传时nginx返回了413错误，查看log文件，显示的错误信息是:”413 Request Entity Too Large”,
于是在网上找了下“nginx 413错误”发现需要做以下设置：
在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
三、Nginx 400错误排查：HTTP头/Cookie过大
今天有人汇报nginx的HTTP400错误，而且这个HTTP400错误并不是每次都会出现的，查了一下发现nginx400错误是由于request
header过大，通常是由于cookie中写入了较长的字符串所引起的。
解决方法是不要在cookie里记录过多数据，如果实在需要的话可以考虑调整在nginx.conf中的client_header_buffer_size(默认1k)
若cookie太大，可能还需要调整large_client_header_buffers(默认4k)，该参数说明如下：
请求行如果超过buffer，就会报HTTP 414错误(URI Too Long)
nginx接受最长的HTTP头部大小必须比其中一个buffer大，否则就会报400的HTTP错误(Bad Request)。
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Nginx 502 Bad
Gateway的含义是请求的PHP-CGI已经执行，但是由于某种原因（一般是读取资源的问题）没有执行完毕而导致PHP-CGI进程终止。
Nginx 504 Gateway
Time-out的含义是所请求的网关没有请求到，简单来说就是没有请求到可以执行的PHP-CGI。
解决这两个问题其实是需要综合思考的，一般来说Nginx 502 Bad
Gateway和php-fpm.conf的设置有关，而Nginx 504 Gateway
Time-out则是与nginx.conf的设置有关。
而正确的设置需要考虑服务器自身的性能和访客的数量等多重因素。
以我目前的服务器为例子CPU是奔四1.5G的，内存1GB，CENTOS的系统，访客大概是50人左右同时在线。
但是在线的人大都需要请求PHP-CGI进行大量的信息处理，因此我将nginx.conf设置为：
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
fastcgi_buffer_size 128k;
fastcgi_buffers 8 128k;#8 128
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_intercept_
这里最主要的设置是前三条，即
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
这里规定了PHP-CGI的连接、发送和读取的时间，300秒足够用了，因此我的服务器很少出现504 Gateway
Time-out这个错误。最关键的是php-fpm.conf的设置，这个会直接导致502 Bad Gateway和504
Gateway Time-out。
下面我们来仔细分析一下php-fpm.conf几个重要的参数：
php-fpm.conf有两个至关重要的参数，一个是”max_children”,另一个是”request_terminate_timeout”
我的两个设置的值一个是”40″，一个是”900″，但是这个值不是通用的，而是需要自己计算的。
计算的方式如下：
如果你的服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点，也就是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死那么就建议你给”request_terminate_timeout”赋一个值，这个值可以根据你服务器的性能进行设定。一般来说性能越好你可以设置越高，20分钟-30分钟都可以。由于我的服务器PHP脚本需要长时间运行，有的可能会超过10分钟因此我设置了900秒，这样不会导致PHP-CGI死掉而出现502
Bad gateway这个错误。
而”max_children”这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少。设置”max_children”也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右，因此我的”max_children”我设置成40个，20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内，低于我的有效内存1Gb。而如果我的”max_children”设置的较小，比如5-10个，那么php-cgi就会“很累”，处理速度也很慢，等待的时间也较长。如果长时间没有得到处理的请求就会出现504
Gateway Time-out这个错误，而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad
gateway这个错误。
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
nginx中配置php fastcgi组解决莫名其妙的502 Bad Gateway错误
一般nginx搭配php都采用这样的方式：
location ~ .php$ {
proxy_pass && &&&
http://localhost:9000;
fastcgi_param&& SCRIPT_FILENAME&&
/data/_hongdou$fastcgi_script_
include && &&& fastcgi_
这个方式只能连接到一组spawn-fcgi开启的fastcgi，在服务器负载稍高时常常出现502 bad
gateway错误。
起先怀疑这是php-cgi的进程开得太少，增加后仍然有反映时常有错，偶然间发现php-cgi会报出这样的错误：
zend_mm_heap corrupted
看来是php-cgi在执行某些代码时有问题，以致于该线程中止。
在服务器上可能还会看到php-cgi进程在不断变少，估计是出现错误的php-cgi的进程自动退出了。
php的问题总是不太容易能解决，所以在nginx方面想想办法，nginx的好处是它总是能爆出一些稀奇古怪的做法出来。
在nginx的proxy中，规避莫名其妙错误的办法无非是proxy到一个upstream的服务器组中，然后配置
proxy_next_upstream，让nginx遇到某种错误码时，自动跳到下一个后端上。这样，应用服务器即使不稳定，但是在nginx后面就变成了稳定服务。想到nginx的fastcgi和proxy是一路东西，所以proxy能用的经验，移植到fastcgi也能跑得起来。
照着这个思路，用spawn-fcgi多开同样一组php进程，所不同的仅仅是端口：
spawn-fcgi -a 127.0.0.1 -p 9000 -u nobody -f php-cgi -C 100
spawn-fcgi -a 127.0.0.1 -p 9001 -u nobody -f php-cgi -C 100
然后把fastcgi的这段配置改成用upstream的方式：
upstream backend {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
location ~ .php$ {
fastcgi_pass && &&&
fastcgi_param&& SCRIPT_FILENAME&&
/data/_hongdou$fastcgi_script_
include && &&& fastcgi_
检查配置结果正确，能跑起来；同时在服务器上netstat -n|grep 9000和grep
9001都有记录，证明连接无误；在前台查阅页面，一切运行正常。
这个配置是最简单的配置，既然能连接上upstream，那么很显然upstream的一些东西都可以拿来用，比如ip_hash、weight、max_fails等。
这样的配置在单机下不知能不能共享session，没有测试，如果有问题，可以加上ip_hash，或者配置php把session存进memcached中。
然后就是fastcgi_next_upstream的配置，nginx
wiki中没有介绍到这个配置，查了一下，在nginx的CHANGES中有提到，而且出生年月是和proxy_next_upstream一样的。既然如此，那就照proxy_next_upstream一样配吧。一般按默认的值error
timeout就可以工作，因为php出现502错误的异常是返回的500错误，所以我把fastcgi_next_upstream定为：
fastcgi_next_upstream error timeout invalid_header http_500;
通过这个配置，就可以基本杜绝任何时常性的500错误，出问题的几率会变小很多，如果客户反映仍然激烈，那么就多增加几组fastcgi进程。
以上配置能够杜绝由于php所引起的“莫名其妙”的时常性的502错误，同时可使nginx搭配php比从前方式更为强悍。假如nginx还是返回502错误，那这次就一定是出现服务器挂掉或其它严重问题的了。
转载请注明原文地址：您所在的位置： &
Nginx asp错误502的解决方法
Nginx asp错误502的解决方法
Nginx asp需要我们不断的解决相关的问题，当你遇到错误502的时候是不是有些懵呢？下面我们就详细的看看如何解决Nginx asp错误的方法。
初次使用Nginx很多东西不懂。尤其是 asp的相关应用更是一头雾水。当你一不小心就出现了502错误，应该怎么办呢？其实还是很简单的，下面就详细呃介绍有关Nginx asp的相关错误问题。
在网上搜了一圈，都是FastCGI，因为通过抓包，调试，发现出现502错误并不是nginx的主要原因，看看我的配置，原来仅将aspx交给iis处理，ashx,ascx等都没转，因此修改配置：
location&~*&/.(asp|aspx|asa|ashx|axd|ascx|asax|asmx)$&{&root&/host/wwwroot/&index&default.aspx&index.asp&index.&proxy_pass&http://127.0.0.1:81;&proxy_set_header&X-Real-IP&$remote_&}&
顺便把网上FASTCGI的也转一次：
NGINX 502 Bad Gateway错误是FastCGI有问题，造成NGINX 502错误的可能性比较多。将网上找到的一些和502 Bad Gateway错误有关的问题和排查方法列一下，先从FastCGI配置入手：
1.查看FastCGI进程是否已经启动。NGINX 502错误的含义是sock、端口没被监听造成的。我们先检查fastcgi是否在运行
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;&
4.头部太大nginx和apache一样，有前端缓冲限制，可以调整缓冲参数
fastcgi_buffer_size&32k; &fastcgi_buffers&8&32k; &如果你使用的是nginx的负载均衡Proxying，调整 &proxy_buffer_size&16k; &proxy_buffers&4&16k;&
5.https转发配置错误：正确的配置方法
server_name&; &location&/myproj/repos&{ &set&$fixed_destination&$http_ &if&(&$http_destination&~*&^https(.*)$&) &{ &set&$fixed_destination&http$1; &} &proxy_set_header&Host&$ &proxy_set_header&X-Real-IP&$remote_ &proxy_set_header&Destination&$fixed_ &proxy_pass&http://subversion_ &}&
当然，还要看你后端用的是哪种类型的FastCGI，我用过的有php-fpm，流量约为单台机器40万PV(动态页面), 现在基本上没有碰到Nginx asp的错误502。
【编辑推荐】
【责任编辑： TEL：（010）】
关于的更多文章
想要理解大数据，使之更贴近大多数人，最重要的手段的之一就是数
作为移动开发者，WOT2016移动互联网技术峰会，绝对有你不得不来的理由。
讲师： 26人学习过讲师： 14人学习过讲师： 35人学习过
自从MySQL被Oracle收购以后，PostgreSQL逐渐成为开源
1314的的日子在，在忙忙碌碌中过去了。一周五天，中间
本期开发频道重点推荐是2013年开发频道重点推荐的最后
本书是针对全国计算机技术与软件专业技术资格（水平）考试而编写的，书中详尽分析与解答了2006年上半年的程序员级、软件设计师级
51CTO旗下网站现在位置：
恋香缘基于云计算随机推荐