504 Gateway Timeout 主因是后端响应慢，尤以数据库慢查询最常见；需按“Nginx错误日志→访问日志$upstream_response_time→直连后端→应用线程堆栈→数据库慢查日志→EXPLAIN分析”层层排查。
504 Gateway Timeout 很少是 Nginx 自身的问题，绝大多数情况是它等不到后端响应——而数据库慢查询，正是最常见的“拖后腿”原因。排查要从外到内、层层递进，不能一上来就调大超时值。
看 Nginx 错误日志，确认是不是真超时
先登录 Nginx 服务器，打开 /var/log/nginx/error.log，搜索关键词：
- upstream timed out：明确是代理超时，不是连接失败
- 后面括号里的提示很关键：while reading response header from upstream → 对应 proxy_read_timeout 阶段
- 如果同时看到大量 upstream prematurely closed connection，说明应用可能已崩溃或主动断连，需另查；但若只有“timed out”，重点就是响应慢
查 Nginx 访问日志，看后端真实耗时
Nginx 的 $upstream_response_time 字段直接记录了每次请求在后端花了多久。比如这一行：
192.168.1.100 - - [02/Oct/2026:02:15:23 +0000] "GET /api/products HTTP/1.1" 504 172 "-" "curl/7.68.0" 0.002 138.456 0.001
最后三个数字就是三次重试的 upstream 响应时间，其中 138.456 秒 明显异常。这说明问题不在网络或 Nginx，而在后端处理本身。
直连后端服务，绕过 Nginx 验证
用 curl 直接请求后端地址（如 curl http://127.0.0.1:8080/api/products），观察响应时间和返回内容：
- 如果也卡顿或超时，说明问题确实出在应用或其依赖上
- 再结合应用日志或 APM 工具（如 Arthas、SkyWalking），定位具体哪个接口、哪段代码耗时高
- 常见线索：线程堆栈里大量卡在 java.sql.PreparedStatement.execute 或类似数据库调用点
查数据库慢查询日志，锁定根因 SQL
开启并检查数据库的慢查询日志（以 MySQL 为例）：
- 确认是否启用：slow_query_log = ON，long_query_time = 1（建议设为 1 秒）
- 查看日志文件（如 /var/lib/mysql/slow.log），找执行时间长、扫描行数多的语句
- 典型问题：缺少索引、ORDER BY + LIMIT 无覆盖索引、JOIN 字段类型不一致、全表扫描
- 用 EXPLAIN 分析可疑 SQL，重点关注 type=ALL、rows 过大、Extra 出现 Using filesort 或 Using temporary
