504 是后端太慢，不是网络断。同一件事有很多种做法，选哪种取决于你的系统版本和线上是否允许中断。

下面按“先判断范围、再处理、最后防复发”的顺序展开，涉及 Nginx 504、超时 的关键动作都给了具体做法，可以照着走。

分层看

先确认后端单独执行耗时多少。

拿不准的时候先做备份再做变更，成本最低。

超时参数

proxy_connect_timeout 与 proxy_read_timeout 分别调。

容易踩的坑：常见的坑是只处理表象：症状消失就收工，根因还在，过几天又复发。

业务侧

慢 SQL、外部接口阻塞最常见。

动手前先确认影响范围，能局部处理就不要影响整机。

不建议无限调大

可能把问题推成雪崩，先做限流。

速查表

常见问题

Q：Nginx 504这类问题，最快的判断办法是什么？
先确认现象的范围：只有单台还是全部、只在某个时段还是持续。范围一缩小，原因基本就浮出来了。

Q：按文中的步骤做完，还需要注意什么？
把处理过程和最终生效的参数记下来。同类问题再出现时直接对照记录，比重查一遍快得多。

小结

回到这篇的四个环节：分层看、超时参数、业务侧、不建议无限调大。以上步骤按顺序做完，同类故障基本能自己处理。留一份操作记录，下次能省一半时间。

相关阅读：Nginx 502 错误的排查顺序、Nginx 反向代理怎么配、Nginx 编译安装还是包安装。