Shadowrocket
故障排除指南

先區分無法開啟與開啟後自動關閉

開關無法維持在開啟狀態時，請先確認系統是否允許建立 VPN 設定，不要立刻修改伺服器密碼。請在 Home 選取現有伺服器，確認目前不是停留在編輯表單，再嘗試連線。首次發起連線時，裝置可能會顯示新增 VPN 設定的系統確認畫面；確認來源是目前使用的 Shadowrocket 後，再依系統提示完成授權。若先前關閉了提示視窗，請返回 App 重新發起連線，觀察是否再次出現確認畫面。

請將現象分成三類記錄：點按後完全沒有反應、出現系統確認但未完成，以及開關短暫開啟後自動關閉。第一類還要確認 App 是否能正常回應其他操作；第二類應檢查裝置授權；第三類則須查看連線失敗時 App 顯示的提示。不要只記下「無法開啟」，因為這三種現象分別涉及介面回應、系統權限與建立連線的過程，後續處理順序也不同。

若介面暫時沒有反應，可先等目前的匯入或測試作業完成，再返回 Home 重試。正常退出並重新開啟 App，可以排除一次性的介面停滯，但不代表伺服器問題已修復。反覆點按開關會混淆多次連線過程，讓錯誤提示難以對應到特定操作；完整保留一次嘗試的結果，比連續開關更有助於診斷。

檢查系統設定與 On Demand

前往裝置的 Settings，在 VPN 設定管理位置確認是否有 Shadowrocket 對應的設定，並查看是否有其他網路通道正在連線。管理入口可能因系統介面版本而異，可使用 Settings 的搜尋功能尋找。先中斷其他使用中的通道，再返回 App 手動測試一次；不要直接刪除不熟悉的設定，尤其是由學校、公司或裝置管理政策部署的項目。

如果關閉開關後又自動開啟，或切換網路時狀態反覆變化，請檢查 On Demand。它可能依照已設定的條件再次要求連線，這與一般手動開關故障不同。先記下現有條件，暫時關閉 On Demand，只測試手動連線是否穩定。手動連線正常後，再逐一恢復按需條件，確認是哪個網路條件觸發連線或中斷。

受管理的裝置可能受到系統政策限制，無法新增或修改 VPN 設定。若授權選項無法操作，或系統明確提示設定受到限制，請向裝置管理者確認允許的設定範圍，不要反覆重新安裝 App。App 內的參數無法覆蓋裝置管理政策；確認系統允許建立連線後，檢查伺服器位址、協定與規則才有意義。

保留資料後再進行復原

開關短暫開啟後又關閉時，先確認目前的伺服器資料是否完整：位址和連接埠是否空白、協定類型是否正確、匯入後是否仍指向已失效的項目。請依服務商提供的資訊逐項核對，不要只憑名稱判斷設定內容。若錯誤提示涉及解析、驗證或憑證，請前往相應章節；此時系統授權可能已完成，不必重複處理 VPN 設定。

需要重建系統 VPN 設定前，先儲存必要的設定檔與伺服器資料，並確認仍可向你的服務商取得訂閱。移除系統 VPN 設定與刪除 App 是兩種不同操作，影響範圍也不同；尚未備份前，不要同時執行。重建後，先使用已核對的伺服器手動連線，暫時不要恢復複雜規則與 On Demand，以便確認基本連線是否已恢復。

最後記下具體結果，例如「已完成系統確認、其他通道已中斷，手動連線仍會自動關閉」。若重新啟動裝置後問題仍可重現，可依據 App 內顯示的錯誤資訊繼續排查。購買或 App 來源相關問題，請另行參閱App Store 正版核對說明，不要將取得 App 的問題與連線參數問題混為一談；系統需求以 App Store 頁面標示為準。

先確認基本網路，再比較不同模式

