Shadowrocket 故障排除手冊

一、先建立可重複的排查基準

故障排除的第一步不是立即修改參數，而是確認問題發生在哪一層。Shadowrocket 建立連線時，會依序涉及目前的 Wi-Fi 或行動網路、系統 VPN 設定、所選伺服器、協定參數、規則比對、DNS 解析以及目標網站回應。任一層失敗，都可能表現成「網頁打不開」。若跳過分層判斷，只是不斷切換開關，往往會把一個明確問題變成多個變數同時變動的問題。

先記錄現象，不要以印象代替結果

開始前記下四項資訊：異常發生在 Wi-Fi、行動網路，還是兩者皆有；關閉 Shadowrocket 後一般網頁能否存取；連線開關能否保持開啟；異常影響所有網域、單一網域，還是某類 App。也應記錄目前的 Global Routing 是 Config、Proxy 還是 Direct，以及剛才是否更新過訂閱、修改過 Config、切換過伺服器或變更過 DNS。這裡不需要保存敏感的伺服器內容，只需記下操作順序與結果。

「能連線」與「能正確傳輸」不是同一件事。系統狀態列顯示 VPN 標記，只代表系統接受了連線設定；不代表伺服器一定可達，也不代表規則一定會把請求交給預期的策略。反過來，某個網站打不開也不等於整個連線失效，可能只是該網域命中了 REJECT、DNS 回傳異常、目標網站拒絕回應，或目前規則將它交給了不可用的策略群組。

用最少變數完成四組對照

1. 關閉 Shadowrocket，在目前網路中開啟兩個平時穩定可存取的頁面，確認本機網路本身能夠傳輸資料。
2. 維持相同網路與相同伺服器，將 Global Routing 暫時設為 Proxy，觀察問題是否仍然存在。
3. 其他條件不變，將 Global Routing 改為 Direct，判斷系統基礎網路在連線開啟時是否能正常運作。
4. 只更換一個參數完整且已知可用的伺服器，再重複測試，區分單一伺服器問題與全域設定問題。

這四組結果可以快速劃定範圍：Direct 正常而 Proxy 異常，重點檢查伺服器與協定參數；Proxy 正常而 Config 異常，重點檢查規則、策略名稱與 DNS；關閉連線正常、Direct 也異常，重點檢查系統 VPN 設定、On Demand 或其他網路延伸功能衝突；所有狀態都異常，則應先修復目前的 Wi-Fi 或行動網路。完成對照後再恢復原本的 Global Routing，避免把臨時測試狀態長期當成正式設定。

確認 App 來源與使用前提

如果無法確認裝置上的 App 來源、購買紀錄或 App 身分，請先前往正版核驗說明，核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。Shadowrocket 是一次買斷的用戶端，但用戶端一次買斷 ≠ 線路方案；後續連線需要使用者已有自己的訂閱或伺服器資訊。本手冊只說明用戶端內的診斷方法，不評價服務來源。

排查期間不要頻繁刪除 Config 或整批覆蓋現有資料。較穩妥的做法是先記住目前選取的伺服器與設定名稱，另外保存重要自訂規則的文字副本，再進行單項調整。若最後需要向自己的服務商回報，至少應提供故障發生時間、網路類型、協定名稱、Connectivity Test 結果，以及是否只有單一伺服器異常；密碼、完整訂閱網址與身分憑證不應出現在一般截圖中。

二、連線開關無法開啟或立即跳回

Home 中的連線開關無法保持開啟，通常發生在系統 VPN 設定尚未授權、現有網路延伸功能狀態異常、On Demand 反覆觸發，或 App 設定無法被系統接受時。這種症狀與伺服器逾時不同：伺服器逾時通常允許開關保持開啟，只是請求無法完成；開關立即跳回則應優先檢查裝置端的連線建立流程，而不是先調整規則。

檢查首次授權與系統狀態

首次開啟連線時，系統會要求允許加入 VPN 設定，並可能要求使用裝置密碼、Touch ID 或 Face ID 確認。若在授權流程中途取消，返回 Home 後再次開啟，讓系統重新顯示確認步驟。授權完成後，可在系統設定的 VPN 相關頁面確認 Shadowrocket 對應的設定是否存在。不同系統的介面入口名稱可能調整，因此只需確認系統中看得到該連線設定，不必依賴某一條固定選單路徑。

如果系統頁面存在多個長期不用的 VPN 設定，先逐一確認目前實際使用的是哪一項。不要在多個連線工具之間連續搶占系統 VPN 狀態；先中斷其他網路延伸功能，再回到 Shadowrocket 測試。系統在網路切換、裝置剛解鎖或恢復資料連線時，可能短暫處於過渡狀態；等待十到二十秒後再操作，通常比快速連續點按開關更容易得到可判斷的結果。

