记一次生产环境大面积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 @16
2021/02/26 21:34:26 [debug] 31486#0: *56 http process request header line
2021/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 done
2021/02/26 21:34:26 [debug] 31486#0: *56 rewrite phase: 0
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"

从上面的输出日志中，我们可以看到：访问的接口地址为“/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/;  
}

location ^~ /binghe/ {  
   root /usr/local/nginx/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/abc122.html、http://test.com/test/456/11111cccc.js等

从上面的介绍可以看出，这里可以使用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 文件

好了，今天就到这儿吧，我是冰河，大家有啥问题可以在下方留言,一起交流技术，一起进阶，一起牛逼~~

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 214,776评论 6赞 496
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,527评论 3赞 389
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 160,361评论 0赞 350
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,430评论 1赞 288
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,511评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,544评论 1赞 293
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,561评论 3赞 414
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,315评论 0赞 270
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,763评论 1赞 307
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,070评论 2赞 330
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,235评论 1赞 343
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,911评论 5赞 338
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,554评论 3赞 322
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,173评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,424评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,106评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,103评论 2赞 352

推荐阅读更多精彩内容