文章总结： 本文详细解析504网关超时错误的完整排查流程，从确认问题现象到检查网关层、网络层、应用服务器、系统资源和后端服务的五步排查法。提供具体命令和配置调整建议，指出应用代码慢占50%为主要原因，强调先定位根因再调整超时时间的原则。 综合评分： 85 文章分类： 解决方案,技术标准,运维安全,应用安全,云安全
504 网关超时？别慌！完整排查思路来了
原创
刘军军 刘军军
运维星火燎原
2026年5月2日 00:01 山西
在小说阅读器读本章
去阅读
01
504是什么？
504 Gateway Timeout：网关/代理服务器在等待上游服务器响应时超时了。
简单说：Nginx 等了很久，应用服务器没反应，所以报 504。
02
完整排查思路（从外到内）
第一步：确认问题现象
# 1. 直接访问应用服务器（绕过网关），看是不是正常
curl http://应用服务器IP:端口/路径
# 2. 访问网关，看是不是确实 504
curl -I http://你的域名/路径 # 看 HTTP 状态码
判断：
- 直接访问应用正常 → 问题在网关或网关到应用的网络
- 直接访问应用也慢 → 问题在应用或后端
第二步：检查网关层（Nginx）
- 查看 Nginx 错误日志
# 看 Nginx 错误日志（通常在 /var/log/nginx/error.log）
tail -f /var/log/nginx/error.log
# 常见错误信息
# upstream timed out (110: Connection timed out) while reading response header from upstream
- 检查 Nginx 超时配置
# 查看 Nginx 配置
vim /etc/nginx/nginx.conf
# 或
vim /etc/nginx/conf.d/你的配置.conf
# 相关配置项
proxy_connect_timeout 60s; # 连接上游超时
proxy_send_timeout 60s; # 发送请求超时
proxy_read_timeout 60s; # 读取响应超时（最常见！）
临时调整：如果确认是超时时间太短，可以调大（指标不治本，建议先找根因）
# 重新加载 Nginx
nginx -t && nginx -s reload
第三步：检查网络层
- 从网关服务器 ping 应用服务器
# 在网关服务器上执行
ping 应用服务器IP
# 看延迟和丢包率
# 延迟高/丢包 → 网络问题
2. telnet 测试端口连通性
# 从网关服务器测试
telnet 应用服务器IP 端口
# 或
nc -zv 应用服务器IP 端口
# 结果
# Connected → 连通正常
# Connection refused → 端口没开或防火墙
# 超时 → 网络问题
- traceroute/mtr 排查路径
# 看网络路径
traceroute -n 应用服务器IP
# 持续监控网络质量（推荐）
mtr -n 应用服务器IP
第四步：检查应用服务器
- 看应用进程是否还在
# 看应用进程
ps -ef | grep 你的应用名
# 看端口是否在监听
netstat -tlnp | grep 端口
# 或
ss -tlnp | grep 端口
- 看应用日志
# 看应用日志（路径根据你的实际情况）
tail -f /path/to/你的应用.log
# 找关键词
# ERROR / Exception / Timeout / 死锁 / 数据库连接失败
- 看应用响应时间
# 直接在应用服务器上测试
time curl http://127.0.0.1:端口/路径
# 如果这里就很慢 → 应用本身慢
第五步：检查系统资源（应用服务器）
- 看 CPU
top
# 或
htop
# 看 CPU 使用率
# load average > CPU 核数 → CPU 忙
2. 看内存
free -h
# 重点看 available
# available 小 → 内存不足
3. 看磁盘 I/O
# 看磁盘使用率
df -h
# 看磁盘 I/O 情况
iostat -x 1
# %util 接近 100% → 磁盘瓶颈
- 看网络连接
# 看连接数
netstat -an | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
# 看是否有 CLOSE_WAIT/TIME_WAIT 过多
第六步：检查后端（数据库/中间件）
1. 数据库
# 看数据库连接数
show processlist;
# 看慢查询
# MySQL
show variables like 'slow_query%';
# PostgreSQL
select * from pg_stat_activity where state = 'active';
# 测试数据库查询速度
time mysql -e "select * from 你的表 limit 1"
2. 中间件（Redis/MQ等）
# Redis
redis-cli info stats
# 看响应时间
time redis-cli ping
03
常见原因总结
| 原因 | 占比 | 排查点 | | — | — | — | | 应用代码慢 | 50% | 慢查询、死循环、锁等待 | | 数据库慢 | 20% | 慢 SQL、锁、连接池耗尽 | | 网络问题 | 15% | 丢包、延迟高、防火墙 | | 网关超时设置短 | 10% | proxy_read_timeout 太小 | | 资源耗尽 | 5% | CPU/内存/磁盘满 |
04
快速排查
#
# 1. 先确认问题（必做）
curl -I http://你的域名/路径 # 看是不是 504
curl http://应用服务器IP/路径 # 绕过网关测试
# 2. 看网关日志（必做）
tail -f /var/log/nginx/error.log
# 3. 看应用日志（必做）
tail -f /path/to/应用.log
# 4. 看系统资源（必做）
top
free -h
iostat -x 1
# 5. 看网络（怀疑网络时）
ping 应用服务器IP
mtr -n 应用服务器IP
504 = 网关等不及应用响应了
- 先绕过网关测试，定位是网关还是应用问题
- 优先看应用日志和慢查询
- 最后再调大网关超时时间（指标不治本）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：运维星火燎原 刘军军 刘军军《504 网关超时？别慌！完整排查思路来了》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论