504 一出现，我就重启了服务

监控报 504，我登录服务器重启了应用，结果还是 504。日志里也没有明显错误。

后来才明白，504 是网关在说「我等够了」，不是应用在报错。重启不解决问题。那次真正的原因是数据库锁等待。

这两个角色要分开

网关可以是 Nginx、负载均衡、CDN。它把请求转给上游，然后等。

等超过设定的时间还没拿到响应，它就返回 504，主动断开。

上游可能是应用、Tomcat、PHP-FPM，也可能是另一层网关。上游超时后，网关只能给你一个 504，它并不知道具体原因。

看耗时特征

所有节点都是 504，而且耗时几乎一样，像卡在某个整数秒上，这通常是网关的超时设置。固定时长的 504 也别急着调大，先确认业务正常耗时是多少。

耗时忽长忽短，有时成功有时失败，更像上游真的不稳定，或者偶尔很慢。

这两种方向完全不同：前者改配置，后者查后端。

用分段定位

用宝塔拨测的网站测速看五段。DNS、TCP、TLS 一般正常，因为连接是通的。

异常会集中在 TTFB 这一段：请求发出去了，一直等不到第一个字节。

再看节点分布。所有节点一样，偏源站或统一入口；只有某些地区，偏 CDN 回源或者那条链路。如果 TCP 也失败，那就不是 504 的问题，往连接层查。

上游为什么慢

常见的是慢查询、外部接口超时、锁等待，或者一次请求要处理太多数据。长事务、大批量导出、同步调用第三方，都会把 TTFB 拉过阈值。

还有一种容易被忽略：网关的超时时间比后端的正常处理时间还短。业务本来就需要几秒，网关等两秒就断了。

这种情况调大超时是对的，但前提是确认后端确实在正常工作。有些 CDN 的回源超时和浏览器看到的不一样，要分开看。源站慢的时候，CDN 先超时，用户看到 504，源站其实还在处理，请求继续占着后端资源。这时候加超时可能让问题更严重，先限流、再优化，比调参数靠谱。

复测和顺序

先加日志、看慢查询，确认后端到底卡在哪。再决定是优化代码还是调整超时。日志时间要和客户端时间对齐，这个顺序很多人会弄反。

改完用同一批节点复测，看 TTFB 是否降到超时阈值以下，状态码是否回到 200。

连测三次，别拿一次成功当结论。504 经常是间歇性的，单次通过说明不了问题，多观察一段时间更稳。