快捷導(dǎo)航

Nginx轉(zhuǎn)發(fā)404問題的排查和思考

更新時間：2023年09月11日 08:55:40 作者：磊叔的技術(shù)博客

本篇文章原自當(dāng)前業(yè)務(wù)遇到的一個實際問題,因為受到所在網(wǎng)絡(luò)環(huán)境的因素影響,所以整體排查下來耗費了很大精力,記錄一下Nginx 轉(zhuǎn)發(fā) 404 問題的排查和思考,需要的朋友可以參考下

項目背景

項目是 toG 項目，部署的網(wǎng)絡(luò)環(huán)境是一個大的內(nèi)網(wǎng)環(huán)境（又具體分為內(nèi)網(wǎng)和內(nèi)網(wǎng)互聯(lián)網(wǎng)區(qū)），項目涉及到小程序、前端、后端（又包括 JAVA 和 GO 兩個項目）的部署。整體的部署拓?fù)鋱D大致如下：

虛擬 IP 映射：大多數(shù)內(nèi)網(wǎng)如何需要暴露對外訪問，會在出口的核心路由上配置一個虛擬的 IP 作為對外的統(tǒng)一訪問入口。比如你的內(nèi)網(wǎng)地址及端口是 10.13.3.177:8080，則通過虛擬 IP 映射的地址及端口可能是：10.31.31.253:8080。

在這個業(yè)務(wù)流程程，訪問路徑是：公網(wǎng)（小程序前臺）-> 內(nèi)網(wǎng)互聯(lián)網(wǎng)區(qū)【10.31.1.142(nginx + 小程序后臺)】 -> 【10.31.31.253 -> 10.13.3.177(nginx+后端)】 -> 【10.233.1.2 -> 172.13.7.249(nginx+后端)】。其中 10.13.3.177 和 172.13.7.249 是兩臺虛擬機，虛擬機上部署了nginx 和后端服務(wù)。

PS：上述所有的 IP 均已做過處理，非正式 IP。

問題

訪問步驟及問題節(jié)點：

1、小程序訪小程序后臺服務(wù)
2、小程序后臺服務(wù)發(fā)起調(diào)用到 10.31.31.253（這里實際上是 10.31.1.142 要調(diào)用 10.233.1.2 的服務(wù)，因為 10.31.1.142 不能直接訪問 10.233.1.2，所以借用 10.31.31.253 來實現(xiàn)一層轉(zhuǎn)發(fā)邏輯）。

這里會涉及到兩個轉(zhuǎn)發(fā)，

10.31.31.253 對應(yīng)的 10.13.3.177 這臺機器上的 nginx 需要將 10.31.1.142 的請求轉(zhuǎn)發(fā)給 10.233.1.2
10.233.1.2 對應(yīng)的 nginx 需要將請求到當(dāng)前機器的后臺服務(wù)上

在轉(zhuǎn)發(fā)時通過 10.31.31.253 調(diào)用 10.233.1.2 時出現(xiàn) 404，10.233.1.2 調(diào)用本機后端服務(wù)時也出現(xiàn) 404；還有一個 502 是 10.31.1.142 訪問 10.31.31.253 出現(xiàn)的。下面是分析問題的大體過程和解決辦法。

因端口映射導(dǎo)致的訪問 502 問題

前面提到 10.31.31.253 和 10.233.1.2 均是虛擬 IP ，10.31.31.253:8805 端口映射到虛擬機 10.13.3.177 上的端口是 18805，10.13.3.177 上 nginx 配置的監(jiān)聽端口是 18805，所以 10.31.1.142 在訪問的第一跳是 10.31.31.253:8805，但在實際排查中發(fā)現(xiàn)， 10.31.1.142 訪問的是 10.31.31.253:18805，所以出現(xiàn) 502 問題。

