企业网站出现502、504、数据库连接失败，通常怎么排查？

网站运维

2026-09-14

网站打不开的时候，运营发来的截图通常只有一句话：「白屏，什么都没有」。

技术这边真正要做的第一件事，不是重启服务器，而是把这句「打不开」翻译成具体的一种故障。因为 502、504 和数据库连接失败虽然在用户那里长得一模一样，但它们断在完全不同的位置，排查方向也完全相反。

一次请求要经过浏览器、Nginx 网关、应用程序、数据库四个环节，三种常见报错断在不同位置：502 Bad Gateway 是网关转交后应用没有响应，通常是应用进程挂了或没启动；504 Gateway Timeout 是应用接了请求但迟迟不返回，超过了网关的等待时间；数据库连接失败 则是应用连不上数据库，常见于连接数打满、数据库服务未启动或凭据变更。

502、504 和数据库连接失败，区别到底在哪？

三者断点不同：502 是应用没响应，504 是应用响应太慢，数据库连接失败是应用连不上库。

用一次点餐来打比方会更清楚。用户是客人，Nginx 是服务员，应用程序是后厨，数据库是仓库。

502：服务员把单子递进后厨，发现里面一个人都没有。对应到服务器上，就是 PHP-FPM、Node 这类应用进程已经退出，或者压根没启动
504：后厨有人，也接了单，但这道菜做了太久，客人等不下去走了。对应的是请求卡在应用里，超过了 Nginx 愿意等待的时间
数据库连接失败：厨师在，菜谱也在，但仓库上了锁，料取不出来。这时候页面报的可能是 500，也可能直接显示数据库错误

分清这一点很重要：502 要去看进程为什么没了，504 要去看哪一步太慢，两件事的排查路径几乎没有交集。

排查应该按什么顺序来？

五步，从最省事的往后走：看状态码、翻 Nginx 日志、查应用进程、看服务器资源、最后才进数据库。

502、504 的排查有固定顺序，从最省事的一步往后走：先确认是哪个状态码，因为 502、504、500 指向的方向完全不同；再翻 Nginx 错误日志，绝大多数问题的原因就写在那几行里；然后确认应用进程是退出了还是进程池被占满；接着看内存、磁盘、CPU 有没有见底；最后才进数据库看连接数、慢查询和锁表。跳过前面直接查数据库，往往会在错误的方向上浪费几个小时。

展开说：

第一步，确认状态码。打开浏览器开发者工具的 Network 面板，或者直接 curl -I 一下。别凭页面上的提示文字判断，很多站会用自定义错误页把真实状态码盖掉。

第二步，翻 Nginx 错误日志。这是整个流程里性价比最高的一步。日志一般在 /var/log/nginx/error.log，直接看最后几十行。几条常见提示的含义：

connect() failed (111: Connection refused) — 应用进程根本没在监听，对应 502
upstream timed out — 应用没在规定时间内返回，对应 504
no live upstreams — 后端节点全被标记为不可用

第三步，看应用进程。systemctl status php-fpm 或对应的服务名。重点看两件事：进程是不是退出了，以及退出原因。如果看到 oom-kill，说明是内存不足被系统杀掉的——那么真正的问题在内存，不在应用本身。

第四步，看服务器资源。free -m 看内存，df -h 看磁盘，top 看 CPU。这三项任何一项见底，都会连锁引发上面所有症状。磁盘写满尤其隐蔽——日志文件涨到把盘占满，数据库先写不进去，然后应用开始报错，最后网关返回 502，看起来像是三个故障，其实是一个。

第五步，才轮到数据库。看连接数是不是打满（SHOW PROCESSLIST），有没有慢查询堆积，有没有表被锁住。

顺序之所以重要，是因为跳过前面直接查数据库，很容易在错误的方向上耗掉一整个下午。而绝大多数情况，答案在第二步就已经写在日志里了。

找到原因之后，具体要改什么？

四个地方：进程池上限、内存与磁盘、数据库连接数、慢接口。

定位之后真正要处理的是四处：应用进程池调大上限，同时回头查清是谁把进程长期占住；内存与磁盘清理日志和缓存，长期不足就该扩容；数据库连接数通过优化慢查询和引入连接池来降下来，避免连接不释放；响应时间可以适当调大超时阈值，但根治的办法是优化那条慢接口。只重启服务能暂时恢复，下一次高峰还会复发。

需要提醒的是，这四项里每一项都有「治标」和「治本」两种做法，而它们经常被混为一谈：

进程池被占满，调大 pm.max_children 能立刻缓解，但如果不查清是哪个接口把进程长期占住，调多少都会再被占满
504 频发，调大 fastcgi_read_timeout 确实能让报错消失，但用户仍然要等十几秒——问题只是从报错变成了体验差
数据库连接数打满，往往是因为连接用完没有释放，或者存在长时间不结束的慢查询。加大 max_connections 只是把爆掉的时间往后推
磁盘满了清一次日志能撑几天，但如果没配日志轮转，下个月同一天还会再满一次

怎么避免同一个故障反复出现？

把被动救火换成三件常规动作。

监控要在用户之前发现问题。内存、磁盘、连接数设好告警阈值，最低限度也要有一个每分钟访问首页的可用性监测。绝大多数企业站的故障是运营先发现的，这意味着已经损失了一段时间的访问
日志要能留住现场。配好日志轮转，既防止写满磁盘，也保证出事后还能回溯。日志被覆盖掉的故障，基本等于查不了
把这次的排查过程记下来。什么现象、日志里是哪一行、最后改了什么。同一台服务器上的故障复发率很高，这份记录下次能省掉一半时间

还有一条经验值得单独说：重启服务几乎总能让网站暂时恢复，这也正是它的危险之处。问题看起来解决了，根因却留在原地，下一次高峰它还会回来——而且往往挑在更糟糕的时间点。