Nginx 代理配置導致應用頁面加載失敗的分析與解決
前期部署信息：
部署DM數據庫DEM時，配置了nginx代理，conf配置內容如下：
charset utf-8;client_max_body_size 128M;listen 4567;server_name 192.168.1.156;root /opt/h5/;index index.html;location /tomcat {proxy_pass http://127.0.0.1:8080;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;# 隱藏 /tomcat 路徑rewrite ^/tomcat(.*)$ $1 break;}
問題現象
我遇到了一個問題：直接訪問http://192.168.1.156:8080/dem/是正常的，但是訪問 http://192.168.1.156:4567/tomcat/dem/ 時，頁面卻無法正常顯示，表現為一個不停轉圈的加載狀態，無法進入登錄界面。
或者報錯“獲取系統屬性失敗！加密響應失敗！”
分析原因
經過多次排查和測試，我發現問題主要出在 Nginx 的代理配置上，可能的原因包括以下幾點：
-
資源路徑不一致
應用中的 JavaScript、CSS 等靜態資源可能使用了相對路徑或絕對路徑。在代理過程中，如果 Nginx 沒有正確映射這些路徑，瀏覽器會無法加載資源，導致頁面卡在加載狀態。 -
路徑重寫配置問題
我嘗試使用rewrite指令隱藏代理路徑（如/tomcat），但與proxy_pass結合使用時，可能會導致請求 URL 被錯誤解析，后端應用接收到的路徑與預期不符，從而引發加載失敗。 -
代理轉發未完全適配應用需求
如果應用內部的 AJAX 請求或其他邏輯依賴特定的 URL 路徑，而 Nginx 的代理配置沒有正確處理這些請求，可能會導致功能異常。
處理方法
經過反復調整，我最終通過以下兩種 Nginx 配置方案成功解決了問題：
方法一：精確代理到 /dem/ 路徑
server {charset utf-8;client_max_body_size 128M;listen 4567; # 監聽 4567 端口，便于局域網訪問server_name 192.168.1.156;root /opt/h5/;index index.html;location /dem/ { #修改了這一行proxy_pass http://127.0.0.1:8080/dem/; #修改了這一行proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;# 嘗試隱藏 /tomcat 路徑（可選，未完全生效時可移除）rewrite ^/tomcat(.*)$ $1 break;}
}
- 配置說明：
- 通過
location /dem/將請求直接代理到http://127.0.0.1:8080/dem/，保持路徑一致性。 - 添加了基本的代理頭信息（如
Host、X-Real-IP等），確保后端能正確識別請求來源。 rewrite指令用于隱藏/tomcat路徑，但測試發現它對最終成功訪問并非必要，可根據需求保留或移除。
- 通過
方法二：代理根路徑到 Tomcat
server {listen 7890;server_name 192.168.1.156;location / {proxy_pass http://127.0.0.1:8080;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;}
}
- 配置說明：
- 將所有請求代理到
http://127.0.0.1:8080/，適用于 Tomcat 應用部署在根路徑下的場景。 - 這種方式簡單直接，減少了路徑匹配的復雜性，適合不需要額外路徑前綴的情況。
- 將所有請求代理到
結果
經過以上配置調整，我成功實現了目標：
- 方法一：訪問
http://192.168.1.156:4567/dem/，頁面正常加載并跳轉到登錄界面。 - 方法二：訪問
http://192.168.1.156:7890/dem/，同樣可以正常訪問應用，頁面加載和功能運行無異常。
兩種方法都解決了頁面加載失敗的問題，具體選擇取決于你的應用部署方式和訪問需求。
總結
通過這次排查和解決，我總結了以下幾點經驗，供其他開發者參考：
-
保持路徑一致性
在配置proxy_pass時，確保前端請求的路徑與后端應用的實際路徑一致，避免因路徑不匹配導致資源加載失敗。 -
謹慎使用路徑重寫
rewrite雖然可以隱藏代理路徑，但與proxy_pass結合使用時容易出錯。如果不需要復雜的路徑轉換，建議直接使用簡單代理。 -
調試技巧
在排查類似問題時，可以通過瀏覽器開發者工具（F12）檢查網絡請求，查看資源加載是否失敗，或查看 Nginx 的error_log日志定位問題。
希望這篇文章能幫助到遇到類似問題的朋友！如果有其他疑問，歡迎在評論區交流。
)
