得，今天又碰上糟心事儿，浏览器页面直接给我撂个“504 gateway time-out”的脸子。这玩意儿隔三差五就能见到，但每次碰到还是有点烦。
我本能地就按F5刷新，想着是不是网络抽风，多刷几次就好。结果？没用，那“504”跟焊在屏幕上似的。
那我就开始琢磨，这到底是哪儿出问题？
我先看看自己电脑的网络，好的很呐，访问其他网站都刷刷的，说明不是我这边的问题。
那就得是服务器那边的事儿。“gateway time-out”，网关超时。我自己的理解就是，我访问网站，请求先到一个“门口”（网关），这个“门口”得去找后面的“屋子”（实际处理请求的服务器）要东西，结果，在规定时间内，“屋子”没把东西给“门口”，“门口”等不及，就跟我说：“哥们儿，超时，不等！” 大概就这么个意思。
排查过程是这样的：
- 第一步：确认是不是普遍现象。我找同事问下，他们那边也打不开，得，实锤，服务器端的问题。
- 第二步：登录服务器看看情况。我赶紧连上服务器，先看看系统资源，什么CPU、内存、网络流量。有时候服务器太忙，累趴，处理不过来请求，也会搞出这个504。我看一下，资源占用率是有点高，但不至于完全动不。
- 第三步：检查相关服务状态。我们这边常用的是 Nginx + PHP 的组合。Nginx 算是那个“门口”，PHP-FPM 就是那个“屋子”。
- 我先看 Nginx 的错误日志。果然，日志里刷不少类似 `upstream timed out (110: Connection timed out) while reading response header from upstream` 的记录。这就很明显，Nginx 等 PHP-FPM 的响应等超时。
- 接着我就去看 PHP-FPM 的情况。看看进程在不在，运行状态怎么样。发现 PHP-FPM 的进程确实在运行，但是好像有几个进程卡住，状态不太对劲。
- 我试着重启一下 PHP-FPM 服务。命令敲下去，服务重启。
- 第四步：再次尝试访问。重启完 PHP-FPM，我赶紧回到浏览器，又按下 F5。这回页面出来，访问正常。
所以这回的问题根源找到：就是后端的 PHP-FPM 服务不知道为有几个进程处理请求卡住，没能在 Nginx 设置的超时时间内返回数据，导致 Nginx 那边等不及，就报 504。
虽然重启服务解决眼前的问题，但这不算完。我还得去翻翻 PHP 的慢日志，看看是哪个脚本执行那么慢，把进程给卡死。找到那个慢脚本，优化它，或者看看是不是有外部请求太慢拖累它，这才是长久之计。
有时候，也可能是 Nginx 和 PHP-FPM 配置文件里的超时时间设置得太短，比如 `fastcgi_connect_timeout`, `fastcgi_send_timeout`, `fastcgi_read_timeout` 这些 Nginx 的配置，还有 PHP-FPM 配置里的 `request_terminate_timeout`。如果有些正常的请求确实需要处理比较长时间，那可能就得适当调大这些值。不过这回看情况，更像是 PHP-FPM 进程本身卡住。
遇到 504，别慌，先判断是自己这边的问题还是服务器的问题。如果是服务器问题，就登录上去，查查资源占用，看看日志，检查检查网关（比如 Nginx）和后端服务（比如 PHP-FPM、Tomcat 等）的状态和连接，基本就能找到方向。重启服务大法但治标不治本，找到根本原因才是王道。