关于nginx:记一次生产环境大面积404问题

写在后面

公布到线上的接口服务始终好端端的，明天忽然经营反馈说很多性能无奈失常应用。通过排查，发现前端调用后端接口时，局部接口呈现404的景象。明天，我到公司比拟晚，必定是哪个小伙伴昨晚上班，走出办公室前没有祷告服务器不要出问题。要把这个人揪出来，吊在服务器上——祭天！

文章已收录到：

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

问题复现

得悉经营的反馈后，我迅速登录服务器排查问题。首先，查看了接口服务的启动过程失常。验证接口服务的ip和端口是否失常，后果也是没啥问题。接下来，通过Nginx转发申请，此时呈现了问题，无法访问接口。同时Nginx的access.log文件中输入了如下日志信息。

192.168.175.120 - - [26/Feb/2021:21:34:21 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0"192.168.175.120 - - [26/Feb/2021:21:34:22 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0"192.168.175.120 - - [26/Feb/2021:21:34:26 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0"

此时，从Nginx日志中发现，输入的状态为404，未找到后端的接口服务。为了进一步定位问题，我间接在线上环境通过curl命令的形式来拜访接口服务，后果是失常的。

通过这一系列的操作之后，咱们就能够确定问题是出在Nginx上了。

问题剖析

Nginx开启debug模块

既然曾经定位到问题了，那咱们接下来就要剖析下产生问题的具体起因了。既然是Nginx的问题，我第一工夫想到的就是调试Nginx查找谬误起因。于是我在服务器命令行输出了如下命令来查看装置Nginx时的配置状况。

nginx -V

留神：这里曾经为Nginx配置了零碎环境变量，如果没有配置零碎环境变量，则须要输出nginx命令所在目录的残缺门路，例如：

/usr/local/nginx/sbin/nginx -v

命令行输入了如下信息。

configure arguments: --prefix=/usr/local/nginx --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module

能够看到，装置Nginx时没有配置Nginx的debug模块。

于是我在服务器上找到了Nginx的安装文件，在命令行输出如下命令从新编译Nginx。

cd /usr/local/src/nginx/  #进入Nginx的安装文件根目录make clean                #革除编译信息./configuration --prefix=/usr/local/nginx-1.17.8 --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module --with-debug  #设置编译Nginx的配置信息make     #编译Nginx,切记不要输出make install

上述命令中，切记不要输出make install 进行装置。

执行完 make 命令后，会在当前目录的objs目录下生成nginx命令，此时咱们须要先进行Nginx服务，备份/usr/local/nginx/sbin/目录下的nginx命令，而后将objs目录下的nginx命令复制到/usr/local/nginx/sbin/目录下，而后启动Nginx服务。

nginx_service.sh stop   #通过脚本进行Nginx服务mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak #备份原有nginx命令cp ./objs/nginx /usr/local/nginx/sbin/nginx #复制nginx命令nginx_service.sh start #通过脚本启动Nginx服务

留神：这里，在进行Nginx服务前，曾经将此Nginx从接入层网关中移除了，所以不会影响线上环境。为了防止应用新编译的nginx命令重启Nginx呈现问题，这里通过脚本先进行Nginx服务，而后复制nginx命令后，再启动Nginx服务。

配置Nginx输入debug日志

在Nginx的nginx.conf文件中配置如下信息。

error_log  logs/error.log debug;

此时，开启了Nginx的debug日志性能，并将debug信息输入到error.log文件中。

剖析问题

接下来，在服务器命令行输出如下命令监听error.log文件的输入日志。

tail -F /usr/local/nginx/logs/error.log

而后模仿拜访http接口，能够看到error.log文件中输入如下信息。

2021/02/26 21:34:26 [debug] 31486#0: *56 http request line: "GET /third/system/base/thirdapp/get_detail HTTP/1.1"2021/02/26 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail"2021/02/26 21:34:26 [debug] 31486#0: *56 http args: ""2021/02/26 21:34:26 [debug] 31486#0: *56 http exten: ""2021/02/26 21:34:26 [debug] 31486#0: *56 posix_memalign: 0000000000FF6450:4096 @162021/02/26 21:34:26 [debug] 31486#0: *56 http process request header line2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Host: 10.31.5.66"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept: */*"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Accept-Encoding: gzip, deflate"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Referer: http://192.168.175.100/api/index.html"2021/02/26 21:34:26 [debug] 31486#0: *56 http header: "Connection: keep-alive"2021/02/26 21:34:26 [debug] 31486#0: *56 http header done2021/02/26 21:34:26 [debug] 31486#0: *56 rewrite phase: 02021/02/26 21:34:26 [debug] 31486#0: *56 test location: "/"2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "file/"2021/02/26 21:34:26 [debug] 31486#0: *56 test location: ~ "/base"2021/02/26 21:34:26 [debug] 31486#0: *56 using configuration "/base"

从下面的输入日志中，咱们能够看到：拜访的接口地址为“/third/system/base/thirdapp/get_detail”，如下所示。

2021/02/26 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail"

Nginx在进行转发时，别离匹配了“/”，“file/”，“~/base”，最终将申请转发到了“/base”，如下所示。

2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "/"2021/02/26 21:34:26 [debug] 31486#0: *56 test location: "file/"2021/02/26 21:34:26 [debug] 31486#0: *56 test location: ~ "/base"2021/02/26 21:34:26 [debug] 31486#0: *56 using configuration "/base"

咱们再来看看Nginx的配置，关上nginx.conf文件，找到上面的配置。

location ~/base {  proxy_pass                  http://base;  proxy_set_header Host $host:$server_port;}location ~/third {  proxy_pass                  http://third;  proxy_set_header Host $host:$server_port;}

那么问题来了，拜访的接口明明是“/third/system/base/thirdapp/get_detail”，为啥会走到“/base”上面呢？

说到这里，置信仔细的小伙伴曾经发现问题了，没错，又是运维的锅！！

解决问题

看了Nginx的配置后，置信很多小伙伴应该都晓得如何解决问题了，没错那就是把nginx.conf中的如下配置。

location ~/base {  proxy_pass                  http://base;  proxy_set_header Host $host:$server_port;}location ~/third {  proxy_pass                  http://third;  proxy_set_header Host $host:$server_port;}

批改为如下所示。

location /base {  proxy_pass                  http://base;  proxy_set_header Host $host:$server_port;}location /third {  proxy_pass                  http://third;  proxy_set_header Host $host:$server_port;}

去掉“~”符号即可。

接下来，再次模仿拜访http接口，可能失常拜访接口。

接下来，将Nginx的debug性能敞开，也就是将nginx.conf文件中的 error_log logs/error.log debug; 配置正文掉，如下所示。

# error_log  logs/error.log debug;

从新加载nginx.conf文件。

nginx_service.sh reload

最终，将Nginx退出到接入层网关，问题解决。

科普Nginx的转发规定

Nginx的location语法

location [=|~|~*|^~] /uri/ { … }

= 严格匹配。如果申请匹配这个location，那么将进行搜寻并立刻解决此申请
~ 辨别大小写匹配(可用正则表达式)
~* 不辨别大小写匹配(可用正则表达式)
!~ 辨别大小写不匹配
!~* 不辨别大小写不匹配
^~ 如果把这个前缀用于一个惯例字符串,那么通知nginx 如果门路匹配那么不测试正则表达式

示例1：

location  / { }

匹配任意申请

示例2：

location ~* .(gif|jpg|jpeg)$ ｛    rewrite .(gif|jpg|jpeg)$ /logo.png;｝

不辨别大小写匹配任何以gif、jpg、jpeg结尾的申请，并将该申请重定向到 /logo.png申请

示例3：

location ~ ^.+\.txt$ {    root /usr/local/nginx/html/;}

辨别大小写匹配以.txt结尾的申请，并设置此location的门路是/usr/local/nginx/html/。也就是以.txt结尾的申请将拜访/usr/local/nginx/html/ 门路下的txt文件

alias与root的区别

root 理论拜访文件门路会拼接URL中的门路
alias 理论拜访文件门路不会拼接URL中的门路

示例如下：

location ^~ /binghe/ {     alias /usr/local/nginx/html/binghetic/;  }

申请：http://test.com/binghe/binghe...
理论拜访：/usr/local/nginx/html/binghetic/binghe1.html 文件

location ^~ /binghe/ {     root /usr/local/nginx/html/;  }

申请：http://test.com/binghe/binghe...
理论拜访：/usr/local/nginx/html/binghe/binghe1.html 文件

last 和 break关键字的区别

（1）last 和 break 当呈现在location 之外时，两者的作用是统一的没有任何差别

（2）last 和 break 当呈现在location 外部时：

last 应用了last 指令，rewrite 后会跳出location 作用域，从新开始再走一次方才的行为
break 应用了break 指令，rewrite后不会跳出location 作用域，其整个生命周期都在以后location中。

permanent 和 redirect关键字的区别

rewrite … permanent 永久性重定向，申请日志中的状态码为301
rewrite … redirect 长期重定向，申请日志中的状态码为302

综合实例

将合乎某个正则表达式的URL重定向到一个固定页面

比方：咱们须要将合乎“/test/(\d+)/[\w-.]+” 这个正则表达式的URL重定向到一个固定的页面。合乎这个正则表达式的页面可能是：http://test.com/test/12345/ab...、http://test.com/test/456/1111...

从下面的介绍能够看出，这里能够应用rewrite重定向或者alias关键字来达到咱们的目标。因而，这里能够这样做：

（1）应用rewrite关键字

location ~ ^.+\.txt$ {    root /usr/local/nginx/html/;}location ~* ^/test/(\d+)/[\w-\.]+$ {    rewrite ^/test/(\d+)/[\w-\.]+$ /testpage.txt last;}

这里将所有符合条件的URL（PS：不辨别大小写）都重定向到/testpage.txt申请，也就是 /usr/local/nginx/html/testpage.txt 文件

（2）应用alias关键字

location ~* ^/test/(\d+)/[\w-\.]+$ {    alias /usr/local/nginx/html/binghetic/binghe1.html;}

这里将所有符合条件的URL（不辨别大小写）都重定向到/usr/local/nginx/html/binghetic/binghe1.html 文件

好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，也能够加我微信：sun_shine_lyz，我拉你进群，一起交换技术，一起进阶，一起牛逼~~