本文適合處理 Shadowrocket（小火箭）顯示已連線、狀態列連線標記正常，但網頁或 App 仍無法連線的情況。排查順序是先建立本地網路基準，再分別驗證伺服器、Global Routing、DNS 與 Config 規則；完成後可根據對照現象判斷故障所在層級，避免同時修改多個設定。
先建立可重複的網路基準
「已連線」只代表 Shadowrocket 已在系統中建立網路通道，不代表通道內每個環節都能正常傳輸。伺服器無法連線、驗證資訊失效、DNS 查詢失敗或 Config 中的規則選擇錯誤策略，都可能造成開關已開啟但請求沒有回應。
開始排查前，先記下目前的伺服器名稱、Global Routing 模式與正在使用的 Config。一次只修改一個項目，每次修改後重新開啟同一個測試頁面。若同時更換伺服器、DNS 與規則，即使網路恢復，也無法判斷真正生效的是哪項變更。
驗證原始網路
先關閉 Shadowrocket 連線開關，透過目前的 Wi-Fi 或行動網路開啟兩個先前未造訪過的網頁。若此時也無法存取，應先處理本地網路、路由器登入頁或行動數據權限。
記錄目前設定
在 Home 記錄已選伺服器與 Global Routing，在 Config 記錄已啟用的設定名稱，在 Settings → DNS 記錄目前的 DNS 項目，避免排查後無法還原。
重新建立連線
回到 Home，關閉連線開關並等待數秒，再重新開啟。若系統要求確認網路設定，請依照系統提示完成授權，然後觀察連線狀態是否保持穩定。
執行對照測試
依序使用 Direct、Proxy 與 Config 進行測試，每次只切換 Global Routing，不更換伺服器。三組結果的差異可快速區分本地網路、伺服器路徑與規則問題。
第一層：確認伺服器狀態與參數
若關閉 Shadowrocket 後本地網路正常，而 Global Routing 設為 Proxy 後所有請求都失敗，首先檢查目前伺服器。Home 中的延遲結果只能表示測試請求是否在限定時間內回應，不能單獨證明實際流量一定可用；但持續逾時、延遲空白或測試結果突然大幅升高，仍是伺服器路徑異常的重要訊號。
開啟 Home 的伺服器列表，對目前伺服器執行可用性或延遲測試，再選擇使用者既有服務設定中的另一台伺服器進行對照。若同一網路下只有一台失敗，問題通常集中在該伺服器、連接埠或憑證；若全部失敗，請繼續檢查訂閱是否成功更新、本地網路是否限制目標連接埠，以及 DNS 是否能解析伺服器網域。
錯誤:Request timed out
原因與解法:請求在等待時間內沒有收到回應，常見原因包括伺服器離線、線路丟包或目標連接埠無法連線。先切換使用者既有設定中的另一台伺服器；若只有原伺服器失敗，請向自己的服務商確認伺服器狀態與連接埠。
錯誤:Failed to resolve hostname
原因與解法:伺服器位址使用網域，但目前 DNS 沒有回傳可用位址。進入 Settings → DNS 檢查 DNS 設定，並確認伺服器網域沒有多餘空格或拼寫錯誤。
錯誤:Network is unreachable
原因與解法:裝置目前沒有可用的網路出口，或 Wi-Fi 尚未完成入口網站驗證。關閉連線後開啟一般網頁驗證原始網路，必要時先完成 Wi-Fi 登入，再重新開啟 Shadowrocket。
錯誤:Failed to load subscription
原因與解法:訂閱位址失效、存取逾時，或伺服器沒有回傳有效內容。核對自己的連結，例如格式示例 https://example.com/sub?token=xxxx，再向自己的服務商確認連結狀態，回到 Home 下拉更新。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的參數結構不同，排查時不要將某種協定的連接埠、驗證欄位或傳輸設定套用到另一種協定。訂閱更新成功也不代表每台伺服器都在線；這只表示 Shadowrocket 成功取得並解析了設定內容。
- 伺服器位址使用網域時，先確認 DNS 能解析該網域。
- 伺服器位址使用 IP 時，DNS 對建立伺服器連線的影響較小，可優先檢查連接埠與憑證。
- 同一台伺服器在 Wi-Fi 失敗、行動網路成功時，應檢查目前 Wi-Fi 出口與路由器策略。
- 所有伺服器在兩種網路下都失敗時，應核對訂閱更新時間、帳號狀態與伺服器端狀態。
第二層：用 Global Routing 定位流量去向
Global Routing 決定請求採用統一策略，或依 Config 進行匹配。Proxy 讓請求統一採用代理策略，Direct 讓請求直接連線，Config 依規則逐條判斷，Scene 則根據預設場景選擇行為。排障時最有價值的是 Proxy、Direct 與 Config 三組對照結果。
| 測試結果 | 優先判斷 | 下一步 |
|---|---|---|
| Direct 成功，Proxy 失敗 | 本地網路可用，伺服器路徑或伺服器參數異常 | 測試其他既有伺服器，核對伺服器網域、連接埠與驗證欄位 |
| Proxy 成功，Config 失敗 | 伺服器可用，Config 規則或策略名稱有誤 | 檢查規則順序、策略群組名稱與 FINAL |
| Proxy 與 Config 成功，Direct 失敗 | 目標在目前直連網路下無法連線，或直連 DNS 結果異常 | 檢查 DNS 回傳結果，以及 Config 中對應目標的策略 |
| 三種模式全部失敗 | 本地網路、系統網路權限或 DNS 基礎設定更值得懷疑 | 關閉連線驗證原始網路，再檢查 Settings → DNS |
| Scene 下失敗，手動 Config 成功 | Scene 的觸發條件或所選設定不符合目前網路 | 檢查 Scene 對 Wi-Fi、網路狀態與設定的判斷條件 |
結論：先固定伺服器，再比較模式
在同一台伺服器下，Proxy 可存取而 Config 無法存取，已可將伺服器故障的優先級降至較低；此時繼續頻繁更換伺服器只會增加變數，應直接檢查規則命中與策略群組名稱。
若目前使用 Scene，排障階段可暫時切換至手動的 Direct、Proxy 或 Config。待基本鏈路恢復後，再回到 Scene 檢查觸發條件。如此可避免場景切換與規則匹配同時影響判斷。
第三層：檢查 DNS 解析是否中斷
DNS 的工作是將網域轉換為位址。DNS 失敗時，常見現象是伺服器延遲測試可能有結果，但輸入網域後網頁長時間停留；已建立連線或命中快取的少數 App 可能暫時正常，因此「部分可用」不能排除 DNS 問題。
進入 Settings → DNS，先記錄目前項目，再檢查是否存在無法存取的 DNS 位址、錯誤的加密 DNS URL 或重複設定。傳統 DNS 通常透過 UDP 或 TCP 53 連接埠運作，DNS over HTTPS 通常透過 HTTPS 443 連接埠運作；兩者的網路路徑不同，發生故障時應分開驗證。
記錄 DNS
開啟 Settings → DNS，保存目前位址、協定方式及相關開關狀態。若需要回復，應能還原至排障前的設定。
檢查格式
傳統 DNS 應填寫有效位址；DNS over HTTPS 應使用完整 HTTPS URL。刪除行首與行尾空格，並檢查路徑是否被截斷。
減少變數
暫時只保留一個確認可存取的 DNS 項目進行測試，不要同時疊加多個結果未知的項目。修改後重新連線，讓新設定套用至目前網路工作階段。
比較解析結果
分別測試先前從未造訪過的網域與已造訪網域。新網域失敗而快取頁面可以開啟時，DNS 查詢鏈路更值得優先檢查。
查看請求結果
在 Shadowrocket 可見的請求或日誌資訊中尋找 resolve、DNS、timeout 等提示，並記錄失敗網域，避免只根據瀏覽器的一般錯誤頁面判斷。
傳統 DNS:
伺服器位址 → UDP/TCP 53 → 回傳 A 或 AAAA 記錄
DNS over HTTPS:
HTTPS URL → TCP 443 → 加密查詢 → 回傳解析記錄如果伺服器本身使用網域，DNS 故障會發生在建立伺服器連線之前；如果伺服器使用 IP，但目標網站使用網域，則伺服器連線可能成功，而網頁請求仍會因目標網域無法解析而失敗。兩種現象都可能顯示連線開關已開啟，但故障位置並不相同。
結論：區分伺服器網域與目標網域
若日誌中先出現伺服器主機名稱解析失敗，應處理建立連線前的 DNS；若伺服器已連通，只有存取目標網域時失敗，則檢查通道內的目標解析路徑與 Config 對 DNS 請求的處理。
第四層：檢查 Config 規則順序與 FINAL
當 Proxy 可以存取而 Config 無法存取時，重點應轉向規則。Shadowrocket 的 Config 通常依序匹配，先命中的規則先決定策略；FINAL 負責承接前面都未匹配到的請求，因此通常位於規則末尾。
以下片段表示指定網域後綴採用 PROXY，區域網路位址與符合 GEOIP 條件的位址採用 DIRECT，其餘請求由 FINAL 交給 PROXY。PROXY 必須對應目前 Config 中實際存在的策略或策略群組名稱；若設定使用其他名稱，應保持規則與策略名稱完全一致。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：依網域後綴匹配，例如可涵蓋主網域及其子網域。
- DOMAIN-KEYWORD：網域包含指定關鍵字時匹配，涵蓋範圍通常比後綴規則更廣。
- IP-CIDR：依位址區段匹配；附加 no-resolve 時，不會為匹配動作額外發起網域解析。
- GEOIP：依目標 IP 的地理資料庫結果匹配，因此通常需要先取得目標 IP。
- FINAL：處理先前未命中的剩餘請求，缺少或策略錯誤可能造成未匹配流量的行為不符合預期。
規則最常見的問題不是語法數量不足，而是順序衝突。例如，範圍寬泛的 DOMAIN-KEYWORD 位於精確的 DOMAIN-SUFFIX 之前，可能提前攔截請求；涵蓋範圍較大的 IP-CIDR 位於目標規則之前，也可能讓後續規則沒有機會命中。
進入 Config，確認目前勾選的確實是正在編輯的設定。修改後儲存並重新連線，再用 Config 模式測試。若 Shadowrocket 的請求詳情顯示目標命中了 DIRECT，而預期應走 PROXY，應調整規則順序或規則內容；若顯示策略名稱不存在，則應修正規則引用。
現象:Proxy 可用，Config 無法存取
原因與解法:伺服器鏈路已通過統一代理驗證，Config 中可能存在錯誤的 DIRECT、REJECT 或策略引用。查看目標請求的命中結果，並從第一條相關規則開始檢查順序。
現象:只有部分網域無法開啟
原因與解法:失敗網域可能命中了範圍過寬的 DOMAIN-KEYWORD，或沒有被預期的 DOMAIN-SUFFIX 涵蓋。記錄完整主機名稱，新增精確規則並放在寬泛規則之前測試。
現象:修改設定後結果不變
原因與解法:可能編輯了未啟用的 Config，或目前 Global Routing 仍停留在 Proxy、Direct、Scene。回到 Home 確認 Config 模式與已選設定，再重新連線。
第五層：排除 On Demand、訂閱與本地網路干擾
Settings → On Demand 可根據網路條件觸發連線。若手動關閉後立即再次連線，或切換 Wi-Fi 後模式與預期不同，應暫時關閉 On Demand 進行基準測試。確認手動連線正常後，再逐項恢復觸發條件。
訂閱更新也是獨立環節。App 能夠開啟不代表訂閱位址目前有效，訂閱成功更新也不代表其中每台伺服器都可用。使用者應以自己既有的服務商資訊為準，核對訂閱有效性、帳號狀態與伺服器維護情況。
連線開關總是自動重新開啟？
進入 Settings → On Demand，暫時關閉按需連線，再回到 Home 手動中斷連線。若自動連線停止，表示觸發來源是 On Demand；接著檢查 Wi-Fi、網路狀態等條件，逐項恢復並測試。
Wi-Fi 下失敗，行動網路卻正常？
先關閉 Shadowrocket，在該 Wi-Fi 下開啟一般頁面，確認是否需要完成入口網站登入。原始網路正常後，再固定同一台伺服器與同一種 Global Routing 模式進行測試，以判斷目前 Wi-Fi 是否限制目標路徑。
訂閱更新成功，為什麼仍然連不上？
更新成功只代表設定內容已被取得並解析。回到 Home 對具體伺服器執行測試，並在 Proxy 模式驗證實際請求；若多台伺服器結果不同，應分別記錄，不要將訂閱更新狀態等同於伺服器在線狀態。
Direct 能用，Config 和 Proxy 都不能用？
本地網路基礎連線大致正常。先固定一台伺服器，用 Proxy 驗證伺服器鏈路；若 Proxy 失敗，檢查伺服器狀態、網域、連接埠與驗證資訊，暫時不要修改 Config 規則。
只有一個 App 無法連線怎麼辦？
先確認該 App 在關閉 Shadowrocket 時能否連線，再查看其請求網域與規則命中結果。若其他 App 在相同模式下正常，應重點檢查目標網域、IP-CIDR、REJECT 規則與該 App 自身的網路權限。
也可以檢查系統時間是否準確。部分協定依賴 TLS 或包含與時間相關的驗證，裝置時間偏差過大可能導致握手失敗。應使用系統自動設定日期與時間，再重新建立連線。切換 Wi-Fi 與行動網路後，也建議中斷並重新連線，讓路由與 DNS 工作階段重新建立。
依結果收束排查並還原設定
完成上述測試後，應將結果整理成「網路條件 + 伺服器 + Global Routing + DNS + Config」的組合。例如：「同一 Wi-Fi 下，Direct 成功，固定伺服器在 Proxy 逾時，切換另一台既有伺服器後恢復。」這類記錄能明確指出問題位於伺服器路徑，而不是籠統描述為無法上網。
若需要向自己的服務商回報，提供發生時間、網路類型、伺服器名稱、協定類型、連接埠、錯誤原文與對照結果即可。訂閱連結中的 token、密碼、Private Key 等驗證資訊不應出現在截圖或公開記錄中。
- 原始網路失敗：先處理 Wi-Fi、行動網路或入口網站驗證。
- Direct 成功、Proxy 失敗：檢查伺服器狀態、連接埠、驗證與伺服器網域解析。
- Proxy 成功、Config 失敗：檢查規則順序、策略名稱、FINAL 與目前啟用的 Config。
- 網域失敗但既有連線仍運作：檢查 Settings → DNS 及解析錯誤。
- 手動設定正常、自動場景失敗：檢查 Settings → On Demand 與 Scene 條件。
- 恢復後將臨時模式、DNS 與測試規則還原至已確認的設定。
Shadowrocket 僅透過 App Store 提供，產品頁開發者應顯示為 Shadow Launch Technology Limited，App ID 為 932747118。iPhone 與 iPad 是主要使用裝置，相容範圍及系統要求以 App Store 頁面標示為準。重新安裝前應先確認設定備份與已購項目的恢復方式，避免將重裝當作第一步排障操作。