連線已建立但無法存取時，先暫時中斷 Shadowrocket，使用同一部裝置與同一個網路，瀏覽平常能正常開啟的頁面。若中斷後仍無法存取，應優先檢查 Wi-Fi、行動數據、路由器或網路登入驗證。公共網路可能要求先完成登入頁面；若尚未取得基本網路存取能力，調整代理規則通常無法解決問題。完成驗證後再嘗試建立連線。

基本網路正常後，固定同一個目標頁面與同一台伺服器，依序比較 Global Routing 的 Config、Proxy、Direct。這三種模式分別對應設定、代理與直連。每次切換後都重新發出測試請求，不要只觀察已開啟的頁面；某些 App 會沿用舊連線，未必會立即採用新的路由決策。

對照測試的結果需要解讀，不能直接將某個模式當成永久解決方案。Direct 正常但 Proxy 失敗，表示直連路徑可用，仍需檢查伺服器路徑；Proxy 正常但 Config 失敗，則應優先檢查規則命中、策略指向與 DNS。所有模式都失敗時，請回頭檢查目標本身、裝置網路權限與解析結果，避免將不同層面的故障歸為同一個原因。

依影響範圍檢查規則

若只有部分頁面或 App 無法使用，先記錄一個成功的目標與一個失敗的目標。查看失敗請求實際使用的網域，以及是否採用預期策略。一個頁面可能同時向多個網域發出請求；主頁面能開啟，但圖片或登入失敗時，通常還需檢查相關資源請求。不要為了修復單一頁面，就把整份設定換成涵蓋範圍過廣的代理或直連規則。

Config 中的規則通常依序比對；較廣泛的規則若排在前面，可能會遮蔽後續的精確規則。請檢查自訂規則的位置、策略名稱與最後的 FINAL。也要區分直接拒絕請求的 REJECT 與連線失敗：前者是規則決策，後者則是決策完成後存取路徑未能成功。若 App 內的記錄明確顯示命中拒絕策略，請先確認該規則是否符合原本的用途。

以下片段僅說明比對順序，並非可用來取代現有設定的完整檔案。範例先處理網域後綴，再處理指定地區的位址，最後為未命中的請求設定策略。範例網域僅供說明語法，實際排查時請使用已確認的目標；變更 FINAL 會影響大量未命中請求，未記下原始值前不應隨意修改。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

驗證新請求與實際復原範圍

切換模式後，先結束失敗頁面的舊請求，再重新開啟目標。可在瀏覽器新增分頁測試；其他 App 則退出相關頁面後重新進入。若只有快取內容能顯示，一重新整理就失敗，不能算是網路已恢復。驗證時分別觀察頁面主要內容、圖片資源，以及一項需要網路的實際操作，避免將本機快取或既有工作階段誤認為已能完整存取。

若瀏覽器正常、只有單一 App 失敗，還要檢查該 App 的行動數據權限、是否要求固定存取地區，以及是否依賴獨立連線或帳戶狀態。App 端回傳的存取限制不等於通道故障。不要持續切換伺服器，以免觸發更多登入驗證；先保留錯誤文字，確認問題發生於連線階段，還是已收到伺服器回應後。

恢復後，將 Global Routing 調回原本需要的模式，再測試先前失敗的目標。若只有 Proxy 暫時可用、Config 仍失敗，應繼續修正规則，不要把暫時的對照結果當成徹底解決。第一次設定時若不熟悉，可回看Global Routing 教學；零散提示與購買相關問題可參閱疑難解答。

將測試失敗拆解為可檢查的階段

Connectivity Test 顯示失敗，只能表示這次測試未如預期完成，不能直接斷定伺服器永久無法使用。先確認測試對象是目前選取的伺服器，並記錄使用的測試方式。不同方式檢查的層面不同：連接埠可連通，不代表協定驗證成功；驗證完成，也不代表特定目標頁面一定能存取。應將測試結果與實際請求一併判讀。

