在復(fù)雜的微服務(wù)或企業(yè)級(jí)應(yīng)用部署中，我們經(jīng)常使用多層 Nginx 架構(gòu)：外層 Nginx（如寶塔面板）負(fù)責(zé) HTTPS 卸載和全局入口，內(nèi)層 Nginx（如 Docker 容器）負(fù)責(zé)業(yè)務(wù)邏輯分發(fā)。

最近在部署 MaxKey 認(rèn)證系統(tǒng)（基于 Angular 開發(fā)）時(shí)，遇到了一個(gè)極其隱蔽的坑：后端 curl 正常，但域名訪問靜態(tài)資源報(bào) 404，且頁面陷入重定向死循環(huán)。 本文將復(fù)盤排查過程并提供標(biāo)準(zhǔn)配置方案。

一、 問題現(xiàn)象

1. 靜態(tài)資源 404：瀏覽器訪問 [https://domain.com/maxkey/assets/js.js](https://domain.com/maxkey/assets/js.js) 報(bào)錯(cuò) 404，但直接在服務(wù)器 curl 內(nèi)網(wǎng) IP 資源卻是通的。
2. 重定向次數(shù)過多：頁面無法打開，提示 ERR_TOO_MANY_REDIRECTS。
3. Docker 緩存困惑：修改前端代碼并重新打包鏡像，發(fā)現(xiàn)頁面內(nèi)容始終不更新。

二、 核心原因分析

1. 優(yōu)先級(jí)陷阱：正則匹配“劫持”了轉(zhuǎn)發(fā)

這是寶塔等集成環(huán)境最常見的坑。寶塔默認(rèn)會(huì)在站點(diǎn)配置中添加如下代碼：

location ~ .*\.(js|css)?$ {
    expires      12h;
    # ...
}

Nginx 匹配規(guī)則是： 正則匹配（~）的優(yōu)先級(jí)高于普通前綴匹配（location /maxkey/）。

當(dāng)請(qǐng)求 .js 文件時(shí)，Nginx 會(huì)進(jìn)入寶塔默認(rèn)的正則塊，試圖在本地目錄下找文件。由于文件實(shí)際在 9 號(hào)機(jī)的容器里，本地自然返回 404，轉(zhuǎn)發(fā)邏輯根本沒觸發(fā)。

2. 路徑消失之謎：斜杠的藝術(shù)

在 proxy_pass 中，結(jié)尾是否有斜杠 / 決定了路徑是“替換”還是“透?jìng)?rdquo;：

• proxy_pass http://ip/path/;（帶斜杠）：會(huì)切掉 location 匹配的部分。
• proxy_pass http://ip;（不帶斜杠）：會(huì)完整保留路徑轉(zhuǎn)發(fā)。
• 后果：如果配置不當(dāng)，后端收到的請(qǐng)求會(huì)變成 /assets/js（丟失了 /maxkey/），導(dǎo)致 Angular 路由因找不到 Base-Href 而崩潰。

3. 協(xié)議丟失導(dǎo)致的重定向死循環(huán)

外層走 HTTPS (443)，內(nèi)層走 HTTP (80)。如果外層沒有告訴內(nèi)層“用戶實(shí)際用的是 HTTPS”，內(nèi)層 Nginx 可能會(huì)嘗試發(fā)送 301 重定向讓用戶跳轉(zhuǎn)到 HTTP，而外層又強(qiáng)制 HTTPS，從而導(dǎo)致無限循環(huán)。

三、 解決方案：標(biāo)準(zhǔn)轉(zhuǎn)發(fā)模板

為了徹底解決上述問題，建議在外部網(wǎng)關(guān)（如寶塔）中使用 ^~（最佳前綴匹配）。它能強(qiáng)制跳過正則匹配，確保轉(zhuǎn)發(fā)邏輯生效。

1. 外部網(wǎng)關(guān)（寶塔/站點(diǎn)）配置

# 使用 ^~ 確保優(yōu)先級(jí)高于寶塔默認(rèn)的 .js/.css 正則塊
location ^~ /maxkey/ {
    # 顯式指向內(nèi)網(wǎng)業(yè)務(wù)服務(wù)器 IP 與端口
    proxy_pass http://10.130.135.9:8527/maxkey/; 
    # 關(guān)鍵頭部透?jìng)?
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # 核心：告訴后端當(dāng)前協(xié)議是 HTTPS，防止重定向循環(huán)
    proxy_set_header X-Forwarded-Proto $scheme;
    # 禁用可能導(dǎo)致沖突的自動(dòng)重定向修改
    proxy_redirect off;
}

2. Docker 打包與緩存清理

如果您發(fā)現(xiàn)代碼不更新，通常是 Docker 認(rèn)為 dist 目錄沒有變化。請(qǐng)?jiān)跇?gòu)建時(shí)禁用緩存：

# 強(qiáng)制重新拷貝 dist 目錄
docker build --no-cache -t maxkey-frontend:latest .
# 啟動(dòng)時(shí)強(qiáng)制重新創(chuàng)建容器
docker-compose up -d --force-recreate maxkey-frontend

四、 排查工具箱

• 抓包對(duì)比：同時(shí)在兩臺(tái)機(jī)器執(zhí)行 tail -f 觀察日志，對(duì)比 GET 路徑是否一致。
• 無痕模式：301 重定向會(huì)被瀏覽器深度緩存，修改配置后必須用 Ctrl+Shift+N 測(cè)試。
• 配置校驗(yàn)：修改 daemon.json 或 nginx.conf 后，務(wù)必先用 nginx -t 或相關(guān)工具校驗(yàn)語法，再執(zhí)行 reload。

五、 總結(jié)

在處理多層代理時(shí)，優(yōu)先級(jí)、路徑透明度、協(xié)議識(shí)別是三大核心。使用 ^~ 鎖定路徑優(yōu)先級(jí)，配合 X-Forwarded-Proto 維持協(xié)議狀態(tài)，可以解決 90% 以上的轉(zhuǎn)發(fā)異常。

以上就是Nginx多層代理下的“404”與“重定向死循環(huán)”深度排查與避坑指南的詳細(xì)內(nèi)容，更多關(guān)于Nginx 404與重定向死循環(huán)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論