504 有个特别明显的特征：耗时是个整数。

30 秒、60 秒、100 秒，不偏不倚。看到这种数字，基本不用怀疑网络抖动，就是某一层设了超时，时间到了主动放弃。

504 和 502 的分界

502 是「拿不到有效响应」，可能是连不上，也可能是后端崩了。

504 更明确：连上了，请求也发出去了，就是等太久。所以排查重点只有一个——后端为什么慢。

三个最常见的来源

慢 SQL 或者锁等待。 平时没事，某个时间段数据量上来，一条没走索引的查询拖到几十秒。

外部接口卡住。 支付回调、短信、第三方 API，对方不返回，你的请求就一直挂着。这类问题最容易被忽略，因为日志里看起来是「正常处理中」。

同步的重活。 导出几万行数据、生成报表、批量发信。这些本来就不该在 HTTP 请求里做。

先看后端真实花了多久

Nginx 的 access log 里有两个字段：request_time 和 upstream_response_time。

如果 upstream 只花了 3 秒，网关却在 60 秒报 504，那问题不在后端，在网关到后端之间的连接复用或者缓冲区。

反过来，upstream 就是 60 秒，那就老老实实查代码。

调超时是止血，不是治疗

把 proxy_read_timeout 从 60 调到 120，用户不会更满意，只会多等一分钟。而且前端、CDN、负载均衡各有一层超时，你调了最里面那层，外面那层照样先断。

真要调，从最外层往里对齐，让每一层的超时都比下一层长一点，这样报错才准确。

CDN 的 524 是同一回事

Cloudflare 的 524 就是回源超时，阈值 100 秒。看到 524 不用查 CDN，直接查源站为什么 100 秒还没响应完。

复测的时候注意

修完之后用 网站测速 跑一次，看 TTFB 落到什么水平。如果还是接近阈值，说明只是勉强过关，量一上来还会犯。