先核對位址與連接埠，確認位址欄沒有混入協定前綴、空格、換行或非主機名稱的路徑。不要把訂閱網址當成伺服器位址，也不要將網頁管理入口直接填入 Add Server。若位址使用網域名稱，也應檢查本機能否解析該網域；解析失敗發生在連線伺服器之前，應先處理 DNS，而不是反覆修改驗證欄位。

接著在相同設定下切換一次基本網路，例如從 Wi-Fi 改用行動數據。若只在其中一種網路逾時，排查方向應偏向本機網路、路由路徑或網路對所用傳輸方式的限制。若兩種網路都失敗，再向服務商確認伺服器狀態、連接埠與參數是否有變更。每次對照都維持伺服器與目標不變，網路差異才能成為有意義的證據。

依協定核對參數，避免混用欄位

Shadowsocks 應核對加密方式與密碼；VMess 與 VLESS 應核對識別碼及伺服器要求的傳輸設定；Trojan 則應特別核對密碼與 TLS 相關欄位。不同協定的欄位並不相同，不能只因兩個項目使用同一個位址，就複製所有選項。匯入成功只表示文字格式可解析，不代表匯入內容與伺服器目前的設定一致。

啟用 TLS 的連線也涉及伺服器名稱、憑證有效性與裝置時間。SNI 應依照伺服器提供的要求設定，不要隨意填入一個能開啟的網域。若出現憑證錯誤，先確認裝置日期與時間正確，再核對網域、SNI 與伺服器憑證。不應將關閉憑證驗證當成一般修復方式，這會掩蓋名稱或憑證設定錯誤，也會削弱連線身分驗證。

若伺服器使用 WebSocket 等傳輸方式，還需確認路徑、Host 與 TLS 是否相互符合。路徑可能區分大小寫，也可能要求保留開頭的斜線；不要將參數說明中的註解一併貼入表單。若有任何欄位不確定，請回頭核對服務商提供的原始資料，避免連續試用多個猜測值，讓問題變成無法重現的組合。

區分持續故障與間歇性逾時

若只在某些時段逾時，請記錄發生時間、目前網路、伺服器與測試目標，不要只保留一張失敗畫面。短暫網路壅塞、網路切換與伺服器負載變化，都可能影響單次測試。少量、間隔進行對照即可，不要持續高頻測試；大量並行請求會增加干擾，反而可能讓間歇性問題看起來一直存在。

若測試已完成但實際頁面仍失敗，可改用一個已知能存取的小型頁面，區分「伺服器連線」與「透過伺服器存取目標」兩個階段。目標端限制、解析差異與規則指向都可能導致後一階段失敗。相反地，測試目標本身無法使用時，也可能出現 App 實際存取正常但測試失敗的情況，因此不能只憑單一測試就刪除伺服器。

向服務商回報時，請說明協定、錯誤類別、網路對照與重現步驟，不要公開密碼、識別碼或完整訂閱連結。Trojan 欄位的含義可進一步參閱Trojan 參數逐項說明。若參數已核對、遠端仍無法連通，請等待伺服器端確認，不要修改無關的本機規則，以免擴大故障範圍。

區分取得失敗、解析失敗與項目無法使用

Subscribe 更新失敗時，先確認問題發生在哪個階段：無法取得遠端內容、已取得內容但無法解析，或更新完成後伺服器無法連線。這三種情況不能用同一種方式處理。訂閱更新的作用是將遠端資訊匯入 App，並不保證遠端每台伺服器目前都能連線；若伺服器逾時，應先保留訂閱更新結果，再轉到上一章單獨檢查。

訂閱連結請向你的服務商取得。複製時保留完整網址與查詢參數，特別留意長網址是否被聊天介面換行、截斷，或前後混入空格。不要刪除看起來像隨機字元的部分，它們可能用於身分驗證。也不要將服務商的帳戶頁面、說明頁面或設定展示頁面當成訂閱網址；瀏覽器能顯示文字，不代表內容就是 App 可辨識的資料。

