Shadowrocket 已連線但無法上網？伺服器、Global Routing、DNS 與規則排查

本文重點

Shadowrocket（小火箭）開啟連線，只代表系統隧道已啟動，不代表伺服器、網域解析和目標網站都能正常使用。本文適用於已備妥自有服務商資訊與訂閱資料的使用者：先確認本機網路正常，再檢查伺服器，接著透過 Global Routing 進行單一變因對照，最後查看 DNS 與規則命中情形。每次只變更一項，並記錄同一目標的測試結果，避免把設定變動誤認為網路已恢復。

一、先確認問題範圍，不必急著重新安裝

先分辨是「所有請求都失敗」、「只有部分網域失敗」，還是「切換網路後才失敗」。不同情況的檢查重點也不同。系統顯示 VPN 狀態，無法證明遠端代理已完成握手；Home 顯示測試延遲，也不代表實際網頁請求一定成功。

排查時保留目前的 Config 和伺服器資訊，不要先刪除 App。刪除後重新匯入會同時改變設定、快取和選取狀態，反而失去判斷依據。若已啟用按需連線，先前往 Settings → On Demand 暫停，再手動切換連線進行測試；測試結束後恢復原設定。

建立網路基準

在 Home 關閉連線，開啟平常可直接存取的 HTTPS 網頁。若仍無法開啟，請先處理 Wi‑Fi 登入認證、行動數據權限或路由器連線問題，不要把本機網路中斷歸因於規則。
固定測試目標

選擇一個可直接連線的目標，以及一個必須透過既有代理存取的目標；每次測試都使用相同網域與頁面。頁面完整載入才算成功，舊頁面仍顯示不代表新請求成功。
記錄目前狀態

在 Home 記下目前選取的伺服器與 Global Routing 模式，再到 Config 確認目前啟用的設定。也記下目前使用 Wi‑Fi 或行動網路，後續比較時不要同時變更這些條件。
重新送出請求

開啟連線後，重新載入測試頁面並查看新產生的請求記錄。記下目標網域、時間、處理策略和錯誤訊息；不要用幾分鐘前的舊記錄判斷這次結果。

二、檢查伺服器：隧道已建立，不代表能連上遠端

在 Home 確認實際選取的伺服器，不要只確認訂閱清單中有伺服器。檢查位址、連接埠、協定和認證欄位是否與您已有的服務資訊一致。若伺服器使用網域名稱，建立代理連線前通常還需要先解析該網域，因此伺服器網域解析失敗也會造成連線無法使用。

連接埠號碼本身無法判斷協定。例如伺服器使用 TCP 443，不代表任何協定都能連上該連接埠。Trojan 的認證與 TLS 參數、VMess 或 VLESS 的傳輸設定，以及 Shadowsocks 的加密方法，都必須與伺服器端設定相符；不要只修改 Type 碰運氣，卻保留其他不相容欄位。

先測試目前項目：在 Home 使用 Connectivity Test，並接著實際開啟一次網頁。測試失敗表示還需要繼續檢查；測試成功只代表當下這條測試路徑可用。
再以相同網路交叉測試：若清單中還有其他有效項目，只切換伺服器，維持 Global Routing 與 Config 不變。若只有一個項目失敗，優先檢查該項目的參數、有效狀態與遠端服務。
最後切換網路：維持伺服器不變，從 Wi‑Fi 切換到行動網路後重做測試。若只有其中一種網路會失敗，請檢查該網路的認證狀態、出口限制，以及目前使用的傳輸方式是否可達。
檢查既有訂閱：服務參數變更時，更新您自己的訂閱，再重新選取項目。訂閱更新成功只代表能取得設定內容，不代表其中每部伺服器目前都可使用。

錯誤：`connection refused`

原因：目標端或中間設備明確拒絕連線，常見檢查項目包括位址、連接埠和服務監聽狀態。

處理方式：依照既有服務資訊確認連接埠；若資訊相符，請將發生時間、網路類型和錯誤訊息提供給自己的服務商查核，不要不斷更換 DNS。

錯誤：`i/o timeout`

原因：網路讀寫的某個階段未能在期限內完成；僅憑這則訊息無法判斷問題出在伺服器、傳輸路徑或上游目標。