將 On Demand 與手動連線問題分開

On Demand 會根據已設定的網路條件決定何時連線。條件重疊、目前 Wi-Fi 名稱變更，或規則同時包含連線與中斷動作時，可能出現開關剛開啟又被條件重新處理的現象。排查手動開關時，應先在 Settings 中暫時關閉 On Demand，只測試 Home 的手動開關。若手動連線恢復，表示系統授權與基本設定大致可用，下一步應逐條檢查 On Demand 條件，而不是重新建立伺服器。

檢查條件時，從最具體的網路條件開始。若某條件針對特定 Wi-Fi，應核對名稱是否完全一致，包括空格與大小寫；若條件根據網路類型，應確認裝置當時確實處於對應網路。一次只啟用一條條件，鎖定螢幕後重新解鎖，再測試 Wi-Fi 與行動網路之間的切換。只有每條條件都能獨立運作後，才適合重新組合，避免多個條件互相覆蓋。

重新建立系統連線，但不破壞既有資料

確認授權完整、On Demand 已暫時關閉，但開關仍立即跳回時，先正常退出 Shadowrocket，再重新開啟；接著切換一次飛航模式，讓系統重新建立網路介面。若問題只在某個 Wi-Fi 發生，可忽略該網路後重新加入，以排除 DHCP 或區域網路狀態殘留。若 Wi-Fi 與行動網路都相同，再考慮重新建立系統中的 Shadowrocket VPN 設定。操作前應確認自己的伺服器資訊與 Config 已有可靠副本。

重新建立系統連線的目的，只是讓系統重新接受 VPN 設定，不需要刪除訂閱或逐一刪除伺服器。完成後先關閉 On Demand，選擇一個參數明確的伺服器，將 Global Routing 設為 Proxy，只測試一個一般頁面。如果開關能保持開啟，再依「連線後無法上網」章節繼續；如果仍立即跳回，重新啟動裝置後再測試，並確認裝置沒有處於限制修改 VPN 的管理狀態。

辨識裝置管理與網路限制

由組織管理的裝置可能限制加入或修改 VPN 設定，系統通常會在授權時顯示提示。此類限制無法透過變更 Shadowrocket 的協定參數解決，需要由裝置管理方確認允許的網路策略。家庭網路中的路由器限制通常不會讓開關立即跳回，而會表現為連線後伺服器無法到達，因此應根據開關能否穩定保持來區分兩者。

最終驗證應維持簡單條件：目前基礎網路正常、On Demand 關閉、Global Routing 為 Proxy、只選一台伺服器，連線後等待狀態穩定。完成這些步驟後若開關可用，再逐項恢復原有設定，每恢復一項就測試一次。這樣可以準確找出觸發跳回的設定，而不是恢復全部設定後再次面對同一個問題。

三、連線成功但網頁與 App 無法上網

開關保持開啟、系統也顯示 VPN 狀態，但網頁和 App 沒有資料，是最容易混淆的一類故障。原因可能是伺服器不可用、協定參數錯誤、規則將所有請求送入錯誤策略、DNS 無法解析，或區域網路位址被錯誤處理。應先判斷是「所有請求失敗」還是「部分請求失敗」，再決定檢查 Proxy、Config 或 DNS。

先用 Direct 與 Proxy 劃分故障層級

保持 Shadowrocket 開啟，將 Global Routing 設為 Direct。若 Direct 也無法存取一般頁面，表示問題更接近系統網路介面、本機網路或連線設定；此時先切換 Wi-Fi 與行動網路，確認原始網路能否傳輸。如果 Direct 正常，再改為 Proxy。若 Proxy 全部失敗，重點轉向目前的伺服器、連接埠、協定與驗證參數；若 Proxy 正常而 Config 失敗，伺服器本身通常不是首要原因，應檢查規則與策略引用。

測試時應固定目標頁面，不要每次使用不同網站。瀏覽器可能保留快取，某些 App 也會自動重試，因此可準備兩個一般 HTTPS 頁面，每次切換狀態後等待連線穩定再重新整理。若一個頁面正常、另一個失敗，應記錄失敗網域，並在 Data 或連線記錄中查看它最後命中了哪條規則，而不是概括成「網路時好時壞」。

檢查 Config 中的策略名稱與規則順序