先記下現有訂閱群組與可用項目，再手動更新一次並查看提示。若仍有可用伺服器，請保留這些資料，不要為了重試而刪除整個群組。部分更新方式可能會調整項目名稱、順序或內容，連線前應重新確認目前選取的項目。舊名稱消失與訂閱完全失效是兩種不同情況，請先檢查項目是否已替換或重新分類。

檢查存取路徑與回傳內容

若在取得階段失敗，請確認目前的基本網路能否連線至訂閱所在的服務。必要時可比較中斷連線與使用現有可用連線時的更新結果，但每次只變更存取路徑。更新所用的請求未必與一般頁面請求完全相同，請以 App 內可見的結果為準。若服務商要求特定存取條件，請先核對其說明，不要任意修改訂閱網址的網域或協定來繞過錯誤。

收到驗證失敗或拒絕存取的提示時，請檢查訂閱是否已重設、帳戶授權是否變更，以及連結是否仍為最新有效網址。反覆使用已失效的驗證連結，通常無法恢復授權。若回應提示請求過於頻繁，請停止連續更新，並依服務商的要求稍後再試。App 的購買狀態與遠端訂閱授權彼此獨立，重新購買用戶端不會自動恢復失效的訂閱。

若已取得內容但解析失敗，請確認服務商提供的格式與匯入入口相符。回傳內容有時可能其實是登入頁面、錯誤說明或維護頁面，而非伺服器資料；頁面有文字不代表格式正確。不要將整個網頁複製到設定檔，也不要手動刪改編碼內容中的符號。請服務商確認回傳內容類型，並提供適用於目前入口的資料。

檢查更新後的選取項目與狀態保留

更新成功後，返回 Home 檢查目前選取的伺服器是否仍存在、所屬群組是否正確，並對其中一個項目執行連線測試。若所有新項目都失敗，應優先核對協定與服務商狀態；若只有部分項目失敗，請保留其名稱與錯誤資訊並回報。不要將群組中的項目數量變化直接解讀為 App 故障，遠端內容調整也會改變本機結果。

手動修改訂閱項目前，先確認下次更新是否會覆蓋變更。若要驗證單一欄位，可先儲存原始值，必要時建立獨立的手動測試項目，再與訂閱項目對照。不要在多個群組中同時複製並修改同一台伺服器，否則之後很難判斷目前連線的是原始項目還是暫存副本。驗證完畢後，請清除暫存測試內容，並保留清楚的名稱。

若長時間沒有更新，先確認 App 是否具備執行更新所需的網路條件，再檢查更新設定。背景作業會受系統排程影響，不要因為未在預期時間更新，就直接判定訂閱失效。若手動更新成功、背景更新卻未如預期發生，應優先檢查裝置使用環境與系統限制，不必重新產生所有伺服器參數。

最後應整理出完整紀錄：連結來源已確認、是否成功取得與解析，以及更新後哪些項目能夠連線。若仍無法判斷，請將已移除驗證資訊的錯誤文字與發生階段提供給服務商，不要在公開討論區貼出完整連結。訂閱問題的簡短問答可參閱疑難解答；初次匯入的操作順序則請依照使用教學完成。

先確認變慢的是哪一種操作

「速度慢」應先細分為首次開啟慢、持續傳輸慢、影片緩衝、偶爾停頓，或切換網路後中斷。首次開啟主要涉及解析、建立連線與交握；持續傳輸則還會受到頻寬、壅塞與目標服務影響，兩者不能只用單一延遲數字解釋。請選擇一項容易重複的操作，分別記錄開始階段與持續階段的狀況，再決定要檢查哪個層面。

先觀察同一部裝置上的基本網路，確認沒有同時進行大型檔案同步、系統更新或多個 App 持續傳輸。Data 中的流量變化可協助辨認活動，但流量大不代表某台伺服器速度快，流量小也不代表連線失敗。若其他 App 正大量使用網路，請等它們完成後再進行對照，避免將裝置整體負載誤認為代理效能問題。