處理方式：查看同一筆記錄附近的連線目標與階段，再分別測試「相同網路切換伺服器」和「相同伺服器切換網路」，縮小問題範圍。

以上是網路記錄中可能出現的底層錯誤原文，不是固定的介面提示範本。不同協定的錯誤脈絡各異，回報問題時請保留前後文，並遮蔽密碼、認證資訊與訂閱權杖。

三、Global Routing：透過 Proxy 與 Config 區分出口和規則

前往 Home → Global Routing 查看目前模式。Proxy、Direct、Config、Scene 代表不同的流量處理方式，不代表伺服器的健康狀態。排查前先記下原本的模式，短暫切換比對後再恢復；切換模式可能影響其他 App 正在進行的請求。

模式	處理方式	本次排查用途
Proxy	透過代理處理流量，不依照 Config 的一般分流規則選擇直連。	固定伺服器，測試代理出口能否完成實際請求。
Direct	使用直連路徑。	確認本機網路與目標是否可直接連線；此模式無法用來驗證代理伺服器。
Config	依據目前啟用的設定與規則決定處理方式。	與 Proxy 交叉比對，找出規則、策略或設定中的 DNS 差異。
Scene	依據已設定的場景條件套用相應的路由安排。	先檢查實際生效的場景；初步排查時改用明確模式，減少條件變動。

若相同伺服器和目標在 Proxy 下成功、在 Config 下失敗，請優先檢查目前的設定與命中策略，但不能直接斷定是「規則寫錯」。設定中的解析方式、策略組實際選取項目和拒絕規則，都可能造成差異。若兩種模式都失敗，應先回頭檢查伺服器連線與 DNS，而不是繼續增加分流規則。

結論：先記錄可重現的模式差異

若出現「Proxy 成功、Config 失敗」，請保留這組對照結果，並查看失敗請求實際命中的規則與出口。先找出差異，再修改設定；不要同時更換伺服器和 DNS。

四、檢查 DNS：分別確認伺服器網域與目標網域

一次存取可能涉及兩種解析：代理伺服器位址的解析，以及目標網站網域的解析。前者失敗時，代理連線尚未建立；後者失敗時，伺服器可能已可連線，但目標請求仍無法繼續。實際解析是在本機還是遠端執行，取決於協定與設定，不能只憑網頁一直轉圈來判斷。

目標網域解析結果規則判斷出口連線目標回應

這個流程用來說明檢查步驟，不代表所有協定都在相同位置執行解析。開啟 Config 中目前設定的編輯畫面，查看 [General] 內的 dns-server 等解析設定，並確認請求記錄是否出現解析失敗、結果為空或位址異常。若設定使用自訂解析服務，也要檢查存取該服務所需的網路路徑。

一次只變更一項：先儲存設定副本，再暫時將目前的自訂解析設定還原為已知可用的系統解析方式。重新連線後重試相同網域，避免一次替換整份 Config。
分開檢視位址類型：若記錄中有 A 與 AAAA 結果，請分別查看最後連線使用的 IPv4 或 IPv6 位址。收到 AAAA 記錄不代表目前網路具備可用的 IPv6 出口。
正確理解連接埠：傳統 DNS 通常使用 UDP 或 TCP 53；DoH 使用 HTTPS，通常會用到 TCP 443。連接埠可連線不代表解析請求一定成功，仍須查看實際回應。
不要直接用 IP 位址代替測試：HTTPS 網站通常依賴網域進行憑證驗證與虛擬主機選擇。把網址列改成 IP 位址後無法開啟，不能單憑這點判定 DNS 有問題。

五、檢查規則：查看第一個命中項目，不只確認規則是否存在

在 Config 確認目前真正啟用的設定後，檢查失敗網域對應的請求記錄。重點記下命中規則、最終策略與實際伺服器。規則會依序比對，請求一旦符合前面的規則，不會因為後面還有一條更符合預期的規則就自動改道。

以下僅用來說明順序與語法，不是可直接取代現有設定的通用方案。example.com 是示例網域，192.168.0.0/16 是私有位址範圍；其中 PROXY 與 DIRECT 是規則策略關鍵字，請勿與 Global Routing 選單中顯示的文字混淆。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

