网站打开缓慢，等待一段时间后提示“504 Gateway Timeout”，通常表示网关或代理没有及时收到上游服务的响应。
这里的上游服务，可能是PHP-FPM、Java或Node.js程序，也可能是另一台反向代理服务器。处理时应先确认请求卡在哪里，再决定是否调整超时时间。
一、查看日志，判断超时发生在哪个阶段
先记录故障时间、访问地址，以及是否只有某个页面或接口异常。
查看对应站点的Nginx错误日志：
sudo tail -n 50 /var/log/nginx/error.log日志路径以实际配置为准。使用建站面板的网站，可以先在站点管理中查看错误日志。
常见提示包括：
| 日志关键词 | 含义 | 优先检查 |
|---|---|---|
while connecting to upstream |
建立上游连接时超时 | 后端地址、网络、防火墙、连接队列 |
while reading response header from upstream |
等待上游响应头时超时 | 应用处理、数据库、进程排队、外部接口 |
例如：
upstream timed out (110: Connection timed out)
while reading response header from upstream这类日志说明请求已经进入等待后端响应的阶段，需要结合应用日志继续排查。
应同时核对日志中的请求路径和upstream地址，避免把其他请求的报错当成本次故障原因。
如果源站没有对应记录，还应检查前面的CDN、WAF或其他代理层，不能只凭错误页面样式判断来源。
二、确认后端地址，并测试响应情况
查看Nginx配置：
sudo nginx -T找到故障域名对应的server和请求实际匹配的location，确认使用的是哪种转发方式：
-
proxy_pass：通常转发到HTTP或HTTPS应用。 -
fastcgi_pass：常见于PHP-FPM，使用FastCGI协议。
如果后端是HTTP服务，可以在Nginx所在的网络环境中测试其响应。例如，后端监听127.0.0.1:8080，并提供/health健康检查接口：
curl -sS --connect-timeout 3 --max-time 15 \
-o /dev/null \
-w 'HTTP %{http_code} total=%{time_total}s\n' \
-H 'Host: example.com' \
http://127.0.0.1:8080/health域名、地址、端口和路径均需替换为实际值，Host也应与应用要求一致。
如果很快返回预期结果，说明这个接口能够响应；但健康检查正常，并不代表报表、搜索等业务接口也正常，仍需检查原先出错的请求。
如果curl提示超时，只能说明超过了本次测试设置的等待时间。输出中的HTTP 000不是真正的HTTP状态码，也不能直接等同于服务器返回504。
PHP-FPM的FastCGI端口不能使用上述HTTP命令测试。 Docker部署还要注意，容器内的127.0.0.1指向容器自身。
三、检查应用是否排队或执行过慢
后端响应缓慢，常见原因包括：
-
数据库查询耗时长，或正在等待锁释放。
-
PHP-FPM进程、应用工作线程或数据库连接池被占满。
-
程序调用外部接口时迟迟没有返回。
-
CPU、内存或磁盘资源不足。
-
报表、批量导出等任务一次处理的数据过多。
可以先查看服务器资源：
top
free -h再对照故障时间检查应用日志、数据库慢查询记录及外部接口调用记录。
PHP网站如果出现类似提示：
server reached pm.max_children setting说明FPM进程数曾达到配置上限，需要结合请求耗时、进程内存占用和排队情况判断原因。
不要直接大幅增加pm.max_children。如果根本原因是慢查询或外部接口阻塞，增加进程可能进一步消耗内存、加重数据库压力。
持续出现的慢请求，应优先优化查询、设置合理的外部调用超时，或把耗时任务改为后台执行。
四、检查CDN及多层代理
网站如果经过CDN、WAF、负载均衡或多台反向代理，需要逐层检查。
例如，源站允许等待120秒，但前置代理更早结束等待，用户仍然可能看到超时错误。
建议核对以下内容：
| 检查项 | 重点 |
|---|---|
| 故障请求 | 是否只有特定路径、方法或大数据量请求异常 |
| 代理日志 | 哪一层首先记录了超时 |
| 后端状态 | 超时后任务是否仍在执行 |
| 超时设置 | 各层连接、读取及应用执行限制是否匹配 |
如果总是在接近固定时长后失败，可以将实际耗时与各层配置进行对照。
测试时应尽量保持相同的路径、请求方法和登录状态，避免用首页正常访问的结果代替故障业务的验证。
五、按实际转发类型调整超时配置
只有确认业务确实需要更长等待时间，且后端处理过程正常时，才考虑适当延长超时。
对于使用proxy_pass的HTTP反向代理，可在现有匹配配置中调整：
proxy_read_timeout 120s;对于使用fastcgi_pass的PHP-FPM站点，则检查：
fastcgi_read_timeout 120s;以上是两种不同场景，应按实际转发类型选择。120s只是示例值，需要结合业务耗时和服务器承载能力确定。
这两个读取超时参数限制的是两次读取之间的等待间隔，并不是整个请求的统一总时长上限。它们也不能修复连接阶段的网络超时。
修改时保留现有转发、路由和鉴权配置，并检查是否存在更具体的location覆盖设置。
对于使用systemd管理、服务名为nginx的部署，执行：
sudo nginx -t && sudo systemctl reload nginx配置检查通过后才会执行重载。面板安装、容器部署或自定义路径安装的Nginx，应使用对应实例的检查和重载方式。
如果应用、PHP-FPM或前置代理另有执行限制，还需要一并核对。仅修改Nginx，不会自动改变其他服务的设置。
六、验证原先出错的业务
处理完成后，重新访问原先出现504的页面或接口。
对于无需登录的只读页面，可以辅助检查状态码和耗时：
curl -sS --connect-timeout 5 --max-time 150 \
-o /dev/null \
-w 'HTTP %{http_code} total=%{time_total}s\n' \
https://example.com/reports/preview地址和等待时间需要按实际情况调整。需要登录或特定请求参数的业务，优先通过原来的操作页面验证。
确认以下几点：
-
原先出错的业务能够完成。
-
返回内容和业务结果正确。
-
对应日志不再出现相同超时。
-
正常访问量下，响应时间和资源占用保持稳定。
不要只根据一次HTTP 200就认定问题已经解决，还应观察原先容易出错的时段或操作场景。
常见问题
1. 504是否代表服务器已经关机？
不一定。网关能够返回504，但后端可能连接不通、排队严重，或者处理请求过慢，需要结合日志判断。
2. 502与504有什么区别？
502表示网关从上游收到无效响应；504表示没有及时获得所需响应。两者都需要检查上游服务，但排查重点有所不同。
3. 把超时时间设置得很大，是否就能解决？
不能保证。慢查询、资源不足和程序阻塞仍然存在，延长等待还可能让更多请求同时占用资源。
4. 页面超时后，可以直接重复提交吗？
下单、付款、导入等操作应先确认业务结果。客户端收到504，并不代表后端一定停止执行，重复提交可能产生重复记录或重复操作。
注意事项
修改配置前做好备份，保留故障时间和相关日志。优先处理明确的慢查询、资源瓶颈或网络异常，再评估是否需要调整超时参数。
如果使用莱卡云服务器后仍无法定位问题，可提交工单，提供故障时间、请求路径、部署方式、报错截图及相关日志片段，便于进一步排查。提交材料前请隐藏密码、令牌等敏感信息。