网站突然显示”502 Bad Gateway”或”504 Gateway Timeout”,访客一脸懵,你也一头汗。这两个错误是动态网站最常见的故障。本文讲清它们的区别、根本原因,以及一套逐步排查的解决流程。
一、先分清:502和504不是一回事
- 502 Bad Gateway:Nginx作为前端,把请求转给后端(PHP-FPM、应用服务),但后端没给出有效响应——通常是后端挂了或崩了;
- 504 Gateway Timeout:Nginx把请求转给后端后,等了太久没等到响应而超时——通常是后端太慢(慢查询、卡死)。
一句话:502是后端”死了”,504是后端”太慢了”。诊断方向不同。
二、502排查流程
- 看后端服务是否在运行:PHP站点检查PHP-FPM,
systemctl status php8.2-fpm;应用站点检查你的进程是否存活。挂了就重启并查为什么挂; - 看错误日志(最关键):
tail -f /var/log/nginx/error.log,502的具体原因几乎都写在这里——连接被拒、socket找不到、上游超时等; - 检查连接配置:Nginx配置里的 fastcgi_pass 或 proxy_pass 指向的地址/socket是否正确、后端是否监听在那个地址;
- 检查资源:内存耗尽会导致后端进程被系统杀掉(OOM),
free -m看内存、dmesg | grep -i oom查是否发生过OOM。
三、504排查流程
- 定位慢在哪:504是超时,先找什么操作慢——多半是数据库慢查询、外部API调用超时、或某个耗时脚本。开慢查询日志揪出问题SQL(详见博客MySQL优化教程);
- 治本:优化性能:补索引、加缓存(Redis)、优化代码——让后端在超时前完成响应,这才是正解;
- 治标:调大超时(谨慎):确实需要长时间处理的任务(如大报表),可适当调大Nginx的
fastcgi_read_timeout/proxy_read_timeout——但这是掩盖问题,长期还是要优化; - 检查资源瓶颈:CPU或磁盘IO被打满时,一切都会变慢,
top和iostat确认。
四、高频具体原因速查
- PHP-FPM进程数不够:高并发时进程池耗尽,新请求排队超时。调大 pm.max_children;
- 内存不足触发OOM:后端进程被杀导致502,升级内存或优化占用;
- 数据库慢/卡死:504的头号元凶,优化SQL和索引;
- 后端崩溃未自启:用systemd配置
Restart=always让服务崩溃自动拉起; - 资源被超售挤占:如果是廉价超售VPS,高峰期CPU steal和IO抖动会频繁引发超时——这种情况换物理独享服务器才能根治。
五、预防胜于救火
装好宕机监控(Uptime Kuma),502/504第一时间告警而不是等客户投诉;配合关键词检测,能识破”返回200但页面是报错”的假活着状态。日常做好性能优化(缓存、索引、合理配置),从源头减少这类故障。
502/504不可怕,记住诊断口诀:502查后端死没死(看error.log),504查后端为什么慢(查数据库和资源)。八成的问题,error.log和top两个命令就能定位。如果排查发现是服务器资源长期不足或超售所致,升级到独享资源的方案是最彻底的解法。