Config 會依規則由上而下比對，第一個命中的規則決定處理策略。規則末尾的 PROXY、DIRECT、REJECT 或自訂策略名稱，必須與目前設定中實際存在的策略一致。如果匯入的 Config 引用了不存在的策略群組，請求可能無法依預期處理。尤其在替換設定後，伺服器仍存在並不代表舊設定中的策略名稱仍然有效。

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

上例中，特定網域先交給 PROXY，區域網路位址直接連線，接著處理 GEOIP，最後由 FINAL 收尾。實際設定應依自己的使用目的安排順序。若把 FINAL 放在中間，後續規則就沒有比對機會；若誤將常用網域交給 REJECT，會表現為單一網站立即失敗；若區域網路位址沒有 Direct 規則，印表機、路由器管理頁或其他本機裝置可能在 Shadowrocket 開啟後無法到達。

查看請求是否真正送出

在 Data 中觀察失敗請求時，重點查看網域、連線結果、命中規則與策略，而不只是總流量。完全沒有記錄，可能表示 App 未送出請求、請求由快取直接處理，或系統網路尚未恢復；有網域但解析失敗，應進入 DNS 章節；有目標 IP 但建立連線逾時，應檢查伺服器或目標路徑；立即出現拒絕結果，則檢查 REJECT 與目標網站回應。

某些 App 會維持長時間連線。切換 Global Routing 或伺服器後，舊連線不一定會立即重建，因此測試時應徹底關閉目標 App 後重新開啟，或等待它主動建立新的工作階段。只在瀏覽器中反覆重新整理，不能代表所有 App 的行為。若瀏覽器正常而單一 App 異常，先檢查該 App 是否使用特殊連線方式、是否快取舊 DNS，以及 Config 中是否存在針對其網域或 USER-AGENT 的規則。

處理區域網路與網路切換邊界

從 Wi-Fi 切換到行動網路時，原有連線會經歷網路介面變更。Shadowrocket 通常會重新建立工作階段，但正在傳輸的請求可能會失敗一次。應等待狀態穩定後再測試，不要把切換瞬間的失敗視為持續故障。如果每次切換後都無法恢復，檢查 On Demand 條件是否在新網路上選擇了不同狀態，或 Config 是否對區域網路與行動網路使用不一致的 DNS。

若只有區域網路裝置無法存取，應確認其位址範圍，並使用適當的 IP-CIDR 規則交給 DIRECT。規則範圍不要任意擴大，以免將原本應由其他策略處理的公網位址一併包含。完成修改後重新載入 Config，再透過具體的區域網路 IP 測試。有關規則由上而下比對與 FINAL 的詳細說明，可閱讀自訂規則與優先順序。

四、伺服器顯示逾時或連線測試失敗

伺服器列表中的逾時，通常表示測試請求未能在限定時間內完成，但「逾時」本身不能直接說明伺服器停止回應。網域解析失敗、連接埠無法到達、協定參數不一致、目前網路遺失封包、服務端限制或測試目標回應緩慢，都可能產生相似結果。正確做法是分開判斷「能否解析」、「能否到達連接埠」、「能否完成協定交握」與「實際請求能否傳輸」。

理解 Connectivity Test 的限制

Connectivity Test 用於快速比較目前項目是否能完成指定測試，但測試數值並不等於完整使用體驗。某次結果較佳可能只是當下網路抖動較小；一次逾時也可能只是短暫遺失封包。應在相同網路下間隔測試數次，觀察是否持續逾時，並以實際 HTTPS 頁面複核。不要連續高頻率測試整個列表，這會同時占用本機網路與伺服器連線，反而讓結果更難解讀。

如果只有一個項目持續逾時，而同一訂閱中的其他項目正常，優先檢查該項目的伺服器位址、連接埠與服務端狀態。如果所有項目同時逾時，先測試基礎網路與 DNS，再換用另一種本機網路。所有項目在 Wi-Fi 逾時、行動網路正常，問題更可能位於目前的 Wi-Fi、路由器或其上游路徑；兩種網路都相同，則應核對匯入內容是否完整，以及服務端是否發生一致的變更。

逐項核對協定參數

手動加入伺服器時，SERVER、連接埠、密碼或驗證資訊、協定類型及其附加選項，必須與使用者已有的伺服器資訊一致。Shadowsocks 需要核對加密方式與密碼；VMess、VLESS、Trojan 需注意位址、連接埠、身分資訊以及 TLS、傳輸方式和 Host 等附加欄位；WireGuard 需核對金鑰、位址與路由範圍；Hysteria2 還涉及相應的驗證與傳輸參數。不同協定的欄位不能憑經驗互相套用。

