NGINX 502 Bad Gateway错误以前遇到过，不过不是常发生，所以也没什么注意，不过今天在网上看到一个方法错误处理方法，觉得很好，于是记录下来，留待以后备用，或者有机会实践下。
记录：
一般nginx搭配php都采用这样的方式：
location ~ \.php$ {
proxy_pass http://localhost:9000;
fastcgi_param SCRIPT_FILENAME /data/_hongdou$fastcgi_script_name;
include fastcgi_params;
}这个方式只能连接到一组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 backend;
fastcgi_param SCRIPT_FILENAME /data/_hongdou$fastcgi_script_name;
include fastcgi_params;
}检查配置结果正确，能跑起来；同时在服务器上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 502 Bad Gateway错误处理还可以这样啊！
好久没去搞技术了，发觉技术的东西进步得真快啊！！！