首页可以打开，进入后台、导出数据或提交某个表单时却出现504 Gateway Timeout。这类故障说明网关在规定时间内没有等到上游继续返回数据，问题不一定发生在Nginx本身。
最常见的错误处理是先把超时参数从60秒改成600秒。页面可能暂时不报504，但一个请求仍要等十分钟，真正拖慢它的PHP、应用、数据库或外部接口并没有得到修复。
先确认504由哪一层返回
先记录故障时间、访问地址和请求方式，再检查Nginx错误日志：
sudo tail -n 100 /var/log/nginx/error.log
sudo journalctl -u nginx --since "10 minutes ago"面板环境或单独虚拟主机可能使用其他日志路径，应以生效配置为准。日志里的 upstream timed out、while reading response header from upstream 和上游地址，比浏览器中的504页面更能决定方向。
网站前面还有CDN或负载均衡时，也要确认错误页和响应头来自哪一层。先找到实际返回504的网关，再调整对应配置。
区分连接超时和读取超时
上游连接迟迟建不起来，与连接成功后长期没有返回数据，是两类问题。Nginx连接PHP-FPM、反向代理应用时，错误日志会记录对应阶段。
FastCGI场景常见 fastcgi_connect_timeout 与 fastcgi_read_timeout；反向代理场景则会涉及 proxy_connect_timeout 和 proxy_read_timeout。Nginx官方文档说明，读取超时通常计算两次读取之间没有收到数据的时间，并不是整个响应传输必须在该秒数内完成。
因此，连接上游就超时应检查进程、监听地址、Socket和连接队列；读取阶段超时则更接近应用执行慢、数据库等待或外部请求卡住。
检查PHP-FPM或应用进程状态
PHP站点先确认FPM服务、进程和监听是否正常：
systemctl status php-fpm
ss -lntp
ss -lxnp不同发行版和PHP版本的服务名不同，需要替换为服务器实际名称。Node.js、Java、Python等应用也应检查对应服务状态、进程数量、重启记录和应用日志。
进程显示active只能说明服务没有退出，不代表每个工作进程都能及时处理请求。FPM工作进程耗尽、应用线程池排满或进程陷入阻塞时，Nginx仍可能一直等待。
用慢日志找到卡住的请求
PHP-FPM可以配置慢请求日志和超时跟踪，应用框架也常有请求耗时日志。先在维护窗口内设置合理阈值，复现一次问题，再根据堆栈确认程序卡在哪里。
同一个URL稳定超时，通常更接近代码路径、慢查询、文件处理或第三方接口。所有页面在高峰期一起超时，则要关注并发、工作进程、数据库连接池和服务器资源。
不要直接杀掉所有PHP或应用进程再宣布修好。重启能释放卡住的任务，却会同时清掉最有价值的现场证据。
数据库慢查询和锁等待也会制造504
页面需要等待数据库时，Nginx看到的只是上游迟迟没有响应。应在故障时间段检查活跃连接、慢查询、事务与锁等待，而不是只盯Web服务器日志。
MySQL可结合进程列表、慢查询日志和InnoDB状态，PostgreSQL可查看 pg_stat_activity 与锁关系。查询本身慢、缺少索引、长事务阻塞和连接池耗尽，都会把Web请求拖到网关超时。
数据库层没有完成证据检查前，不要把504简单归因于带宽。 静态文件能快速打开、特定动态操作超时，往往已经说明网络并不是第一嫌疑。
检查外部接口和资源压力
支付、邮件、对象存储、DNS或第三方API没有设置合理连接与读取超时，也可能拖住应用工作进程。应用日志应记录外部请求的目标、耗时和结果，同时避免写入密钥等敏感信息。
再对照CPU、内存、Swap、磁盘延迟和进程数量。CPU满载、OOM、磁盘等待或文件句柄耗尽，可能让多个组件同时变慢，需要按同一时间线定位最先出现的异常。
服务器资源已经长期处于上限时，可以在 萤光云 准备相近环境做压力对照，也可以使用按小时计费的 LightNode 建立临时并行环境。迁移前要先确认慢点在哪一层，否则换更高配置也可能继续被同一条慢查询拖住。
超时参数应该怎么调整
某些任务本来就需要较长时间，例如大文件处理或后台报表。确认应用仍在持续工作、资源使用合理，并且业务允许同步等待后，可以适度调整对应的读取超时。
更稳妥的方式通常是把长任务改为异步队列，前端返回任务编号，再查询进度。这样既不会长期占用Web工作进程，也能避免用户重复提交。
修改Nginx配置后先执行 nginx -t，再平滑重载。只改一项并保留修改前后的耗时数据，避免同时调整多个参数后无法判断哪项有效。
修复后的验收标准
使用之前稳定触发504的同一操作重复测试，记录Nginx、应用和数据库的开始时间与结束时间。响应应在可接受范围内完成，错误日志不再新增上游超时，应用工作进程和数据库连接也不应持续堆积。
随后观察一个实际高峰，并检查普通页面、后台操作和长任务。只让504页面消失、但请求耗时仍在不断拉长，不算真正恢复。
常见问题
504和502有什么区别？
502通常表示网关从上游收到无效响应或无法正常连接，504更强调等待上游响应超时。最终仍应以错误日志中的阶段和错误码为准。
把fastcgi_read_timeout调大就能解决吗？
只能让Nginx等得更久。确认任务合理且仍在工作时可适度调整，慢查询、死锁和外部接口卡死仍需修复根因。
只有WordPress后台出现504该查哪里？
先定位具体操作，再查PHP-FPM慢日志、WordPress错误日志、数据库慢查询和相关插件调用。前台正常并不能证明整个PHP环境没有瓶颈。
