2026-10-15 · 故障排除 · 約 9 分鐘

Shadowrocket 開關已開啟卻無法上網:伺服器、模式、DNS 與規則逐項排查

連線開關已開啟但網頁無法載入時,依序檢查伺服器是否可用、Global Routing 模式是否合適、DNS 設定是否異常,以及 FINAL 與 REJECT 規則是否誤擋,逐步縮小問題範圍。

本文重點

Shadowrocket(小火箭)的開關代表本機連線狀態,不表示伺服器、DNS 與目標網站都能正常使用。本文以使用者已有自己的服務與設定為前提,依序檢查基礎網路、伺服器參數、Global Routing、DNS 與規則;每次只變更一個項目,使用同一網址重新測試,最後還原日常設定。

一、先區分本機通道與實際請求

系統顯示 VPN 狀態,表示裝置已建立相應的本機網路通道;遠端伺服器是否接受連線、網域能否解析、規則最後將請求導向何處,仍須分別確認。別只因開關維持開啟,就認定問題一定出在瀏覽器,也不要把所有網頁無法載入的情況都歸因於 DNS。

App 請求 本機通道 解析與分流 對外連線 目標回應

這條流程用來劃分檢查範圍,不代表所有請求都嚴格依照相同順序完成解析與分流:網域規則可能先比對,部分 IP 規則則可能需要解析結果。先進行以下對照,確認連基礎網路是否也無法使用。

  1. 記下目前 Home 選取的伺服器、Global Routing 模式,以及 Config 中啟用的設定;變更前先保留可還原的副本。
  2. 暫時關閉 Shadowrocket,使用 Safari 開啟平時可直接瀏覽的網頁。若仍無法載入,先完成 Wi-Fi 認證頁面,或檢查行動數據權限與目前網路狀態。
  3. 基礎網路恢復後再開啟連線,瀏覽同一網頁,並記錄是全部無法載入、部分網域無法載入,還是只有某個 App 無法使用。
  4. 情況允許時,分別使用 Wi-Fi 與行動數據重新測試一次。切換網路後重新送出請求,不要把舊頁面的快取結果當成新的測試結果。

二、確認 Home 伺服器與既有訂閱

在 Home 確認目前選取的伺服器確實來自自己的有效設定,而非已失效的舊項目。執行 Connectivity Test 可作為連線能力的參考,但測試目標、方式與實際瀏覽的網站並不完全相同:測出延遲數值不代表所有網頁都能載入,測試逾時也須搭配實際連線記錄判斷。

若項目來自訂閱,請確認訂閱是否成功更新,以及清單是否仍保留舊資訊。需要更新時,在 Home 更新既有訂閱,並前往 Settings → Subscribe 檢查相關設定。更新訂閱是取得設定,連線至伺服器則是實際對外連線,兩者並非同一項請求;更新成功不代表項目可用,更新失敗也不能直接證明所有既有項目都已失效。

錯誤:connection refused

原因與處理方式:通常表示目標位址或中間設備明確拒絕連線——先核對該筆連線記錄指向的是伺服器還是目標網站,再檢查位址、連接埠與遠端監聽狀態,不要直接修改 DNS。

錯誤:i/o timeout

原因與處理方式:表示某個 I/O 步驟等待逾時,單看這行無法判定問題位置——請依據前後記錄判斷發生在解析、伺服器連線還是目標存取,再換另一種基礎網路進行對照。

以上是連線記錄中可能出現的錯誤片段,並非每台裝置都會顯示相同訊息。提供排查資訊時,請保留錯誤原文與發生階段,並隱藏密碼、UUID、私鑰與訂閱 token;不要公開完整設定。

三、透過 Global Routing 比較模式與規則

在 Home → Global Routing 確認目前模式。Proxy、Direct、Config、Scene 的用途各不相同,不能把「連線已開啟」理解為「所有請求都使用所選伺服器」。尤其是 Direct,即使開關已開啟,請求也不會因此自動改由遠端代理處理。

4 種
Global Routing 模式:Proxy / Direct / Config / Scene
53
傳統 DNS 常用連接埠,通常使用 UDP,也可使用 TCP
443
HTTPS 與 DoH 通常使用的連接埠,不代表連線一定可達
模式說明排查用途
Proxy以代理方式處理請求短暫確認所選代理路徑,排除 Config 規則分流的影響
Direct以直連方式處理請求對照目前網路的直連狀況,不能用來證明遠端伺服器可用
Config依據目前設定的規則決定處理策略檢查符合條件的規則、策略群組與最終連線方向
Scene依照已設定的場景選擇路由確認目前網路對應的場景及其實際生效設定

