做网站的人，谁没被502折磨过呢。那感觉就像你好端端走着路，突然被绊了一跤，爬起来一看啥事儿没有，过会儿又绊一次。Nginx给你吐个502 Bad Gateway，意思翻译过来就是：我尽力了，但你后面那哥们儿（PHP-FPM）没理我。很多人一看502就慌，其实它背后就那么几件事，挨个看就行。
先搞清楚502不是Nginx自己的锅
这个观念得先立起来。Nginx只是个传话的，你访问网站，它把请求转给PHP-FPM处理，PHP-FPM半天不回话或者直接挂了，Nginx就只能给你个502。所以排查的时候别盯着Nginx配置翻来翻去，重点看后端，方向对了才能找到病根儿。
第一件事：看看PHP-FPM还活着没
直接上命令，一条一条来，先看服务状态，再看进程在不在，最后看它监听的那个9000端口还通不通：
systemctl status php-fpm 看看有没有报红；ps aux | grep php-fpm 数数进程；ss -tlnp | grep 9000 确认端口还活着。要是服务没起，直接systemctl start php-fpm拉起来，好多人到这一步就完事了，网站立刻能开。
第二件事：翻日志，别瞎猜
进程活着还报502，那就得看日志了，日志这玩意儿比啥都诚实。Nginx的error.log和PHP-FPM自己的日志都翻一翻，tail -n 100一下就行。日志里要是写着connect() failed，那就是连不上PHP-FPM；写着execution timed out，就是脚本跑超时了；写着out of memory或者直接被kill，那基本就是内存不够，进程被系统干掉了。
日志具体在哪儿？Nginx一般是/var/log/nginx/error.log，PHP-FPM的看你的配置文件，常见的是/var/log/php-fpm/www-error.log，Debian系有时候在/var/log/php7.x-fpm.log这种路径下。实在找不到就grep一下配置文件里的error_log字段，它会在你配置的那个路径写日志。反正找到日志你就成功一半了，剩下的照着提示处理就行。
第三件事：进程池配得合不合理
日志里要是一堆超时或者等待，大概率是php-fpm的进程池配置跟你服务器配置不匹配。max_children这个参数，好多人喜欢往大了调，觉得越大越能扛并发——我跟你说，这是个误区。每个php-fpm进程都吃内存的，你1G内存的小机器硬开到50个进程，内存直接爆，然后OOM把进程全杀了，502反而更频繁。这坑我自己也踩过，当年一台破机器上跑论坛，调完参数当晚就崩了。
还有个容易漏的原因：内存悄悄被吃光
有一种502特别阴，就是它专挑你业务高峰期来，平时好好的，一忙就挂。这种时候别光看PHP-FPM，去看看系统内存。很多老程序有内存泄漏的毛病，进程跑得越久吃得越多，吃到系统忍无可忍，直接把进程杀了，那可不就502了嘛。解决思路是给php-fpm配上pm.max_requests，让每个进程处理够一定数量的请求后自动回收重建，等于定期给进程洗个澡，内存就泄不起来了。
502和504还老被人搞混，顺手说下
502是Nginx压根没等到后端回应，504是后端回应了但处理超时。一个像打电话没人接，一个像接起来半天不说话。排查思路不一样：502多查进程和连接，504多查脚本执行时间和慢查询。把这俩分清楚，跟别人聊起来也显得专业，是吧。
最后，别忘了业务本身
配置没问题还老502，那八成是业务的事儿：数据库有慢查询拖后腿、程序里调了个永远等不到响应的第三方接口、或者干脆是被人刷了。这种时候光调参数是治标，得回去看慢查询日志、给接口加超时、上点限流。反正记住一句话：502是表，根子往往在后面，一层一层剥开看，没多难的。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