DOMAIN-SUFFIX：範例會比對 example.com 及其子網域。實際網頁可能還會請求登入、圖片和 API 網域；主頁命中不代表所有相依請求都會命中。
IP-CIDR：依目標 IP 網段比對。範例中的 no-resolve 表示不為符合這條 IP 規則的請求額外發起網域解析，不是關閉整份設定的 DNS。
GEOIP：例如 GEOIP,CN,DIRECT 會依位址所屬地區判斷，結果取決於位址與使用的資料庫；不能將它當成網域後綴規則使用。
FINAL：前面的規則都未命中時採用的最終處理方式。範例使用 FINAL,DIRECT，因此未命中前兩條規則的請求會直連；若目標需要透過代理存取，這項預設處理就可能不符合預期。

發現規則命中不符時，先確認是否啟用了預期的 Config，再檢查規則順序、網域拼寫和引用的策略。若命中的是策略組，也要核對組內實際選取的伺服器。不要只因看到 PROXY 字樣，就認定請求經過了原先預期的出口。

結論：只修正已確認錯誤的分流

若失敗記錄明確顯示目標被錯誤地直連，請先在設定副本中新增範圍精確的網域規則，並放在可能提前命中的寬泛規則之前。確認頁面及其相依請求都正常後，再決定是否保留變更。

六、常見問題：部分可用、自動重新連線與訂閱更新

有延遲數字，為什麼網頁還是打不開？

延遲數字只對應某一次特定測試，不涵蓋所有目標、DNS 路徑和網頁相依請求。維持相同伺服器，在 Proxy 模式下存取實際目標，再檢查失敗發生於解析、連線還是回應階段。

只有一個網站打不開，需要更換整份設定嗎？

先查看該網站主網域與 API 網域的請求記錄。若其他目標正常，優先檢查該目標的規則、解析結果與遠端回應。HTTP 403、429 等回應代表請求已到達某個 HTTP 服務，應繼續確認回應來源與存取條件，不要直接重新安裝。

關閉連線後又自動開啟，該如何對照測試？

前往 Settings → On Demand，暫時停用按需連線，再手動中斷連線進行測試。若裝置還套用了管理策略，也要確認相關連線要求。完成這輪排查後恢復原設定，避免長期保留測試狀態。

訂閱更新失敗和網頁無法開啟是同一個問題嗎？

不是。更新訂閱會存取設定網址，瀏覽網頁則會存取目標網站，兩者的連線路徑可能不同。先確認您自己的訂閱連結是否完整且仍有效，再檢查該網址的解析與連線路徑；更新成功後，也要重新確認 Home 中選取的伺服器。

切換到行動網路後恢復，就能確定是 Wi‑Fi 的問題嗎？

這表示問題與網路條件有關，但仍須控制變因。維持伺服器、Config 和目標不變，檢查 Wi‑Fi 是否已完成認證、能否直接連線，以及該網路是否允許目前使用的傳輸方式。不要一次同時更換協定、伺服器和解析設定。

七、還原設定並整理可重現的紀錄

找出問題後，恢復原本的 Global Routing 與 On Demand 設定，只保留已驗證且必要的變更。一次成功不代表問題已永久解決；請在原本會失敗的網路上重新送出請求，並確認中斷後再次連線，結果仍一致。

環境：裝置類型、網路類型、發生時間，以及關閉連線後是否能直接存取。
對照：同一目標在 Proxy 與 Config 下的結果，以及切換網路或既有伺服器後是否有所變化。
證據：失敗請求的網域、命中策略、錯誤原文與相鄰脈絡，並註明測試的是網頁還是 Connectivity Test。
隱私：傳送記錄前，請移除完整訂閱網址、權杖、密碼及其他認證欄位，只保留排查所需資訊。

這份紀錄能將「連線開了卻不能用」轉化為明確的問題：是無法連上伺服器、解析沒有結果、規則選錯出口，還是目標已回傳錯誤。依序驗證比反覆重設更能保留證據，也方便您自己的服務商查核遠端狀態。