运维排查篇 | 访问nginx出现403错误

vlambda
2021-06-21

运维排查篇 | 访问nginx出现403错误

点击蓝字关注我们

前言

作为一名运维人员，当系统出现故障或者错误时我们要能找出问题并解决问题，而这个过程就需要我们日积月累的排错经验和丰富的知识积累

错误现象

本次案例中使用到阿里云的服务器，通过 yum 安装了 nginx，安装时候一切正常，访问默认网站也没问题。

可是在我配置了一个新的虚拟主机并通过域名访问它的时候，报了403错误。

虚拟主机配置如下：

思路

因为这次案例涉及到计算机网络中HTTP协议的相关知识所以我们先来回顾一下

HTTP状态码表示客户端HTTP请求的返回结果，标记服务器端的处理是否正常或者出现了什么错误，我们可以根据返回的状态码来判断是否得到了正确的处理

所以HTTP状态码非常重要，我们先来看一下常见的HTTP状态码有哪些吧

1XX：接受的请求正在处理
2XX：请求正常处理完毕
3XX：需要进行附加操作以完成请求
4XX：客户端请求出错，服务器无法处理请求
5XX：服务器处理请求出错

在了解了HTTP状态码之后我们知道403是客户端请求没有权限。

我们还可以看一下 nginx 的错误日志（当出现问题时别忘了日志是我们应该优先去查看的）

nginx的访问日志和错误日志在/var/log/nginx/目录下，我们查看一下

  
    
    
  
   
     
     
   tail /var/log/nginx/error.log

Permission denied ，也就是没有权限

这下我们知道了网站不能访问的原因是客户端的请求没有权限，或者说权限被拒绝了

排查

防火墙和selinux未关闭

如果服务器防火墙和selinux没有关闭的话，是会导致出现403错误的

linux本身有两层安全防火墙，通过IP过滤机制的 iptables 实现第一层服务。iptables 防火墙通过直观地监视系统的运行情况，阻挡网络中的一些恶意攻击，保护整个系统的正常运行，免遭攻击和破坏。

第二层是 tcp_wrappers，通过 tcp_wrappers 可以实现对系统中提供的某些服务的开放和关闭、允许和禁止，从而更有效的保障系统安全地运行

而SELinux（安全增强型Linux），它是一个Linux内核模块，也是Linux的一个安全子系统。

知道了一些基础概念之后，我们来看看它们有没有打开

先看防火墙的状态

可以看到，防火墙现在是处于关闭状态的

我们再来看一下 selinux 的状态

可以看到也是处于 disabled 状态的

缺少文件资源

如果我们指定的存放资源路径里面没有相关文件，例如 index.html 或者 index.php文件

我们可以看到在我的虚拟主机配置文件里指定的资源路径为/root/my_web，我们去看一下里面有没有相关文件（也就是my_first_web.html）

可以看到，是有这个文件的，所以排除这个原因

启动用户和nginx工作用户不一致所致

一般来讲，为了安全起见，防止黑客攻击我们的nginx入侵80端口之后获得了 root 权限。我们的nginx工作用户一般不是 root

我们来查看一下

  
    
    
  
   
     
     
   [root@salted ~
   
     
     
   ]
   
     
     
   # ps -aux | grep nginx
   
     
     
   
root      
   
     
     
   12340.00.21067845168 ?     Ss   Jun17   
   
     
     
   0:00 nginx: master process nginx
   
     
     
   
nginx     
   
     
     
   34910.00.21067884212 ?     S    
   
     
     
   15:19   
   
     
     
   0:00 nginx: worker process
   
     
     
   
nginx     
   
     
     
   34920.00.21067884212 ?     S    
   
     
     
   15:19   
   
     
     
   0:00 nginx: worker process
   
     
     
   
root      
   
     
     
   37500.00.0112708984 pts/1 S+   
   
     
     
   18:36   
   
     
     
   0:00 
   
     
     
   grep --color
   
     
     
   =auto nginx

我们可以看到 master进程是由 root 用户创建的，而 worker 进程是由 master 进程创建的

我们再去到主配置文件里看一下 nginx 的工作用户是谁

可以看到工作用户是 nginx

那么就找到原因了：启动nginx的是root用户，而工作用户是nginx，两个不一致就会导致403错误

我们修改工作用户和启动用户一致

这样就成功解决！成功访问到了网站

可是，这样会导致如果我们的80端口被黑客入侵，那么黑客就拥有了 root 权限，这是我们不敢想象的。为了安全起见，我们不建议这样用。

没有资源目录的权限

其实大多数403错误，都主要是因为 nginx 没有网站资源目录的权限，所以为了安全起见，我们通常都不会将 nginx工作用户改成 root，而是去赋予网站资源目录权限

我们先去看下网站资源目录的权限

都是777权限，这是因为我之前给它提权过

咦不对啊，明明已经改成777权限了，怎么还是不行？

不知道细心的你有没有发现，我将网站资源放在了 /root目录下

  
    
    
  
   
     
     
   [root@salted my_web
   
     
     
   ]
   
     
     
   # pwd
   
     
     
   
/root/my_web

我们看一下/root目录的权限吧

可以看到是550权限，而且属主和属组都是 root，也就是说 nginx用户没有任何权限，所以才会出现403错误。

这里我们将root目录提权一下即可解决403问题

  
    
    
  
   
     
     
   [root@salted ~
   
     
     
   ]
   
     
     
   # chmod 777 /root

但是通常在业务中，我们不会将网站资源放在 root 目录下，都是放在根目录下。这样的话就不会有任何问题了

总结

当我们访问 nginx 网站的时候出现403错误，我们首先想到的是客户端请求没有权限，既然是权限问题，我们就应该照着这条线索排查下去

首先查看一下我们的防火墙和selinux，看看他们有没有关闭或者说有没有将客户端请求屏蔽掉

查看我们的网站资源相关文件存不存在，配置文件里的路径有没有写错

查看nginx的启动用户和工作用户是否一样，为了安全问题，不建议将工作用户改成 root

查看一下我们存放网站资源的目录对nginx用户是否开启了权限（通常放在根目录下而不会放在root目录下）

vlambda博客
学习文章列表