固定測試目標、伺服器與 Global Routing 模式，在相近時段進行少量重複測試。不要一次更換網路、伺服器與協定，再把改善歸因於其中某個選項。可先比較同一台伺服器在兩種網路上的表現，再固定網路比較你現有的兩台伺服器；每次只改變一個變數，結果才能指出具體瓶頸。

依本機網路、伺服器與目標分層比較

若只在某個 Wi-Fi 環境中變慢，先檢查訊號強度、裝置與基地台的距離、路由器負載及網路登入狀態。移至訊號較穩定的位置再試，比直接調整協定參數更容易判斷原因。以行動數據對照時，也要留意訊號與網路類型變化；移動過程中的單次測試不能代表固定位置的正常狀況。

在同一個網路中，若只有一台伺服器速度慢、其他現有伺服器正常，檢查重點應放在伺服器負載及通往該伺服器的路徑。若多台伺服器都慢，但 Direct 對照正常，也不能立刻認定是 App 本身有問題，因為它們可能共用類似路徑或遠端出口。應進一步比較目標、時段與協定，確認變化是否一致，再向服務商提供可重現的資訊。

若只有某個網站或服務變慢，先確認使用同一台伺服器存取其他目標時的狀況。目標的內容傳遞、帳戶限制、服務狀態或存取地區都可能影響結果。測速檔案的傳輸量不能代表所有網站的載入體驗；單次下載快速，也不能證明短連線的交握同樣順暢。測試應以實際發生問題的操作為主，而不是只追求較好看的數字。

檢查傳輸特性，避免盲目調整參數

部分協定仰賴 UDP，某些網路對這類流量的連通性與持續傳輸表現可能不同。使用 Hysteria2 或 WireGuard 時，應先確認網路與伺服器支援相關傳輸，再檢查協定設定。不能因為另一條 TCP 連線可用，就認定 UDP 路徑完全正常。協定選擇應符合伺服器設定，不要只改用戶端類型卻保留原有參數。

MTU、並行連線與保持連線等設定，不宜作為第一個嘗試步驟。例如特定路徑上的分片或封包遺失，可能呈現小型請求正常、大量傳輸停頓的情況，但類似現象也可能來自壅塞或目標限制。缺乏對照證據時任意降低 MTU，可能影響其他 App 的表現。確實需要測試時，請記下原始值，一次只調整一項，沒有改善就還原。

若切換網路後才開始停頓，先等系統完成新網路連線，再重新發出請求。有些 App 會保留舊連線，切換後需要自行重新連線；這不代表所有流量都持續無法使用。比較瀏覽器的新請求與原 App 的舊工作階段，有助於判斷問題出在基本通道，還是 App 工作階段的恢復。不要同時反覆開關連線及切換網路，以免干擾重新建立連線的過程。

驗證改善時，至少重新執行先前變慢的完整操作，並觀察是否能持續穩定。若只是某一次開啟較快，不要立刻保留大量未經驗證的參數調整。記錄是哪個變數帶來改善，以及恢復原值後速度是否再次變慢。更詳細的分層測試可參閱速度慢的逐層定位筆記；統計方式則可參閱Data 頁面流量統計說明。

確認問題是否真的發生在解析階段

DNS 問題常見症狀包括伺服器網域無法解析、部分目標顯示找不到位址，或切換網路後同一網域的存取結果不同。先區分無法解析伺服器位址與無法解析目標網域：前者會阻止代理連線建立；後者可能發生在連線已建立之後。記下具體網域與錯誤階段，才能判斷應檢查本機網路、App 中的 DNS 設定，還是伺服器路徑。

不要以瀏覽器直接存取目標 IP 取代所有解析檢查。許多服務需要正確的網域才能完成 TLS 與虛擬主機比對，透過 IP 存取失敗並不能證明網路不通。同樣地，某個 IP 能建立連線，也不代表該網域對應的頁面一定可用。更可靠的方式是查看 App 內可見的解析或請求記錄，確認網域是否取得結果，以及接著採用了哪項策略。