透過 Scan QR Code 或 Import from Cloud JSON 匯入後，也應開啟項目檢查關鍵欄位是否齊全。QR Code 能被辨識，只代表文字格式可解析，不等於其中的伺服器參數仍然有效。若服務商已調整伺服器資訊，應以使用者從自己的服務商取得的最新內容為準。不要在不了解用途時隨意開啟 TLS 選項、更換傳輸方式或改寫 Host，這些變更往往會讓原本接近正確的設定完全不相容。

區分延遲、遺失封包與吞吐量

延遲反映一次往返所需的時間，遺失封包會造成重傳與停頓，吞吐量則同時受伺服器負載、路徑容量、協定開銷與本機網路影響。低延遲項目不一定在持續傳輸時更快，高延遲項目也不一定無法使用。因此選擇時應先排除持續逾時，再以相同工作比較穩定性。詳細方法可參考延遲測試與實際體驗的差異。

如果測試由正常突然變成全部逾時，應回想變化發生前是否更新了訂閱、切換了 Config、變更了 DNS 或更換了網路。恢復到上一個可確認的狀態，再逐項重新套用變更。若確認位址與參數正確，但在不同網路、不同時間仍持續逾時，應將測試時間、協定名稱與去除敏感資訊後的錯誤現象交給自己的服務商確認服務端，而不是繼續修改用戶端中無關的規則。

五、Subscribe 更新失敗或匯入後為空

Subscribe 的作用是從使用者已有的訂閱網址讀取伺服器列表。更新失敗可能發生在網址輸入、HTTPS 存取、DNS、服務端回應、內容格式或本機列表寫入階段。匯入後為空不一定代表請求未成功，也可能是回傳內容不含 Shadowrocket 能辨識的項目，或原有篩選條件讓項目沒有顯示。排查時應保護訂閱網址，因為其中可能包含專屬憑證。

先檢查網址是否完整

在 Subscribe 中開啟對應項目，核對網址開頭、網域、路徑與查詢部分是否完整。複製時最常見的問題是前後混入空格、聊天工具截斷過長網址，或只複製到問號之前。不要將真實網址貼到公開測試網站，也不要在截圖中暴露完整查詢內容。需要與服務商溝通時，可只顯示網域與錯誤提示，並遮蓋路徑中用於識別帳戶的部分。

可先關閉 Shadowrocket 連線，使用目前基礎網路存取訂閱網域，判斷網域是否能建立 HTTPS 連線；這一步不要求公開內容，只用於確認本機網路與網域解析。若關閉連線時可存取、開啟後失敗，檢查 Config 是否對訂閱網域使用錯誤策略。可以在規則較前的位置為該網域指定能正常工作的策略，再重新更新，但不要將未知網域隨意加入大範圍規則。

區分網路失敗與格式失敗

網路失敗通常表現為逾時、無法解析網域或連線中斷；格式失敗則可能很快完成請求，但沒有產生伺服器項目，或出現無法辨識內容的提示。前者應依 DNS 與本機網路方向排查，後者需要確認服務端回傳的是適用於 Shadowrocket 的目前訂閱格式。用戶端能開啟某個 URL，並不代表回傳文字一定包含可匯入的資料。

若同一網址之前可以更新，近期突然變成空白，先不要刪除舊列表。記錄舊項目數量與更新時間，手動更新一次並觀察結果；如果新內容異常，保留舊資料有助於繼續驗證。確認服務端恢復後再更新。若已經覆蓋，重新匯入前應先確認網址仍然有效。訂閱內容由使用者自己的服務商維護，用戶端無法修復服務端回傳的空白文字、錯誤頁面或失效身分資訊。

處理重複、重新命名與篩選

多次加入同一網址可能產生多個 Subscribe 項目，使使用者誤以為更新沒有作用，實際上查看的是另一個列表。應核對訂閱名稱與網址網域，保留需要的項目後再手動更新。若使用備註、排序或篩選，暫時清除篩選條件，確認新項目是否已寫入。名稱變更也可能讓熟悉的項目看似「消失」，此時應依伺服器位址與協定類型核對，而不是只根據顯示名稱判斷。

訂閱更新只負責同步伺服器資訊，不會自動確保目前 Config 中所有策略名稱都與新列表一致。如果更新後伺服器存在，但 Config 引用的自訂策略找不到可用成員，Config 狀態仍可能無法上網。可先用 Proxy 直接選擇一個新項目測試，確認項目本身可用，再處理 Config 的策略關係。這樣能避免將訂閱寫入成功誤判為規則失效，也能避免把規則問題誤判為訂閱問題。

