网站504超时：先定位哪层在等待上游

网站出现504不一定是Nginx自身故障。本文从请求时间线、上游日志和超时类型入手，区分连接失败、响应迟缓与长任务，并说明何时适合调整等待时间。

先画出请求链路

网站504超时，通常意味着网关或代理等待上游响应超时。上游可能是应用服务，也可能是另一层代理。先记录故障时间、接口路径和等待了多久，再画出浏览器、CDN、Nginx、应用与数据库的请求顺序，避免在错误的一层反复修改参数。

用同一路径的小请求对照大请求。只有报表生成或AI写作超时，检查这些任务涉及的外部接口和数据库查询；所有路径都超时，则优先查看应用进程、连接池和资源使用情况。一次成功不能证明问题消失，还应比较相同时段的失败记录。

区分连接与读取超时

查看代理错误日志，判断是在连接上游、发送请求，还是读取响应时超时。接着按时间对应应用日志：应用没有收到请求，应检查前面的连接环节；应用已经开始执行却迟迟没有结束，应进一步检查慢查询、锁等待和外部调用。

对使用proxy_pass的反向代理，proxy_read_timeout约束的是两次连续读取之间的等待，不是整个响应的总时长。PHP站点如果走FastCGI，不能照搬这个代理指令，应检查对应模块和应用设置。不要把不同链路的参数混为一谈。

修复要能解释原因

先处理慢查询、失效依赖或积压队列，再根据正常业务耗时设置有边界的超时。对于几分钟的生成任务，可改成提交后返回任务编号、后台执行、页面查询进度，避免浏览器一直等待。修改后用相同请求复测，并核对日志中的耗时变化；仅把超时提高到很大，可能只是让故障更晚暴露。

参考资料

资料核对日期：2026年10月24日。本文为综合官方文档整理的原创排查指南，未声称进行本站故障实测。

- MDN：504 Gateway Timeout

- Nginx：proxy_read_timeout