服务器出现 502 bad gateway,通常不是 nginx 自己“坏了”,而是 nginx 无法正常连接后端服务。
最常见的情况包括:后端程序没启动、端口写错、进程崩溃、代理地址配置错误,或者 unix socket 权限有问题。
下面按实际排查顺序来处理。
1. 先看后端服务是否还活着
假设 nginx 配置里写的是:
proxy_pass http://127.0.0.1:3000;
先检查 3000 端口:
ss -lntp | grep 3000
如果没有任何输出,说明后端程序大概率没有启动。
如果是 systemd 管理的服务,可以查看:
systemctl status myapp
如果看到:
inactive failed
就先处理后端程序本身。
2. 直接绕过 nginx 测试后端
在服务器本机执行:
curl http://127.0.0.1:3000
如果这里能正常返回内容,说明后端基本没问题,可以继续检查 nginx。
如果出现:
connection refused
通常说明端口没有监听。
如果一直卡住,则可能是程序本身阻塞或者响应异常。
这个测试很重要,因为它能快速判断问题到底在 nginx,还是在后端应用。
3. 检查 proxy_pass 地址
例如:
location /api/ {
proxy_pass http://127.0.0.1:3000;
}重点检查几个地方:
ip 是否正确 端口是否正确 http / https 是否写对 后端是否真的监听这个地址
例如后端实际运行在:
127.0.0.1:8080
但 nginx 配成:
proxy_pass http://127.0.0.1:3000;
访问时自然会出现 502。
4. 查看 nginx 错误日志
如果还没找到原因,直接看日志。
常见路径:
tail -f /var/log/nginx/error.log
或者:
tail -n 100 /var/log/nginx/error.log
比较常见的错误是:
connect() failed (111: connection refused)
通常说明后端没有监听。
如果看到:
upstream timed out
说明后端响应太慢或者卡住了。
如果看到:
permission denied
则要检查文件、socket 或 selinux 等权限问题。
5. 检查后端是不是刚启动就崩了
有时候执行:
systemctl restart myapp
状态短暂显示正常,但几秒之后又退出。
可以查看:
journalctl -u myapp -n 100
常见原因包括:
环境变量缺失 数据库连接失败 端口冲突 依赖缺失 配置文件错误 程序异常退出
这种情况下,502 只是表面现象,真正的问题还是应用启动失败。
6. 检查 nginx 配置有没有写错
修改配置后先执行:
nginx -t
正常会看到:
syntax is ok test is successful
然后再重新加载:
systemctl reload nginx
如果语法有问题,不要直接重启 nginx。
7. 后端使用 docker 时要额外注意
如果应用运行在 docker 中,先检查容器:
docker ps
如果容器已经退出:
docker ps -a
然后查看日志:
docker logs 容器id
还要确认端口映射。
例如:
0.0.0.0:3000->3000/tcp
如果容器内部监听 3000,但宿主机没有正确映射,nginx 同样访问不到。
8. 还有一种常见情况:后端压力过大
如果 502 不是一直出现,而是偶尔出现,可以检查服务器资源:
top
查看内存:
free -h
查看磁盘:
df -h
如果 cpu 长期跑满、内存耗尽,或者后端处理请求过慢,也可能导致 nginx 连接 upstream 失败。
一套比较实用的排查顺序
遇到 502 时,我一般按下面几步检查:
nginx -t
然后:
ss -lntp | grep 后端端口
接着:
curl http://127.0.0.1:后端端口
再看:
tail -n 100 /var/log/nginx/error.log
如果后端由 systemd 管理:
journalctl -u 服务名 -n 100
绝大多数 502 问题,到这里基本都能定位。
简单来说,502 的核心就是 nginx 找不到或者无法正常访问 upstream。先确认后端活着,再检查端口和 proxy_pass,最后结合 nginx 与应用日志排查,比反复重启服务有效得多。
以上就是nginx服务器出现502 bad gateway的排查与解决方法的详细内容,更多关于nginx 502 bad gateway排查与解决的资料请关注代码网其它相关文章!
发表评论