建立穩定的更新順序

建議在基礎網路正常時執行更新：先確認關閉連線可以存取一般頁面，再更新單一 Subscribe；更新完成後查看項目是否變更；選擇一個項目執行 Connectivity Test；最後再啟用原有 Config。自動更新間隔不宜短到頻繁中斷使用，也不應依賴每次連線時同時完成大量請求。若更新只在某一網路失敗，應記錄網路類型，轉到 DNS 章節繼續判斷。

如果錯誤發生在掃描或檔案匯入，Scan QR Code 需要完整清晰的內容，Import from Cloud JSON 則需要符合 App 可辨識的格式。能夠選取檔案不代表檔案內容正確。匯入前保留原始資料，出現錯誤時回到資料來源重新取得有效內容，不要手動猜測缺少的欄位。完整入門流程可參閱使用說明中的匯入步驟。

六、速度慢、影片停頓或連線不穩定

速度問題應拆分為裝置本機網路、伺服器狀態、傳輸路徑、協定特性與目標網站五個層面。單次測速數字無法代表持續使用體驗，某個 App 停頓也不能直接證明伺服器吞吐量不足。有效排查需要使用相同裝置、相同網路、相同時段與相同測試工作，只變更一個變數，並至少重複兩到三次。

先測量基礎網路上限

關閉 Shadowrocket，在目前 Wi-Fi 或行動網路下完成一次基礎測試，並觀察是否存在明顯抖動。若基礎網路本身不穩定，開啟連線後通常只會放大重傳與延遲，不應先調整協定。Wi-Fi 環境還需觀察與路由器的距離、頻段壅塞、同一網路中其他裝置的大流量工作，以及裝置是否正在進行系統同步。切換到行動網路重新測試，可以快速判斷問題是否只屬於目前的 Wi-Fi。

測試下載、網頁開啟與影片播放時，應分別記錄「開始回應需要多久」與「持續傳輸是否穩定」。前者較受 DNS、交握與延遲影響，後者更接近吞吐量與遺失封包。網頁首屏載入慢但後續傳輸正常，可能是解析或交握路徑較長；很快開始但中途反覆停頓，則更應關注遺失封包、伺服器負載與路徑波動。

比較伺服器時保持其他條件一致

選擇兩個使用者已有且參數完整的伺服器，將 Global Routing 暫時設為 Proxy，在同一網路下使用同一項工作測試。不要一邊更換伺服器，一邊變更 DNS 或協定選項。若只有一台伺服器持續較慢，問題更接近該伺服器或其路徑；若所有伺服器都慢，而關閉連線時正常，檢查本機網路對相關協定的傳輸品質、DNS 與裝置狀態；若關閉連線也慢，應先處理基礎網路。

伺服器地區只是影響路徑的因素之一，不能只根據名稱判斷速度。實際路徑可能受網路時段、服務端負載與目標網站接入位置影響。Connectivity Test 數值較低只表示測試往返較快，不保證持續吞吐量更高。應優先選擇多次測試穩定、實際工作連續、錯誤率低的項目，而不是只追求列表中的最小數字。

檢查協定與附加參數是否相符

協定設定錯誤通常不只是速度慢，還會伴隨重新連線、交握失敗或完全無法使用。若連線能運作但不穩定，應先確認參數與服務端一致，再考慮網路特性。不要為了追求速度而隨意更換加密方式、TLS、傳輸方式、UDP 相關選項或 WireGuard 路由範圍。用戶端與服務端不相容時，任何所謂的「最佳化」都沒有可靠基礎。

部分即時 App 依賴 UDP，部分網路對 UDP 的表現可能與 TCP 不同。若網頁正常但即時語音、遊戲或視訊通話異常，應記錄 App 類型與網路類型，並在自己的伺服器資訊允許的範圍內確認 UDP 支援。這項判斷不應透過盲目切換所有選項完成，而應依據協定要求逐項核對。無法確認服務端能力時，應向自己的服務商詢問目前伺服器支援的參數。

處理時段性與切換後的短暫波動

若白天正常、固定時段變慢，應在相同時段比較基礎網路與多台伺服器，而不是跨時段比較。網路壅塞往往具有時間特徵，只有同時記錄關閉連線的結果，才能區分本地接入壅塞與伺服器路徑變化。切換 Wi-Fi、行動網路或伺服器後，舊連線可能繼續存活一段時間，應重新開啟目標 App，讓它建立新的工作階段後再判斷。

