Http状态码502常见原因及排错思路(实战)

Http状态码502常见原因及排错思路

502表示Bad Gateway。当Nginx返回502错误时,通常表示Nginx作为代理服务器无法从上游服务器(如:我们的后端服务器地址)获取有效的响应。导致这种情况的原因有很多:

  1. 后端服务器故障
  2. nginx配置问题
  3. 高负载或者资源耗尽
  4. nginx与后端服务器通信问题
  • 必出现502:应用挂了(服务端返回RST,nginx或者其他发出502报错)
  • 偶尔出现502:CPU使用率高 / QPS增加 / nginx read超时时间设置问题

504 Gateway timeout 网关超时

  • 一般指nginx做反向代理服务器时,所连接的服务器tomcat无响应导致的。
  • 为了完成您的 HTTP 请求,该服务器访问一个上游服务器,但没得到及时的响应
  • nginx超过了自己设置的超时时间

502常见原因及排错思路

1. 后端服务器故障

检查后端服务器是否正常运行,网络连接是否正常。
可以通过 ping 命令检查网络连接:ping your_backend_server_ip
通过 telnet 命令检查后端服务器的端口是否开启:telnet your_backend_server_ip your_backend_server_port
通过 curl 命令测试后端服务器的响应:curl -I http://your_backend_server_url

2. 网关配置问题:代理地址、请求超时时间

以Nginx作为网关为例:

检查 Nginx 配置文件中的代理设置,确保代理到后端服务器的配置正确。
检查超时时间配置:proxy_read_timeout 2s; #vim /opt/nginx/nginx.conf
检查 Nginx 错误日志,查看是否有相关的错误信息:tail -f /var/log/nginx/error.log

3. 后端服务器高负载或者资源耗尽:某一时刻qps过高

# 可能是某一瞬间,服务器的qps过高导致502
可以使用 top 命令查看系统资源(CPU、MEM)使用情况

4. 网关与服务器通信问题(网络连接、端口开放等)

检查 Nginx 与后端服务器之间的防火墙设置,确保端口开放。
检查 Nginx 与后端服务器之间的网络连接是否正常,可以通过抓包工具(如 tcpdump)检查网络通信情况。

实战

今天测试反馈前端页面访问出错,因为我们前端是通过nginx请求到后端的,所以查看浏览器上查看网络请求,发现报502Bad Gateway。
📢:本文ip与端口等信息均以加密

1. 查看nginx.conf:观察是否是代理配置错误

首先想到是不是nginx的代理配置出了问题,结果发现nginx.conf配置文件是没有问题的,配置的代理也是正确指向我们后端服务的地址。

    server {
    listen 80;
    location / {
        proxy_pass http://localhost:6020;
    }
        location /backend-api {
           rewrite ^/backend-api(.*)$ $1 break;
           proxy_pass http://192.168.64.145;
        }
    }

查看能否ping通后端服务器,发现也是通的

ping 192.168.64.145

2. 查看/var/log/nginx/error.log:查看nginx报错信息

然后准备查看nginx的报错日志信息

tail -f /var/log/nginx/error.log

发现错误信息如下:

2023/11/12 11:07:26 [error] 49448#49448: *1998 connect() failed (111: Connection refused) while connecting to upstream, client: 10.3.0.52, server: , request: "GET /backend-api/list HTTP/1.1", upstream: "http://192.168.64.145:80/list", host: "10.16.13.137", referrer: "http://192.168.64.120/page/xx"

可以看出是nginx请求我们后端的服务器没有请求成功。

3. 检查后端服务是否正常运行

查看nginx请求的后端服务器是否正常工作
因为我们使用的是k8s部署服务,所以直接观察每个pod运行状态即可

# 查看服务pod是否是running状态
kubectl get pods -n xxx

运行命令后,发现处理服务的pod状态都是正常的。

然后想到nginx请求我们的是80端口,于是通过检查端口是否处于Listen状态即可

netstat -ano | grep 80

结果发现服务器上的80端口没有被过滤出来,马上联想到是不是80端口没有开放出来

firewall-cmd --zone=public --list-ports | grep 80
# 执行命令后发现FirewallD is not running
# 查看防火墙状态
systemctl status firewalld
# 发现防火墙已经是关闭状态(为了方便测试,暂时关闭),因此防火墙不会阻拦80端口的请求

这个时候突然想到是不是ingress问题,执行命令查看k8s event信息

# 发现是有报磁盘资源不足
kubectl get event
# 查看pod详细信息,包括event
# kubectl describe pod podName

在这里插入图片描述

# 查看所有节点状态
kubectl get pod -n kube-system -o wide
# kubectl get pods -A -o wide

在这里插入图片描述
发现配置的ingress pod被驱逐。

# 查看磁盘使用情况,清理对应磁盘之后发现ingress正常工作
df -h

拓展:HTTP状态码合集

HTTP状态码合集

  • 8
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Linux系统中常见的报错包括但不限于以下几种: 1. Command Not Found:命令未找到,可能是因为命令没有安装或者安装路径不在环境变量中。 解决方法:检查命令是否安装,如果未安装则使用包管理器进行安装,如果已安装则检查环境变量是否正确。 2. Permission Denied:权限不足,可能是因为当前用户没有执行该操作的权限。 解决方法:使用root用户或者具有执行权限的用户进行操作。 3. Connection Refused:连接被拒绝,可能是因为目标主机没有开启服务或者防火墙阻止了连接。 解决方法:检查目标主机是否开启了对应的服务,如果是防火墙阻止了连接则需要修改防火墙规则。 4. File Not Found:文件未找到,可能是因为文件不存在或者路径不正确。 解决方法:检查文件是否存在,如果路径不正确则修改路径。 5. Out of Memory:内存不足,可能是因为系统内存不足或者进程占用了过多的内存。 解决方法:增加系统内存或者优化进程内存使用。 针对以上报错,可以采取以下排错思路: 1. 了解报错信息并确定问题类型。 2. 检查相关配置文件是否正确配置,并确认是否有相关日志输出。 3. 使用命令行工具进行测试,例如ping、curl等。 4. 检查系统日志,了解系统状态。 5. 如果以上方法均无法解决问题,则可以使用搜索引擎或者向相关社区寻求帮助。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值