我这边正常，客户却 504

客户发截图，页面 504。我在本地打开，一切正常，还以为他网络有问题。

后来按地区一测才发现，只有两个省拿到 504，其他地区全绿，这种分布本身就是线索。

504 是谁发的

先问这一句，能省掉一半排查，也不至于被日志吓到。

它不是源站的应用返回的，是前面的网关或 CDN 等不到上游，才代你报了这个错。

所以它的含义是「我等超时了」，而不是「源站说你错了」，两者修法差很远。

先搞清这一层，才不会一上来就改业务代码，改了半天发现方向根本不对。

三种常见情况

三种情况，三种人负责，找错了只能干等。

上游真的慢：源站处理时间超过了网关的等待阈值，网关先放弃，用户就看到 504。

阈值太短：源站只是稍微慢一点，网关的 timeout 配得太紧，这种情况最容易误判成应用故障。

个别节点：某个 CDN 节点回源链路差，只有它超时，其他地区用户毫无感觉。

用结果怎么区分

分布和耗时，是最快的分法，比翻代码快得多。

用宝塔拨测的网站测速跑多地区多运营商节点，看状态码分布和五段耗时，两个维度一起看才能定性。

全部节点 504，且 TTFB 都很长：上游确实慢，先去查应用和数据库，别动网关。

只有个别节点 504，其他正常：节点或回源链路的问题，找 CDN 比改代码快。

TTFB 刚好卡在某个固定值附近：很像网关阈值，值得把配置翻出来对一遍。

该改哪一层

改错层，下次还会来，而且会以别的状态码出现。

上游慢，改查询、加缓存、拆同步调用，动网关只是把问题往后推。

阈值太短，调超时配置，但要先确认上游能在新阈值内完成，不然只是拖长等待。

个别节点，找 CDN 侧排查，必要时先把流量切走，别让用户继续撞。

复测与记录

记录清楚，交接不乱，也不用每次重新推理。

同一地址连测三次，确认 504 是稳定出现还是偶发，偶发的先记着观察。

改完只看同一组节点、同一段耗时，别被整体数字带跑，那样看不出是哪一步起效。

把「谁报的 504、等了多久、影响哪些地区」记下来，交接时最有用，复盘也靠它。

504 这件事，先分清是谁在等，再谈改哪里。

分清了，改起来就不会东一榔头西一棒子。

改对了，504 才真的少。

少了，用户投诉自然也少。

投诉少了，团队才有精力做优化。

优化做久了，事故就少了。

事故少，大家都能准时下班。