保持伺服器與瀏覽網址不變,短暫切換 Proxy 與 Config 進行對照。如果 Proxy 可正常瀏覽而 Config 失敗,應優先檢查規則與策略群組,但也要留意兩種模式下的 DNS 或請求路徑可能不同。如果兩種模式都失敗,優先繼續確認伺服器、基礎網路與 DNS,不必立即刪除整份設定。

Scene 須搭配既有場景判斷,不能假設它等同於 Config。測試完成後請還原原本模式;用來對照的 Proxy 並非日常設定的通用替代方案。

四、確認有明確依據後再調整 DNS

DNS 會將網域解析為位址。如果伺服器位址本身也是網域,連線至遠端之前就可能需要先解析;網頁請求的網域也可能涉及另一段解析流程。因此,「伺服器網域無法解析」與「目標網頁網域無法解析」應分開記錄。

  1. 確認影響範圍:分別測試兩個自己常用的網域。若只有單一網域失敗,先檢查該網域及其解析記錄,不要立即更換全域設定。
  2. 查看生效中的設定:在 Config 確認目前使用的檔案,檢查其中與 DNS 有關的設定,並與 Settings 中實際啟用的 DNS 選項交叉比對。只查看未啟用的設定檔沒有診斷意義。
  3. 確認上游可連線:自訂 DNS 位址必須能透過目前路徑連線。使用 DoH 時,HTTPS 連線、憑證驗證及其服務網域解析也都可能是必要條件。
  4. 單項還原:若問題是在修改 DNS 後發生,先還原修改前的設定,再重新連線並送出請求。不要同時修改 DNS、伺服器與規則,否則無法判斷是哪項變更造成影響。

若記錄顯示憑證名稱不符或憑證已過期,請先檢查裝置日期與時間、服務參數中的伺服器名稱,以及遠端憑證。不要關閉憑證驗證來掩蓋問題,也不要將 TLS 錯誤當成一般 DNS 逾時處理。

五、檢查 FINAL、REJECT 與規則順序

若問題主要發生在 Config 模式,請開啟目前使用的 Config,依規則順序檢查目標網域會符合哪一條規則。規則通常由上而下比對,前面的規則一旦符合,便不會再交由後面的例外規則處理。只在末尾新增允許規則,無法覆蓋前面的 REJECT。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

這段內容僅用於說明語法,example.com 與 192.0.2.0/24 是範例,不應整段取代目前使用的設定。範例中的 FINAL,DIRECT 表示未符合前序規則的請求最後會直連,並不代表所有使用者都應採用此策略。

網頁能載入,但圖片、登入或 API 失敗時,請檢查失敗資源所屬的網域,而不只看網址列中的主網域。若確認某條規則誤擋,請先備份,再調整該規則的範圍、順序或策略;重新測試成功後,保留幅度最小的修改。不要只為了解決單一網頁就刪除所有拒絕規則。

六、依照狀況重新測試並留下精簡記錄

完成一項修改後,使用原本的網址重新測試。建議記錄網路類型、伺服器項目名稱、Global Routing 模式、失敗網域、錯誤原文與測試時間,以便區分偶發失敗和可重現的問題。以下問答整理常見的排查方向。

「延遲測試有數值,為什麼網頁還是無法載入?」

測試成功只代表測試所涵蓋的目標與路徑正常。在 Home 確認選取的項目,再用同一網頁分別比較 Proxy 與 Config;若只有 Config 失敗,請檢查相關網域的規則與最終策略。

「只有 Wi-Fi 無法使用,切換到行動數據就正常?」

先關閉連線,確認 Wi-Fi 已完成認證,再保持伺服器與設定不變重新測試。若仍只有該 Wi-Fi 無法使用,請檢查其 DNS、相關連接埠及 UDP 路徑是否可達;不要因此直接認定整份設定有誤。

「網頁正常,但某個 App 一直轉圈,該怎麼辦?」

重新開啟該 App,觀察它實際請求的網域,並檢查 API、媒體或登入請求是否被 REJECT,或被分配到不同策略。主網頁可用,不代表 App 所依賴的每個網域都正常。

「訂閱更新失敗,需要刪除所有伺服器嗎?」

不必先清空清單。先保留目前項目,確認訂閱連結狀態,再前往 Settings → Subscribe 檢查更新相關設定;只有確認既有參數已失效後,才依照自己的有效服務資料更新。

若仍無法找出問題,請向自己的服務支援方提供已去除敏感資訊的錯誤片段與上述對照結果。Shadowrocket 用戶端的購買與遠端服務狀態是兩回事;重複取得 App 無法修復失效伺服器或錯誤規則。本網站不提供、不販售也不推薦任何節點或訂閱。

下載 Shadowrocket