記一次生產環境大面積404問題！

冰河團隊發表於2021-03-29

寫在前面

釋出到線上的介面服務一直好端端的，今天突然運營反饋說很多功能無法正常使用。經過排查，發現前端呼叫後端介面時，部分介面出現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/;  
}

請求：http://test.com/binghe/binghe1.html
實際訪問：/usr/local/nginx/html/binghetic/binghe1.html 檔案

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

請求：http://test.com/binghe/binghe1.html
實際訪問：/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/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 檔案

好了，今天就到這兒吧，我是冰河，大家有啥問題可以在下方留言，也可以加我微信：sun_shine_lyz，我拉你進群，一起交流技術，一起進階，一起牛逼~~

一次生產環境OOM排查
2024-03-01
OOM
一次生產環境的docker MySQL故障
2022-05-26
DockerMySql
記一次生產頻繁發生FullGC問題
2023-03-16
GC
一次生產環境CPU佔用高的排查
2023-02-10
記一次生產環境tomcat執行緒數打滿情況分析
2020-08-12
Tomcat執行緒
Flink生產環境常見問題
2023-12-19
ForkJoinPool在生產環境中使用遇到的一個問題
2024-03-24
Laravel 在 Docker 環境下訪問 storage 靜態資源 404 問題解決
2020-03-26
LaravelDocker
記一次測試環境壓測問題深究
2021-09-03
windows系統配置nginx環境執行pbootcms訪問首頁直接404的問題
2024-10-04
WindowsNginxboot
Spark 環境問題記錄和解決方法
2020-07-03
Spark
一、Windows 環境搭建問題彙總
2018-07-22
Windows
如何在生產環境排查 Rust 記憶體佔用過高問題
2021-11-03
Rust記憶體
介面詭異的404問題記錄
2018-08-16
記錄一次遷移環境 .env 出現的問題
2021-04-06
Golang GRPC 環境問題
2024-05-30
GolangRPC
**開發環境一些基本問題
2018-03-25
開發環境
Flink生產環境常見問題及解決方法
2024-02-04
Arthas 實踐——生產環境排查 CPU 飈高問題
2020-11-30
記一次生產問題的排查，讓我領略了演算法的重要性
2022-05-03
演算法
記一次生產事故磁碟被佔滿
2020-02-10
解決所有環境問題
2020-10-12
laravel 路由404問題
2020-10-28
Laravel路由
記一次hadoop yarn環境無法提交任務的問題排查
2024-04-19
HadoopYarn
記錄一次 Nginx 配置 proxy_pass 後返回404問題
2021-01-04
Nginx
webpack（1）安裝環境與解決環境問題
2021-07-09
Web
記錄Ajax請求報415與404問題
2021-10-26
idea 訪問 jsp 404問題
2021-07-30
IdeaJS
記錄一次生產釋出事件——(簡單的非空驗證也能引發大問題)
2019-06-12
事件
【環境踩坑】ubuntu下jupyter的環境設定問題
2020-12-02
Ubuntu
Flutter配置環境常見問題
2019-02-16
Flutter
mac 配置mysql環境 Navicat 問題
2019-03-31
MacMySql
go專案起步-環境問題
2020-12-26
Go
生產環境部署springcloud微服務啟動慢的問題排查
2021-10-29
SpringGCCloud微服務
伺服器LNMP環境搭建的一些問題
2020-06-17
伺服器LNMP
linux伺服器環境搭建問題
2024-04-17
Linux伺服器
Linux環境變數問題彙總
2018-04-24
Linux變數
app 測試環境切換問題
2020-12-19
APP