完成測試後恢復 Config，並檢查速度問題是否只影響某類網域。若 Proxy 正常而 Config 變慢，可能是該網域被 Direct 處理，或 DNS 選擇了不合適的位址。此時繼續增加伺服器測試沒有意義，應查看規則命中與 DNS 結果。更完整的分層案例可閱讀速度慢的四層定位方法。

七、DNS 解析失敗、網域打不開或結果異常

DNS 會將網域轉換為 IP 位址。DNS 異常常表現為網域打不開、直接輸入 IP 卻可能有回應、部分網域時好時壞，或切換網路後短時間仍使用舊結果。它也可能與規則共同作用：Shadowrocket 需要先知道網域或目標位址，接著再依 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等規則決定策略。解析與分流不是同一層，但兩者會互相影響最終表現。

先判斷是否為解析問題

選擇一個失敗網域和一個正常網域，在相同狀態下分別測試。若 Data 中的失敗請求顯示無法解析、沒有目標 IP 或很快回傳 DNS 相關錯誤，解析問題的可能性較高。若已取得目標 IP，但在連線階段逾時，則應回到伺服器或路徑方向排查。不要只憑瀏覽器顯示「找不到伺服器」就下結論，因為瀏覽器可能用統一提示覆蓋不同的底層錯誤。

比較 Direct、Proxy 與 Config 的結果。Direct 正常、Config 異常，可能是設定中的 DNS 設定或規則造成差異；Proxy 正常、Direct 異常，可能是目前本機網路的 DNS 對目標網域回應異常；三種狀態都失敗，則應檢查網域本身、裝置網路與快取。每次切換後重新開啟瀏覽器分頁，必要時短暫切換網路，促使系統建立新的解析流程。

檢查 Config 中的 DNS 與 Host

.conf 的 General 區段可以包含 DNS 相關設定，Host 區段則可為特定網域指定對映。錯誤的 Host 項目會讓網域一直指向不正確的位址，即使外部 DNS 正常也無法恢復。檢查時先搜尋失敗網域是否出現在 Host 區段，再檢查 General 中的 DNS 設定是否來自可信且目前可達的來源。不要同時加入多個不了解用途的解析選項。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

範例使用 system 作為說明性設定，並為區域網路範例網域指定位址。實際設定應依自己的網路需求決定。Host 對映具有明確的覆蓋作用，位址變更後若未同步修改，會產生穩定但錯誤的結果。排查未知設定時，可先保存副本，再暫時移除與失敗網域相關的 Host 項目重新測試。設定檔各區段結構可參考General、Rule、Host 與 URL Rewrite 說明。

理解網域規則與 IP 規則的先後關係

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 依網域比對，IP-CIDR、IP-CIDR6 與 GEOIP 則依目標位址比對。若網域規則已命中，後續 IP 規則通常不會再決定該請求；若沒有命中網域規則，解析得到的 IP 可能繼續參與 GEOIP 或 IP-CIDR 判斷。規則順序不合理會讓請求進入意外策略，表面看似 DNS 回傳錯誤，實際上是比對結果不符合預期。

排查單一網域時，可暫時在較前位置加入精確的 DOMAIN 或合適的 DOMAIN-SUFFIX 規則，並指定已驗證可用的策略。若問題消失，表示原規則路徑值得繼續檢查；如果仍然失敗，則應查看 DNS 與目標連線。臨時規則驗證完成後應整理回正式設定，避免長期累積大量互相覆蓋的例外項目。

清理快取時維持操作順序

系統、瀏覽器與 App 都可能快取 DNS。變更 DNS 後立即重新整理一次，不一定會產生新的解析。可關閉目標 App、斷開 Shadowrocket、切換一次飛航模式後重新連線，再測試同一網域。不要同時重新啟動路由器、刪除 Config、修改伺服器與清理 App 資料；這些操作疊加後，即使恢復也無法辨識原因。

若只有某個 Wi-Fi 出現解析異常，檢查路由器分配的 DNS、區域網路中的自訂解析，以及是否存在失效的本地域名對映。行動網路正常可作為對照，但不代表 Config 一定正確。如果多個網路對同一網域都回傳異常，檢查 Host、規則與網域本身。記錄失敗網域、命中策略、是否取得 IP 及網路類型，通常足以將問題定位在解析前、解析中或解析後三個階段。

八、耗電異常與 App Store 更新後異常

Shadowrocket 作為網路延伸功能持續處理流量，連線時產生一定耗電屬於正常現象。需要排查的是在相同使用情境下耗電突然明顯增加、裝置持續發熱、背景流量長時間不下降，或從 App Store 更新後原有設定行為發生變化。判斷時應結合系統電池統計、Data 中的流量活動、網路品質與最近的設定變更，而不是只看某一小時的百分比。

