运维
Nginx 504 Gateway Timeout怎么解决？从日志定位上游超时
证据状态：官方文档、明确条件与可重复步骤；页面未标注的数据不视为本站实测。
直接答案：504表示Nginx等待上游应用返回时超时。先从错误日志确认是proxy还是FastCGI请求，再检查上游服务、CPU内存、数据库和慢接口；只有业务确实需要更长处理时间时才调整proxy_read_timeout或fastcgi_read_timeout。
先从错误日志判断是哪一层超时
查找与504发生时间一致的Nginx错误，记录请求URI、上游地址和模块。proxy_pass通常对应proxy超时，PHP网站常通过FastCGI连接PHP-FPM。没有这一步就修改所有超时，容易掩盖真正瓶颈。
确认上游服务与依赖是否健康
- 检查应用或PHP-FPM是否运行、是否频繁重启。
- 查看CPU、可用内存、磁盘和IO等待。
- 从服务器直接请求上游地址，排除公网与CDN。
- 检查数据库慢查询、外部API和长任务。
所有请求都超时先查服务和资源；只有特定接口超时则重点查接口逻辑。
什么时候可以增加超时时间
报表导出、长轮询或确实需要较长处理的API，可在对应location设置proxy_read_timeout；PHP场景使用相应FastCGI参数。修改后先运行nginx -t再平滑重载。不要把全站改成600秒代替性能排查。
修复后如何确认
重新执行原请求，记录状态码与总耗时，并观察错误日志、PHP-FPM队列、数据库和95分位响应。高峰期仍逐渐变慢时，应先优化慢请求，再根据持续资源数据判断是否升级。
备份只有恢复成功才算有效
备份成本包括存储、跨地域复制、请求、出口流量和恢复时间。快照与异地备份承担不同职责。
- 定义可接受的数据损失时间和恢复时间。
- 分别备份数据库、用户文件和配置。
- 至少保留一份不与生产实例同故障域的副本。
- 定期在空白服务器完成恢复演练。
sudo nginx -t
sudo tail -n 100 /var/log/nginx/error.log
systemctl --type=service | grep -E 'nginx|php.*fpm'
free -h
df -h这些命令只验证配置、读取错误并检查服务与资源。日志位置和PHP-FPM服务名可能因环境而异。
哪些情况下不应这样选
- 只开同账号同地域快照，就认为已经异地容灾。
- 从未恢复过备份，也没有记录恢复依赖。
资料与边界
本文结合官方文档和可重复的验收方法编写。未标注“实测”的数据不作为跑分或线路承诺；价格、资格和产品限制应以购买当天的官方页面为准。
常见问题
504和502有什么区别？
504通常表示等待上游超时；502更常见于上游无法连接、进程退出或返回无效响应。
把proxy_read_timeout改大就能解决吗？
只能解决业务本来就需要更长时间的情况；上游卡死或资源不足时只会让用户等待更久。
什么时候需要升级服务器？
应用无明显错误且高峰期CPU、内存、IO或工作队列持续饱和时，再按瓶颈升级。