寶塔反向代理的首頁能開，內頁卻404，先查後端實際收到的路徑。代理不是只把IP換成域名；公開網址的前綴、後端路由、請求Host和靜態資源地址都可能影響結果。
以下依寶塔及Nginx官方文件整理診斷方法。配置片段只解釋Nginx一般原理，不是宣稱某個寶塔版本一定生成相同內容，也沒有替你的網站執行修改。先把預期映射寫清楚，再核對現場。
先列出公開路徑與後端路徑
假設訪客使用/api/users，後端究竟需要/users，還是/api/users？先從後端路由與部署文件確認，不能只因首頁回應成功，就推斷所有內頁都能接受同樣的前綴。
也確認代理的是整個網站，還是其中一個目錄。若只代理/api/，其他路徑可能仍由原站點處理；它們各自的404不能直接合併為同一個代理錯誤。記錄一條已知有效的後端路由，作為核對基準。
寶塔官方反向代理頁要求目標URL可以正常訪問，並提供代理目錄與發送域名等欄位。代理目錄涉及高級功能，介面能力以你的版本為準，不要在欄位不存在時用另一個近似選項代替。
Nginx的proxy_pass有沒有URI，含義不同
Nginx官方proxy_pass說明，帶URI時，匹配location的那部分標準化請求URI會被指定URI替換；不帶URI時，通常按文件所列條件傳遞原始或完整變更後的請求URI。簡單前綴範例可以先看以下差異。
location /api/ {
proxy_pass http://127.0.0.1:3000/;
}
location /api/ {
proxy_pass http://127.0.0.1:3000;
}第一段的目標包含/這個URI，對/api/users的簡單映射會移除匹配的/api/，交給後端/users。第二段目標沒有URI，在未另外改寫的普通請求中保留/api/users。兩段是互相對照的替代範例，不要同時貼進同一份配置。
這個差異不是「永遠要加斜線」的口訣。選哪一種取決於後端需要的路徑；正則location、命名location、rewrite及變數又有文件列出的特殊條件。遇到它們時按完整配置核對，不能只盯著最後一個字元。
回到寶塔核對真正生成的配置
面板欄位保存成功，只能先證明設定已被接受，還要查看實際站點配置和回應。不同版本或服務可能有不同生成方式，不能把上面的Nginx例子冒成寶塔UI一定產生的結果。
若要檢查Nginx，先找到目標站點及匹配的location，再看proxy_pass與相關改寫。Nginx核心文件說明location選擇有匹配規則，另一段更具體或正則配置可能接手請求；不是所有/api/網址都一定由你剛看到的那段處理。
變更前保存原配置，避免直接覆蓋其他站點或原有規則。若服務不是Nginx，改查對應服務的代理文件，不將Nginx指令貼到不同配置格式中。
404是誰回的，要靠紀錄核對
MDN將404定義為伺服器找不到請求資源；狀態本身沒有告訴你是哪一層回應。它可能來自前面的Web服務，也可能是後端收到不正確路徑後回傳，再由代理轉交。
保存完整網址、時間和回應，再核對相應的代理與後端日誌。前端日誌記錄的公開URI與後端記錄的路由如果不同，正是定位前綴變換的線索；不要只因錯誤頁有某個服務名稱，就斷言整個問題的來源。
Nginx日誌文件說明，可以按配置使用相應格式記錄請求。實際欄位取決於log_format與相關設定，不能假設每台機器都已記錄上游狀態。若沒有該欄位，先查現有證據，不替日誌補出想像的值。
發送域名影響後端選中的站點
寶塔官方頁把發送域名描述為傳遞到代理請求頭的域名，預設使用目標URL域名，並提醒設定不當可能導致代理不能正常運行。若後端依Host選站點，路徑正確也仍可能收到另一個虛擬站點的回應。
先確認後端需要的Host，再查看實際代理設定。不要因為公開域名和後端域名不同，就一律把某個值改成公開域名；後端可能正是依內部名稱安排服務。
若你自己使用proxy_set_header，依Nginx官方說明核對其作用與變數。請求頭設定和URI改寫是不同工作，改其中一項不代表另一項已符合後端需求。
首頁成功後，也要查靜態資源網址
應用部署在子路徑時，HTML中的絕對資源地址可能仍指向根目錄。例如頁面在/app/，資源卻要求/assets/；該請求可能根本沒有進入/app/代理。先看瀏覽器真正要求的資源網址，再查相應路徑。
這類問題可能需要應用的公開基底路徑設定，而不是再加一個泛用替換規則。寶塔內容替換僅在Nginx提供，官方頁列有條數限制；不要把文字替換當成可靠修復所有腳本、API與資源地址的辦法。
如果是WebSocket或其他特殊協定，也另外依服務能力核對。本篇聚焦普通HTTP路徑診斷，不用一張首頁成功的畫面，替所有連線模式作驗收。
代理後重新核對原有存取限制
寶塔官方頁明確提醒，設定反向代理後，訪問限制中相應路徑的規則會失效。因此，不能只確認頁面能開，就認定原本的存取控制仍在相同位置生效。
先列出原本需要保護的管理、私人內容與寫入入口，再確認目前由哪一層負責限制。不要為了消除404就放開所有路徑，也不要把後端只綁本機，直接推斷公開代理入口必定安全。
後端位址以代理服務的環境為準
目標URL若使用127.0.0.1，它指向代理服務所在環境的本機，不一定是你操作瀏覽器的電腦。容器、另一台主機或不同網路安排，都要按實際部署核對；不要把某個教學的本機端口原樣填入，卻沒有確認那裡存在需要的服務。
連線失敗時先核對目標入口可達性，收到404時再查路徑和後端路由。兩種現象分開記錄，能避免為了處理網路問題反覆改URI，或為了處理錯誤路由去更換正常的端口。
用路徑樣本收束變更
保存首頁、合法內頁、靜態資源、需要參數的路徑與必要例外的核對結果，對照公開URI和後端路由。出現錯誤時按匹配、URI、Host與應用資源地址逐項查，不同時猜改所有設定。
最後把原配置、預期映射及驗收時間放在維護紀錄。下次更新後端路由，就能直接檢查代理前綴是否仍合適，不必重新用「加斜線或刪斜線」碰運氣。
評論0