區分用戶端處理與 App 流量

系統電池統計可能將經由網路延伸功能處理的活動計入 Shadowrocket，但真正持續產生流量的可能是前景影片、雲端同步、照片上傳或其他背景 App。先在 Data 中觀察連線是否持續有請求，再逐一暫停高流量 App。若停止相關 App 後流量與發熱很快下降，重點應放在流量來源，而不是立即修改協定。

網路訊號不佳會增加重傳與無線電工作時間。行動網路訊號較弱、Wi-Fi 邊緣覆蓋或網路頻繁切換時，裝置可能不斷重新建立連線。應在穩定 Wi-Fi 下使用相同伺服器與 Config 重新測試一段時間。如果穩定網路下恢復正常，表示耗電與目前接入環境關係較大。持續逾時的伺服器也會觸發重試，應先切換到已確認可用的項目。

檢查 On Demand 與高頻率背景行為

On Demand 條件若反覆符合與失效，可能使連線頻繁建立與中斷。查看問題是否集中在離開某個 Wi-Fi、鎖定與解鎖螢幕或網路切換之後。排查時暫時關閉 On Demand，改用手動連線；若耗電與發熱下降，再逐條啟用條件。條件應清楚且互不衝突，不要讓同一網路同時符合連線與中斷邏輯。

Subscribe 的自動更新、Connectivity Test 與大量並行請求也會產生短時間活動。不要設定過於頻繁的更新節奏，也不要在背景連續測試所有伺服器。若 Config 中存在複雜的腳本處理或大量規則，先使用簡化設定重新測試，判斷問題是否與特定處理鏈有關。簡化測試必須保留原設定副本，確認後再逐項恢復。

更新後先驗證設定是否仍完整

Shadowrocket 唯一的取得與更新入口是 App Store。更新完成後若出現異常，先不要刪除所有資料。依序確認目前伺服器仍被選取、Subscribe 項目仍存在、Config 仍是原本使用的項目、Global Routing 沒有被改成測試狀態、On Demand 條件仍符合目前網路。介面位置可能調整，但應以目前 App 內的實際標籤為準。

接著執行一組最小測試：關閉 On Demand，將 Global Routing 設為 Direct，確認基礎網路；改為 Proxy，選擇一台參數明確的伺服器；最後恢復 Config。若 Direct 與 Proxy 正常而 Config 異常，應檢查設定相容性與規則；若 Proxy 異常，重新核對伺服器參數；若開關無法保持，回到第二章檢查系統授權與 VPN 設定。這個順序可以避免將更新後的單項變化誤認為所有資料損壞。

何時需要重新啟動或重新建立設定

更新後系統網路延伸功能狀態未正確收斂時，正常退出 App 並重新啟動裝置可以清除暫時狀態。若重新啟動後仍無法建立連線，再考慮重新建立系統 VPN 設定，但不應先刪除伺服器與訂閱。重新建立後使用最簡單的條件測試，確認成功後再恢復 On Demand。裝置受管理時，也應確認管理策略沒有在同一時間發生變更。

如果耗電問題只能在特定協定、特定伺服器或特定網路重現，應固定這三個條件，比較前後結果。若所有設定在不同網路下都持續異常，可記錄系統電池統計時間段、Data 活動情況與重現步驟，再等待 App Store 後續提供更新說明。本網站不編寫版本號或發布日期，實際變更內容以 App Store 頁面為準。

九、iPad 專屬：分欄、網路切換與已購恢復

iPad 上的 Shadowrocket 與 iPhone 使用相同的核心概念，但橫向分欄、多工、鍵盤操作、Wi-Fi 使用比例與背景狀態，會讓故障表現有所不同。排查時不要只照搬 iPhone 上的點按位置，應依目前橫向或直向版面確認 Home、Config、Settings、Data 與伺服器詳細資料所在區域。系統需求與相容性一律以 App Store 頁面標示為準。

先確認購買與 App 身分

若已使用同一 Apple ID 購買 Shadowrocket，可從 iPad 的 App Store 已購項目中尋找並重新下載。若商店顯示狀態與預期不符，應先核對目前登入的帳戶、商店地區，以及開發者 Shadow Launch Technology Limited 和 App ID 932747118。詳細步驟請見iPad 取得說明與已購恢復說明。

