nginx故障实例--附带排查思路
一 Nginx工作场景
Nginx是最受欢迎的HTTP服务器之一,在我们公司扮演着举足轻重的作用,做为我们公司的核心组件之一,在整个访问链路上是不可或缺的一环,而且, Nginx组件、模块、版本众多, 所以如何管理好Nginx将显得至关重要.
Before we get started,我们先来看看Nginx的工作场景:
「1」静态资源的web服务器
「2」http、smtp、pop3等协议的反向代理服务器
「3」缓存加速和负载均衡
我们公司主要用到了Nginx的第二个功能,即反向代理服务器,我们的服务都通过Nginx代理至Real Server,既保证Real Server的安全性,也起到了访问流量的负载均衡.
二 Nginx问题处理流程
1 Nginx自身排查
如果出了问题,第一时间检查是否是nginx自身因素导致的服务不可用,
「1」检查Nginx服务是否启动,
sudo lsof -P -n -i :80 -i :443 | grep LISTEN
ps aux | grep nginx「2」如果服务宕掉,先试着启动服务
sudo /opt/nginx/sbin/nginx -c /opt/nginx/conf/nginx.conf「3」如果2成功,则访问对应的服务,看是否正常,
如果2失败,则需要检查nginx的配置文件,以及各功能模块,为了能够更加精确的定位,我们需要开启debug模式.然后执行:
nginx –t
tail –f /data/log/nginx/error.log「4」可查看nginx编译时的参数,看看是不是有些功能模块未编译进来.
nginx -V2 外界因素排查
这里的外界干扰主要Nginx这一环以外的问题导致服务不可用,像Navigator,APIRouter等.
「1」 如果是新发的配置,确保Navigator发布的版本生效
「2」 绑定该nginx集群对应的LB的外网地址到本地hosts,观察访问服务是否可用
「3」 检查DNS records
如果「2」可用,则说明是Nginx之前的环节出了问题,此时需使用dig 工具查看看解析是否正确.如果是解析错误,修正即可.
dig 域名
dig –t A +trace 域名
3 根具返回客户端状态判断故障发生点
「1」3xx类响应码
3xx类状态码,通常为重定向类响应状态码,其中301为永久重定向,302为临时重定向,304表示从缓存中响应,如果访问某域名是,出现跳转问题,那么就要检查nginx的配置,看看rewrite规则是否合理,location是否出现优先级问题.「2」4xx类响应码
4xx类状态码,通常来说表示客户端类错误,
如果出现400错误, 通常表示client发送了一个无效的请求.如果一个http1.1的请求没有host域，那么server应该给client段发送400的状态码，表明这个请求server不能处理。
如果出现403错误,会提示Forbidden,表示禁止访问,这类原因通常来说会有2种可能,一是:客户端请求的资源做了黑白名单,或者是一些特殊的资源(例如:status页面);二是:
如果出现404错误,会返回NOT Found状态吗,产生这种错误,一般是用户发起了错误的请求,请求的资源不存在. Nginx需要访问目录，但是autoindex选项被关闭.「3」5xx类响应码
500类响应码通常表示服务器端出现了问题,这里可能是nginx除了问题,也又可能是后端Real Server出现了故障.
502错误会返回Bad Gateway,及网关错误,这中情况,可能与cgi类型有关
504 错误会返回Time Out,通常表示nginx作为代理时，没有及时从上游服务器收到请求,这中情况要么是后端服务处理不了nginx转发的请求,导致请求超时,要么就是后端服务器除了故障,比如服务意外停止…三 常见的状态码
状态码信息查询地址:https:///zh-CN/docs/Web/HTTP/Status
|
状态码 |
含义 |
解释 |
|
状态码 |
含义 |
解释 |
|
200 |
OK |
请求正常处理完毕 |
|
301 |
Moved Permanently |
永久重定向 |
|
302 |
Found |
临时重定向 |
|
304 |
Not Modified |
条件式请求,资源未该被修改 |
|
400 |
Bad Request |
请求报文语法错误或参数错误 |
|
401 |
Unauthorized |
需要通过HTTP认证，或认证失败 |
|
403 |
Forbidden |
请求资源被拒绝(例如:黑名单,状态检测资源等) |
|
404 |
Not Found |
无法找到请求资源 |
|
409 |
Conflict |
表示请求与当前服务器端的状态相冲突;冲突最有可能发生在对 PUT 请求的响应中。例如，当上传文件的版本比服务器上已存在的要旧，从而导致版本冲突的时候，那么就有可能收到状态码为 409 的响应。 |
|
500 |
Internal Server Error |
服务器故障或Web应用故障 |
|
502 |
|
代理服务器，从上游服务器中接收到的响应是无效的 |
|
503 |
Service Unavailable |
服务器超负载或停机维护 |
|
504 |
|
代理服务器无法在规定的时间内获得想要的响应 |
|
505 |
|
表示服务器不支持请求所使用的 HTTP 版本 |
补充
[root@web html]# nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] still could not bind()
此端口被占用了，80端口被其他进程占用了，找出来杀掉
或者nginx配置其他端口
解决
1.寻找进程-杀进程---
找
ps aux |grep nginx
ss -tulpn |grep nginx
netstat -tulpn |grep nginx
杀
kill nginx
kill -9 nginx
pkill nginx
pkill -9 nginx
2.配置其他端口
找到自己的nginx配置目录，如果是自己编译安装的，直接配置其他端口就可了，listen哪里的监听 后面改一下其他端口
不知道如何查找的，可以用ps +grep 或者which
tips：
查找Nginx的安装路径有多种方法，以下是一些常见的方式：
1. **通过`which`命令查找可执行文件路径**：
```bash
which nginx
```
这将返回Nginx的可执行文件路径，通常该路径所在的目录就是Nginx的主要安装目录的一部分。
2. **查看进程信息**：
```bash
ps -ef | grep nginx
```
查看Nginx的运行进程信息，找到进程对应的命令行路径，该路径就是Nginx可执行文件的路径。
3. **通过配置文件路径推测**：
Nginx的配置文件通常位于`/etc/nginx/nginx.conf`，而配置文件所在目录的上级目录往往是Nginx安装目录的一部分。
4. **通过系统服务信息**：
对于使用systemd的系统，可以查看Nginx服务单元文件来获取相关信息：
```bash
systemctl cat nginx | grep 'ExecStart='
```
或者
```bash
systemctl status nginx | grep 'Main PID:'
```
这样可以从输出中看到Nginx服务的启动命令和进程ID，进而推断出Nginx的安装路径。
5. **手动安装时指定的路径**：
如果你是手动编译安装的Nginx，并且记得当时使用了`--prefix`选项指定安装路径，那么你就可以直接去那个路径下寻找。
综合以上方法，通常能找到Nginx的安装路径。