檢查時先使用已知應能正常存取的目標，並維持目前網路不變。若只有單一網域失敗，請確認拼字、網域本身狀態，以及服務商提供的伺服器位址；若大量無關網域同時失敗，才優先檢查解析服務或前往解析服務的路徑。不要把個別伺服器回傳錯誤、帳戶驗證失敗或頁面空白都稱為 DNS 故障。

檢查解析路徑、快取與位址類型

查看目前 Config 中與 DNS 相關的設定，同時檢查裝置是否有額外的 DNS 設定或網路管理政策。先列出可能參與解析的設定，再決定要測試哪一項。更換解析服務前，應確認所選位址使用的協定及網路路徑可用；若填入無法存取的解析服務，原本只影響單一目標的問題可能擴大成所有網域都無法解析。

若使用加密解析，還需檢查伺服器名稱、憑證與存取路徑。建立加密解析連線本身也可能需要先解析伺服器名稱；依賴關係設定錯誤，會造成啟動階段失敗。因此，不要只因為標示為「加密」，就認為解析鏈路設定正確。請依照所用設定的說明核對，避免將一般 DNS 位址、加密解析位址與網頁網址視為可互換的內容。

修改後還要考慮快取與舊連線。系統、App 與目標 App 都可能保留先前的結果，立即重新整理一次未必會觸發新的解析。先結束相關請求，重新建立連線並再次測試，必要時重新啟動目標 App。不要連續切換多個解析服務卻不記錄結果，否則快取尚未更新時觀察到的現象，可能被錯誤歸因於剛修改的設定。

也要留意 IPv4 與 IPv6 路徑是否一致。某些網路能取得兩種位址，但其中一種路徑不穩定；另一些服務則依賴特定位址類型。不要為了修復單一目標，就直接關閉所有 IPv6 相關功能。先比較不同網路、具體網域與失敗的位址類型，確認問題範圍後，再依目前設定支援的選項做最小幅度調整。

一併檢查解析結果與規則順序

網域規則與位址規則檢查的對象不同。DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 與 IP-CIDR6 則比對位址範圍。若請求先命中較廣泛的規則，後面的精確項目可能不會參與決策。解析結果改變也可能影響位址規則的比對，因此「DNS 有解析結果」與「規則命中正確」仍是兩項獨立檢查。

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

以上規則片段用於說明不同的比對對象，並非完整設定。範例中的完整網域項目已被相同策略的後綴項目涵蓋，保留兩行是為了對照語法；實際設定應避免不必要的重複。私有位址規則只處理符合條件的位址範圍，不代表所有區域網路探索或裝置通訊只靠這一行就能解決；區域網路問題還應參考最後一章檢查。

恢復後，分別確認伺服器網域能夠解析、失敗目標能夠解析、新請求命中預期策略，而且實際頁面可用。若其中一項仍異常，請沿著相應層面繼續排查，不要不斷新增解析位址。向服務商回報時，可提供已遮蔽敏感資料的網域、錯誤類別與網路對照；不要公開包含帳戶識別資訊的專用位址或完整設定檔。

先檢查是否有持續傳輸或反覆重新連線

判斷耗電異常時，應一併參考裝置 Settings 中的電池使用記錄、螢幕使用情況與當時的網路活動。VPN 連線會轉送其他 App 的網路流量，系統顯示的用量歸屬不一定能直接反映單一 App 主動產生的所有活動。不要只憑一個百分比認定設定有問題；先記錄異常發生的時段，確認是否同時播放影片、同步、上傳或長時間傳輸資料。

將排查分為靜置與使用兩種狀態。靜置對照時，維持相同網路、相近電量與相近觀察時間，避免同時充電、下載或移動位置。使用對照時，執行相同操作並記錄持續時間。短時間內顯示的電量會受到溫度與系統估算影響，不適合用來得出精確耗電結論；應優先尋找持續傳輸、反覆連線等可直接觀察的線索。