Shadowrocket 是一次買斷的用戶端，但用戶端一次買斷 ≠ 線路方案。iPad 重新下載 App 不會自動產生伺服器資訊；使用者仍需使用自己已有的訂閱或伺服器資訊。若 iPhone 中已有設定，遷移時應使用 App 支援的匯入方式並檢查敏感欄位，不能只依賴介面截圖重新輸入，因為較長的身分資訊與協定附加參數很容易遺漏。

理解橫向分欄造成的「找不到」

橫向使用時，列表與詳細資料可能同時顯示，所選項目的內容會出現在另一欄。使用者點選 Config 或伺服器列表後若認為「沒有開啟」，應觀察右側詳細資料是否已經變更。直向使用時，相同內容可能採用逐層進入的方式，因此返回路徑也不同。切換方向後若版面沒有及時更新，可先等待介面重新排列，再關閉並重新開啟 App，不必因此刪除設定。

外接鍵盤與觸控板不會改變規則邏輯，但可能讓焦點停留在搜尋框或編輯欄位，導致滑動與快捷操作與預期不同。編輯伺服器參數後，應明確完成儲存並返回列表，確認目前項目仍被選取。iPad 螢幕能同時顯示更多欄位，也更容易讓使用者將詳細資料欄中的舊項目誤認為目前項目，因此測試前應回到 Home 核對實際選取的伺服器名稱。

處理 Split View 與背景恢復

在 Split View 或其他多工狀態下，App 視窗尺寸會改變，但網路延伸功能仍由系統管理。縮小視窗不會直接中斷連線，但目標 App 進入背景、網路從 Wi-Fi 切換或系統回收資源時，原有工作階段可能需要重建。排查某個 App 在分欄中無法連網時，先讓兩個 App 分別全螢幕測試，再恢復分欄。若全螢幕正常、分欄異常，應關注目標 App 的背景與工作階段恢復，而不是先修改 Shadowrocket 規則。

鎖定螢幕一段時間後重新開啟 iPad，狀態列可能先顯示舊狀態，稍後才完成網路恢復。應等待 Wi-Fi 圖示與 VPN 狀態穩定後再進行測試。若已啟用 On Demand，觀察它是否依目前 Wi-Fi 條件建立連線；若沒有，暫時關閉 On Demand 並手動開啟，以區分條件判斷與連線本身。頻繁開合保護套造成的鎖定螢幕切換，也可能放大條件設定不合理的問題。

檢查 iPad 常見的 Wi-Fi 情境

iPad 常在固定 Wi-Fi 中長時間使用，因此 DHCP 位址變更、路由器重新啟動、本機 DNS 快取與區域網路裝置存取問題更容易累積。關閉 Shadowrocket 測試基礎網路，再用 Direct 檢查系統連線，最後用 Proxy 檢查伺服器。如果只有印表機、檔案裝置或路由器頁面無法存取，應確認區域網路 IP-CIDR 規則交給 DIRECT，而不是更換遠端伺服器。

在需要網頁登入確認的公共 Wi-Fi 中，應先關閉連線，完成網路本身的登入流程，確認一般頁面可用後再開啟 Shadowrocket。登入頁尚未完成時，伺服器測試通常會全部逾時，容易被誤判為訂閱或協定問題。若從一個 Wi-Fi 移動到另一個同名網路，On Demand 可能仍依名稱處理，但兩個網路的實際環境不同，因此應結合位址與可存取性重新測試。

遷移 Config 後逐層驗證

從其他 Apple 裝置匯入 Config 後，先檢查 [General]、[Rule]、[Host] 與 URL Rewrite 是否符合 iPad 目前的網路。固定區域網路位址、特定 Wi-Fi 的 DNS 或只適用於原網路的 Host 對映，都可能在 iPad 上產生差異。不要一次啟用所有附加處理；先驗證伺服器，再驗證基礎規則，最後恢復 Host 與改寫項目。

完整驗證順序仍然是 Direct、Proxy、Config。iPad 上若瀏覽器正常而分欄中的某個 App 異常，關閉該 App 後重新開啟，讓它建立新的連線；若所有 App 都異常，查看 Data 是否有請求與規則命中；若連線開關跳回，檢查系統授權；若只有網域失敗，檢查 DNS。有關 iPad 的已購重新下載與版面差異，可繼續閱讀iPad 重新下載與橫向分欄說明。

如果依照本手冊仍無法定位，請整理可重現的步驟：裝置類型、網路類型、Global Routing、協定名稱、是否只有單一伺服器受影響、Connectivity Test 結果、規則命中與錯誤發生時間。向自己的服務商回報時只提供去除敏感資訊的內容，不要展示完整訂閱網址、密碼或身分欄位。