网站报错502咋解决？别慌，这篇给你讲明白

昨天半夜三点多，有个朋友突然给我发消息，说他的网站挂了，打开就是一行白底黑字的“502 Bad Gateway”。他问我是不是服务器被攻击了，语气还挺急。其实502这个报错，说大不大，说小也不小，今天就用大白话跟大家聊聊它到底是怎么回事，以及该怎么一步步排查。

先说结论：502错误本质上不是你的网站程序自己报的错，而是“中间人”传话失败了。你可以把整个访问链路想象成送快递：用户是收件人，浏览器是快递员，服务器上的Nginx或者Apache是中转站，后端的PHP、Java、Node这些程序才是真正发货的仓库。502的意思就是，中转站联系不上仓库，或者仓库半天没反应，中转站只好跟用户说“对不起，没拿到货”。

那具体怎么排查呢？按顺序来，别乱。

第一步，先看后端服务还活着没。最常见的原因就是PHP-FPM、Tomcat、Gunicorn这类进程挂了或者卡死了。登录服务器，用ps aux | grep php-fpm或者systemctl status看一下进程状态。如果是挂了的，重启一下大概率就能恢复。但要注意，重启只是止血，得看看日志里有没有崩溃原因，不然过一会儿又挂。

第二步，看是不是资源不够了。CPU跑满、内存耗尽、连接数打满，都会让后端来不及响应，中转站等超时了就给你甩个502。用top、free -h、df -h扫一眼，心里就有数了。特别是小内存的云服务器，跑个数据库加应用，内存吃紧是常态，该升级配置就升级，别硬扛。

第三步，查Nginx的配置和日志。打开/var/log/nginx/error.log，往下翻，一般会有类似“connect() failed”或者“upstream timed out”的记录，这就是线索。常见的情况是proxy_pass指向的端口写错了，或者后端根本没监听那个端口。另外，proxy_read_timeout设得太短，后端处理慢一点就被判定超时，也会报502，适当调大一点能缓解。

第四步，看看是不是被攻击或者流量突增。有时候是爬虫疯狂抓取，或者被人刷接口，把后端连接池占满了。这种情况日志里会有明显的异常请求特征，可以考虑上防火墙或者限流。

最后说一句，502虽然吓人，但它其实是个很“诚实”的错误，告诉你问题出在中间层调不到后端。按上面这四步走，绝大多数情况都能定位到。平时多留意监控和日志，比出了问题再救火要轻松得多。希望大家的网站都稳稳当当，半夜别再被报警电话吵醒了。