連線不穩定可能造成持續重試，增加網路活動。查看是否在 Wi-Fi 與行動數據之間反覆切換、是否位於訊號較弱的位置，以及 On Demand 是否在相近條件之間反覆觸發。先穩定基本網路，暫時關閉按需條件，再手動連線對照一次。若停止重新連線後耗電情況改善，請逐一恢復條件，而不是一次關閉所有功能。

減少診斷干擾，不犧牲正常驗證

排查時可能會暫時開啟詳細記錄，或頻繁執行 Connectivity Test。取得必要證據後，應恢復原本的記錄層級並停止重複測試，避免將診斷活動本身誤認為日常負載。若 Data 中的流量持續增加，請一併檢查其他 App 當下的活動；雲端同步、媒體上傳與背景傳輸可能在螢幕關閉後持續進行，不能只因裝置看似閒置就認定沒有流量。

裝置明顯發燙時，先停止高負載測試，等溫度穩定後再比較連線狀況。溫度變化可能影響系統效能與無線通訊，邊充電邊持續傳輸也會增加干擾。不要為了收集更多資料而持續進行壓力測試。日常排查的目標是重現實際問題並確認是否改善，而不是測出裝置或網路能承受的極限。

電池問題也需要檢查裝置整體狀況。若中斷連線後仍有相同的耗電異常，應繼續查看系統電池記錄與其他 App 活動，而不是持續調整代理參數。若只有特定網路與特定伺服器的組合會造成異常，應優先調查連線重試與傳輸穩定性。將觀察範圍縮小至可重現的組合，才能避免把裝置電池狀態誤認為單一 App 的設定問題。

更新後從最簡可用設定開始復原

更新後出現異常，先區分 App 更新、系統更新、訂閱更新與 Config 內容更新。它們可能在相近時間發生，但影響的項目不同。記錄最後一次正常使用時的網路與設定，確認目前的伺服器、Global Routing 與設定檔是否仍是原本選取的項目。訂閱重新命名、策略指向變更或系統權限狀態改變，都可能讓問題看起來像是 App 更新直接造成。

先正常重新開啟 App，必要時重新啟動裝置，接著使用一台已核對的伺服器與簡單的存取目標進行測試。暫時停用自行新增的複雜規則、按需條件或其他擴充設定，但保留原始內容。每恢復一項就測試一次；若基本連線正常，加入某項設定後才失敗，就能將調查範圍限縮至該項，不必刪除所有 App 資料。

檢查 Config 中失效的策略參照、已移除的伺服器名稱與格式錯誤。舊設定可以儲存，不代表其中引用的項目仍然存在。若出現明確的解析提示，請依提示定位相應行，並保留修改前後的差異。不要從不同來源拼湊大量參數來修復單一錯誤；設定之間的相依關係，可能使表面正確的片段在組合後失效。

只有在資料已備份且確實有需要時，才考慮移除系統設定或重新安裝 App。App 的取得與更新一律透過 App Store；如需恢復購買或確認裝置相容性，請參閱已購項目恢復說明，系統需求以 App Store 頁面標示為準。恢復後先驗證基本連線，再逐步匯回資料；完整的重現步驟比未經驗證的「更新後就壞了」更有助於定位。

比較裝置前，先確認網路與資料一致

同一份訂閱在 iPhone 正常、iPad 失敗時，先確認兩部裝置確實使用相同網路。iPhone 可能已切換至行動數據，而 iPad 仍連著需要登入驗證或訊號較弱的 Wi-Fi。查看實際網路狀態，再核對所選伺服器、Global Routing、Config 與訂閱更新時間。只比較伺服器顯示名稱並不足夠，同名項目中的參數也可能不同。

在兩部裝置上使用相同目標、同一台伺服器與相同模式，各自發出新的存取請求。不要拿一部裝置已載入快取的頁面，與另一部裝置剛開始存取的情況比較。若條件一致後仍只有 iPad 失敗，請檢查該裝置的 VPN 授權、日期與時間、裝置管理政策及額外網路設定；伺服器在另一部裝置上可用，並不能排除本機權限或設定差異。