狀態(tài)碼 502 表示 HTTP 協(xié)議中的 "Bad Gateway"，通常用于表示服務(wù)器作為網(wǎng)關(guān)或代理時遇到了問題。這個錯誤通常會在一個服務(wù)器作為中介時，無法從另一個服務(wù)器獲取有效響應(yīng)以滿足客戶端請求時出現(xiàn)。

proxy_pass 轉(zhuǎn)發(fā) url 丟棄路徑導(dǎo)致的 404 問題

根據(jù)前面的背景，實際上兩個 404 問題均是因為這個原因?qū)е隆?code>10.31.1.142 發(fā)起的請求是 10.31.31.253:8805/miniapp/user/case, nginx access.log 的日志如下：

"POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"
"POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"
"POST /miniapp/user/case HTTP/1.1" 404 153 "-" "Java/1.8.0_351"

因為這個請求不是 10.31.31.253 對應(yīng)的 10.13.3.177 這臺機器上的服務(wù)處理，而是直接轉(zhuǎn)發(fā)給 10.233.1.2 對應(yīng)的 172.13.7.249 機器的，因此這里出現(xiàn) 404，因為是轉(zhuǎn)發(fā)到 172.13.7.249 時沒有找到相應(yīng)的資源。查看 249 機器上的 nginx 訪問日志

"POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"
"POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"
"POST /user/case HTTP/1.0" 404 153 "-" "Java/1.8.0_351"

可以看到， 249 這臺機器上的請求變成了 /user/case，丟失了 /miniapp 這個 prefix，10.13.3.177 機器的 nginx 配置如下：

location /miniapp/ {
    // 主要是這里
    proxy_pass http://10.31.31.253:8805/;
}

關(guān)于這個問題，解決方案大致有如下幾種（來源各種技術(shù)文章）：

1、修改代理配置：將匹配以 /miniapp 開頭的所有請求，并將它們代理到 10.31.31.253:8805，保持請求 URI 不變。

location /miniapp {
    proxy_pass http://10.31.31.253:8805;
}

2、使用正則表達(dá)式捕獲和重寫 URI：捕獲以 /miniapp 開頭的請求，并將 /miniapp 后面的部分傳遞給后端服務(wù)器。

location ~ ^/miniapp(/.*)$ {
    proxy_pass http://10.31.31.253$1;
}

3、rewrite 重寫：使用 rewrite 指令將 /miniapp 后面的部分提取出來，然后將其傳遞給后端服務(wù)器

location /miniapp/ {
    rewrite ^/miniapp(/.*)$ $1 break;
    proxy_pass http://10.31.31.253;
}

4、保留 location 前綴：就是將 location 前綴保留在 proxy_pass 的后面

location /miniapp/ {
    proxy_pass http://10.31.31.253:8805/miniapp/;
}

經(jīng)測試，方案 1 和方案 4 是可以解決 404 問題的。其中方案 4 是**有病治病的邏輯，轉(zhuǎn)發(fā)丟棄則就加上。**這兩個問題對于了解 nginx proxy_pass 配置的同學(xué)來說應(yīng)該一眼就可以看到問題所在，但是 大多數(shù)時候，我們會忽略那些看起來并不是很顯眼的東西，比如 /。

proxy_pass 配置以 / 結(jié)尾和不以 / 結(jié)尾的區(qū)別

以 / 結(jié)尾的proxy_pass配置

location /miniapp/ {
    proxy_pass http://10.31.31.253:8805/;
}

這種配置方式?jīng)]有斜杠 / 結(jié)尾，意味著 Nginx 會將原始請求的 URI 原封不動地傳遞給后端服務(wù)器。例如，如果原始請求是 http://10.31.1.142/miniapp/user/case，那么 Nginx 會將它代理到http://10.31.31.253:8805/miniapp/user/case。

所以說，如果你希望將請求映射到后端服務(wù)器的根目錄，則可以使用以斜杠 / 結(jié)尾的配置。如果你希望保持URI不變，可以使用不以 / 結(jié)尾的配置。