工作中经常会碰到502 Bad Gateway和504 Gateway Time-out错误，下面以Nginx+PHP-FPM来分析下这两种常见错误的原因和解决方案。
1、502 Bad Gateway错误
当出问题后不要慌张，首先查看日志，跟进报错error来定位问题点，查看最近变更文件，查看端口及网络是否正常，排出病毒×××等，然后根据nginx--php--mysql等交互原理，进行逐一排查，处理问题，原理图如下：
2、下面简单列举工作中遇到的集中情况
1，iptables 防火墙策略，是否有阻止端×××互
2，nginx 对日志目录是否有读写权限，访问超时
3，php运行较慢，并超出php-fpm.conf的request_terminate_timeout设置的秒数”max_children”
4，nginx服务器的并发连接数超过了其承载量，netstat -an 查看流量情况
5，浏览器是否开启代理
6， 磁盘空间原因：
磁盘空间不足，如mysql日志占用大量空间清理一下磁盘上的文件，有部分剩余空间，重启即可恢复。
7，程序运行原因：
查看php-cgi或php-fpm进程是否在运行
8，调优不当原因：
将nginx.conf里的
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout都调大一点。
9，phpcgi进程不足原因
在安装好使用过程中出现502问题，一般是因为默认php-cgi进程是5个，可能因为phpcgi进程不够用而造成502，需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加，如果php已升级到5.3.*以上且使用的是dynamic模式，需要调整pm.max_spare_servers参数的值。
也有可能是max_requests值不够用。
2、504 Gateway Time-out错误
PHP-FPM设置的脚本最大执行时间已经够长了，但执行耗时PHP脚本时，发现Nginx报错从502变为504了。这是为什么呢？
因为我们修改的只是PHP的配置，Nginx中也有关于与上游服务器通信超时时间的配置factcgi_connect/read/send_timeout。
以Nginx超时时间为90秒，PHP-FPM超时时间为300秒为例，报504 Gateway Timeout错误时的Nginx错误访问日志如下：
2013/09/19 00:55:51 [error] 27600#0: *78877 upstream timed out (110: Connection timed out) while reading response header from upstream,
client: 192.168.1.101, server: test.com, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",
host: "test.com", referrer: "http://test.com/index.php"
调高这三项的值(主要是read和send两项，默认不配置的话Nginx会将超时时间设为60秒)之后，504错误也解决了。
而且这三项配置可以配置在http、server级别，也可以配置在location级别。担心影响其他应用的话，就配置在自己应用的location中吧。
要注意的是factcgi_connect/read/send_timeout是对FastCGI生效的，而proxy_connect/read/send_timeout是对proxy_pass生效的。
配置举例：
location ~ .php$ {
root /home/cdai/test.com;
include fastcgi_params;
fastcgi_connect_timeout 180;
fastcgi_read_timeout 600; #读取超时时间
fastcgi_send_timeout 600; #通信超时时间
fastcgi_pass unix:/dev/shm/php-fcgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/cdai/test.com$fastcgi_script_name;
}