App 購買與設定移轉也應分開處理。同一帳戶下的已購項目、裝置相容性與系統需求，以 App Store 頁面標示為準；已安裝 App 不代表伺服器資料會自動完整出現。請先依照iPad 取得說明確認 App，再向你的服務商取得訂閱並完成匯入，之後才比較連線狀況，避免將缺少設定誤認為購買項目恢復失敗。

檢查多工、休眠與網路恢復

iPad 使用分割畫面或多工功能時，App 可能顯示在較窄的區域，部分設定入口需要展開或捲動畫面才能看到。視窗變窄不會改變參數的含義，但操作時容易漏看下方欄位。核對 Add Server 時請逐項捲動檢查，儲存後再返回項目查看。不要只憑編輯頁面上半部正確，就認定所有參數都已完整儲存。

闔上保護套、長時間閒置或切換網路後出現異常時，應分別驗證系統網路恢復、VPN 連線狀態與目標 App 工作階段。先確認裝置能正常存取基本網路，再檢查 Shadowrocket 的連線，最後重新開啟目標頁面。若新請求正常，但原本的影片、檔案傳輸或工作階段仍停滯，問題可能是目標 App 未能及時恢復舊連線，不必立刻重建所有伺服器設定。

iPad 上的 On Demand 也應依實際網路條件逐一驗證。裝置可能長時間連接同一個 Wi-Fi，但期間曾進入休眠、登入驗證過期或切換基地台。先以手動連線確認基本功能正常，再恢復按需設定，分別測試喚醒、離開網路及重新連回網路後的狀況。不要將一次喚醒成功視為已涵蓋所有網路條件，請保留實際使用情境的驗證紀錄。

區分區域網路位址、探索機制與代理路徑

無法存取家中儲存裝置、印表機或其他區域網路服務時，先中斷連線進行對照，並確認裝置確實位於可互相存取的同一個網路。訪客 Wi-Fi、基地台隔離與不同網段，本身就可能阻止裝置彼此通訊。若中斷後仍無法存取，應先處理路由器或裝置權限；只有基本區域網路路徑正常後，才繼續檢查 Config 的路由規則。

區域網路探索與直接存取位址是兩種不同操作。已知位址可直接存取，但自動探索失敗時，可能涉及探索封包、網路隔離或系統的本機網路權限；單靠新增網域規則無法解決。若相關 App 需要本機網路權限，請在裝置 Settings 中檢查授權狀態。不要將所有探索問題都歸因於 DNS，也不要任意為整個網路新增範圍過大的策略。

若確實需要讓特定私有位址範圍直接存取，先確認實際網段，再使用相應的 IP-CIDR 或 IP-CIDR6 規則，並將其放在可能遮蔽此規則的廣泛規則之前。不要直接將範例網段當成家中網路的實際設定。對於同時有網域與位址的服務，也應核對網域解析結果，避免網域指向遠端位址，而你只修改了本機私有位址規則。

測試時分別驗證已知位址存取、網域存取與裝置探索，並記錄三項結果。若只有探索失敗，應繼續調查探索機制；若網域失敗但位址正常，請回到 DNS 章節；若所有區域網路目標都失敗，則檢查網路隔離與規則順序。如此拆分問題，可避免為了修復單一入口而改變所有其他存取路徑，進而引發新問題。

最後整理出可重現的紀錄：裝置型號類別、目前網路、連線模式、目標類型、錯誤文字與對照結果。傳送前請遮住訂閱網址、驗證欄位與帳戶資訊。基本連線恢復後，再返回使用教學完成日常驗證；需要快速核對常見結論時，請參閱疑難解答。保留這份紀錄，下次遇到類似症狀時即可從已驗證的層面繼續排查，不必重新調整所有設定。