Shadowrocket 疑難排解

連線開關無法啟用：先檢查系統授權

開關無法維持啟用時，首先要區分「系統未建立通道」與「通道已建立但無法存取」。前者常見情況是開啟後立即關閉、反覆出現授權提示，或系統設定中的 VPN 狀態始終沒有變化；後者通常可以維持連線，卻無法載入內容。先留在 Home 觀察一次完整操作，不要快速連續切換，以免把正常的建立過程誤認為沒有回應。

確認首次授權與本機設定

首次啟用時，系統可能會要求允許加入 VPN 設定，並透過裝置密碼或系統驗證確認。只有在剛才主動操作 Shadowrocket 時，才繼續這次授權；若取消提示，返回 App 再發起連線即可。App 內開關與系統授權是兩個步驟，匯入伺服器不代表裝置已允許建立通道。完成授權後，再確認系統狀態與 App 狀態是否一致。

前往系統設定查看 VPN 設定，確認是否有對應 Shadowrocket 的項目。系統入口名稱可能因裝置系統而異，請使用設定內的搜尋功能定位，不必拘泥於固定路徑。若已有多個網路設定，先記下名稱與用途，再暫時停止其他會接管裝置流量的連線。不要直接批次刪除，尤其是受工作或學校管理的裝置；部分設定可能會由管理政策自動還原。

確認 Home 中已選取有效伺服器，留意選取標記，而不只是查看清單中是否有項目。開啟該項目，核對 Address、Port 與協定類型是否完整儲存；若剛才編輯後直接離開，請重新開啟確認修改確實保留。欄位空缺或無法解析的設定，可能導致連線在啟動階段失敗。伺服器是否能實際通訊，應留待下一階段驗證，不能只憑開關自動關閉就判定遠端故障。

排除按需連線與系統限制

若手動關閉後又自動開啟，先檢查 On Demand。按需連線會依已設定的條件觸發，與手動操作同時存在時，容易讓人覺得「開關不受控制」。記下目前條件，暫時關閉 On Demand，再手動連線、斷線各測試一次。確認手動狀態穩定後，再逐項恢復自動條件；不要同時修改按需規則與更換伺服器。

若按鈕無法操作，或始終沒有出現授權提示，請檢查裝置是否受組織管理，以及系統是否限制修改 VPN。管理政策造成的限制應由裝置管理員確認，反覆重新安裝 App 通常無法改變政策。個人裝置可先結束正在占用網路的工作，正常重新啟動裝置後再測試一次。重新啟動有助於清除暫時狀態，但無法修正伺服器參數或網路條件。

使用需要網頁登入驗證的 Wi-Fi 時，請先中斷通道並完成網路驗證，再啟動連線。否則系統雖然已連上無線網路，實際外部通訊仍可能被驗證頁面擋下。請用一般網頁確認基本網路已恢復，不要只依據 Wi-Fi 圖示判斷。切換到另一個既有且可用的網路後，若開關能穩定維持，應繼續檢查原網路的連線條件，而不是立刻清除 App 資料。

何時重建 VPN 設定

只有在授權紀錄異常、系統狀態與 App 狀態持續不同步，且上述交叉測試無效時，才考慮重建對應的 VPN 設定。先保留伺服器資料與 Config 備份，停止連線和 On Demand，再刪除確認屬於 Shadowrocket 的系統 VPN 項目，之後返回 App 重新請求授權。刪除系統 VPN 項目與刪除 App 內伺服器是不同操作，請仔細核對確認文字，避免誤刪仍需使用的資料。

重建完成後，以最少變因進行測試：一個已核對的伺服器、手動連線、暫時關閉按需觸發。若仍立即關閉，請保存這次的錯誤提示、重現步驟及系統連線狀態；若開關已能穩定維持但仍無法存取，請前往下一章。不要一開始就「重置網路設定」，這會影響其他網路紀錄，也可能讓原本可供比對的環境消失。

連線後無法上網：分別驗證伺服器與規則

連線狀態只表示裝置已啟動相應的網路通道，不能證明所有要求都已抵達目標。排查時，選一個確定可正常存取的網頁作為對照，再測試實際失敗的目標。記錄是所有 App 都失敗、只有特定網站失敗，還是只有部分資源無法完整載入。瀏覽器顯示的一般錯誤有時涵蓋解析、連線及憑證問題，請保留原始提示，不要直接將其視為伺服器無法使用。

使用 Global Routing 建立對照

先記下目前的 Global Routing，再了解三種模式的用途。Config 依目前設定中的規則選擇策略；Proxy 用於將可接管的要求導向代理路徑進行對照；Direct 用於比對直連路徑。這些選項並非依「效果強弱」排列。測試結束後應恢復原本模式，尤其不要把暫時使用 Proxy 當作規則設定已修復的證據。

若 Direct 可用而 Proxy 失敗，優先檢查預設伺服器與協定參數；若 Proxy 可用而 Config 失敗，重點檢查規則命中結果與策略去向。若三者都失敗，先完全中斷連線並測試基本網路，再查看 DNS 章節。請注意，Direct 狀態仍可能受目前網路處理方式與解析設定影響，因此「切換到 Direct」與「中斷連線」應分別記錄為兩種對照。

依規則順序追查流量去向

在 Config 中確認目前實際啟用的檔案，而不只是開啟名稱相似的檔案查看。規則通常依序比對，前面已命中的項目會影響後續規則是否還有機會生效。檢查目標是否被範圍過廣的 DOMAIN-KEYWORD、網域後綴規則或 IP 規則提前涵蓋，同時確認命中的策略存在，且指向預期伺服器。規則內容正確但策略無法使用，同樣會造成存取失敗。

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

上例僅說明比對與兜底關係，不應直接覆蓋現有檔案。DOMAIN-SUFFIX 適用於範例網域及其子網域；DOMAIN-KEYWORD 涵蓋範圍較廣，修改前應考慮誤匹配；FINAL 負責處理前面未命中的要求。範例網域應依自己的目標調整，PROXY 也應搭配目前的預設伺服器核對。若使用自訂策略名稱，請確認名稱與引用一致，不能把拼字不同當成網路問題。

頁面文字能顯示，但圖片、登入或影片失敗時，不要只檢查網址列中的網域。同一頁面可能從多個網域載入資源，也可能在驗證過程中重新導向。重現一次問題，查看 App 中可用的要求紀錄，比較成功與失敗要求的目標及策略。只新增有明確依據需要調整的規則，不要因單一資源失敗就把範圍過廣的關鍵字規則移到頂端；擴大修改範圍會掩蓋真正原因。

確認 App 與目標服務的問題範圍

若只有一個 App 異常，先用瀏覽器開啟同一服務的網頁入口作為對照；網頁正常不代表 App 內部介面一定正常，但有助於縮小問題範圍。檢查該 App 是否仍保留舊連線；切換策略後，請完全結束再重新開啟，並重新發出要求。既有連線可能繼續使用先前建立的路徑，修改規則後不代表每條舊連線都會立即重新選擇策略。

若失敗表現為登入限制、帳戶提示或內容權限，應將目標服務回傳的說明與網路逾時分開處理。連線成功不會改變服務端的帳戶狀態。恢復原設定後，再依特定網站規則寫法整理需要保留的例外。只有在目標要求穩定導向預期策略，且重新建立連線後仍可重現成功，才能判定本輪規則排查完成。

伺服器逾時：從可連通性檢查到協定驗證

伺服器逾時並非單一原因。地址解析失敗、目標連接埠無法連通、協定欄位不相符、TLS 驗證失敗，最後都可能表現為等待後出錯。先確認 App 使用哪種測試，再觀察實際連線時發生的狀況。某種延遲測試有回應，只能表示該測試涉及的環節獲得回應，不能據此保證驗證、目標要求及持續傳輸都正常。

先核對伺服器資料是否相符

進入 Home 中目前選取的項目，與自己持有的原始資料逐項比較 Type、Address、Port 及驗證欄位。複製地址時容易帶入前後空格、把完整連結誤填至 Address，或把訂閱地址當成單一伺服器地址。連接埠應使用資料指定的數字，不要依協定名稱猜測。若透過掃描匯入，完成後仍應開啟項目複核；掃描成功只代表內容已被辨識。

確認資料仍有效，並確認服務端是否已調整入口或驗證資訊。可以先更新自己已有的訂閱，再比較新舊項目是否有變化；若曾手動儲存專用參數，不要在更新覆蓋後憑記憶補填。將「原始資料的內容」、「App 實際儲存的內容」及「目前實際選取的項目」一併核對，比反覆嘗試多組參數更容易找出不一致之處。

先在目前網路測試，再換到另一個既有且可用的網路進行相同測試。兩個網路都失敗時，優先檢查伺服器狀態與參數；只有某個網路失敗時，再考慮該網路的連接埠、傳輸類型或接入條件。這種對照無法直接判定哪一方故障，但能避免把局部網路條件誤認為設定錯誤。測試期間保持相同伺服器與測試方式，結果才有比較價值。

依協定核對關鍵欄位

對於使用 TLS 的設定，連線地址與憑證名稱可能各有不同用途。Address 決定連線入口，Peer/SNI 參與服務端名稱與憑證相關處理；原始資料若明確提供名稱，應依原樣填入對應欄位，而不是將所有欄位都替換成同一個 IP。裝置日期與時間明顯錯誤，也可能影響憑證有效期判斷。先核對時間與名稱，再依錯誤提示繼續排查。

不要長期啟用 Allow Insecure 來掩蓋憑證錯誤。此選項會改變驗證條件，即使短暫連線成功，也不能證明伺服器設定正確。正確做法是核對服務端提供的網域、憑證名稱與 TLS 要求，再恢復驗證條件。若資料不完整，請向自己的服務提供者確認必要欄位；手冊中的範例不能取代實際連線參數。

透過實際要求完成最後驗證

執行 Connectivity Test 後，再開啟一個已知可用的目標網頁，確認內容是否能完整載入。若測試有結果但網頁仍失敗，請繼續檢查 DNS 與規則；若只有大型要求失敗，則前往速度章節排查傳輸與路徑問題。不要直接比較不同測試的讀數；測試可能採用不同方法、目標與逾時條件，數值差異不一定代表同一連線的效能有所變化。

WireGuard 還需注意 Allowed IPs 與本機地址範圍；它們不是用來填寫目標網站的一般規則清單。握手狀態與網頁存取仍應分開檢查，路由範圍錯誤可能造成部分目標無法連線。若要逐項了解，請參閱WireGuard 設定欄位說明，但不要直接照抄不屬於自己的地址與金鑰。

排查紀錄至少應保留協定、測試網路、錯誤階段，以及是否所有伺服器都失敗。若只有某個項目失敗，而其他既有項目可用，可暫時使用已驗證的設定作為對照，並請自己的服務提供者單獨核對失敗項目。分享紀錄時，請隱藏驗證資料及完整伺服器地址；保留欄位名稱與錯誤類別通常已足以說明問題，無須公開整份連線資料。

訂閱失敗：區分要求、內容與匯入結果

Subscribe 更新包含多個環節：App 讀取地址、透過網路發出要求、取得回應、解析內容，再將項目寫入本機。失敗可能發生在任何一步。先記錄原始提示與發生時機，不要一看到失敗就刪除現有群組。原本已儲存的伺服器可能仍可使用；刪除群組會失去比對資料，也不一定能解決上游回傳錯誤。

確認連結完整且來源相符

從自己的服務提供者重新複製訂閱地址，避免經多次轉傳取得遭截斷的文字。檢查是否混入換行、空格或句末標點，尤其確認查詢參數中的字元是否完整。連結中的驗證參數屬於敏感資訊，不應放入公開截圖、線上轉換頁面或留言。若只需確認欄位結構，請使用範例地址代替真實地址，不要為了排查問題而擴大憑證的傳播範圍。

確認取得的是訂閱內容地址，而不是帳戶管理頁面、付款紀錄頁面，或必須先登入的網頁入口。瀏覽器能開啟某個頁面，不代表它回傳了 App 可解析的伺服器資料。若回應實際上是登入提示、錯誤說明或維護頁面，App 通常無法將其匯入為伺服器清單。此時應回到自己的資料來源核對地址類型，而不是不斷修改協定欄位。

首次匯入與日常更新也要分開判斷。首次失敗時，重點檢查地址、回應格式與網路；過去成功但現在失敗時，還要確認訂閱是否已更換、驗證是否失效，以及服務端是否調整內容。不要只憑本機群組名稱判斷新舊地址相同；群組名稱可能不變，但實際儲存的連結已不同。記錄時請先遮蔽完整地址。

建立可重複的更新測試

先在目前網路手動更新一次，等結果明確後再進行下一步。連續點擊可能造成多個要求重疊，也可能觸發服務端的頻率限制。若提示暫時無法發出要求，請保留原項目，稍後再單獨測試一次。切換網路前，記下目前是否已連線及使用哪種 Global Routing；否則成功可能只是更新要求採用的路徑改變，不能證明連結內容已修復。

若既有連線可能影響訂閱要求，可在基本網路可用的前提下中斷連線後再試；也可以透過一條已驗證可用的連線進行對照。實際要求路徑也取決於 App 內相關設定，請以可觀察紀錄為準，不要假設所有更新都會使用相同路徑。尤其要避免形成循環依賴：唯一的伺服器已失效，卻又必須透過它才能取得更新內容。

要求成功但沒有項目時，請檢查回應是否包含有效伺服器，以及 App 是否支援該內容格式。要求成功但只出現部分項目時，請比較缺少項目的協定與欄位，不要立刻覆蓋所有原有資料。若能從自己的資料來源取得單一伺服器資訊，可先手動新增一項並驗證連線，以區分「伺服器本身無法使用」與「批次內容未正確解析」。

更新後核對選取項目與本機修改

訂閱更新完成後，重新檢查 Home 中的預設伺服器。原先選取的項目若遭替換、重新命名或移除，目前的選取項目不一定仍對應先前的連線入口。開啟更新後的項目查看關鍵欄位，再執行 Connectivity Test 並發出實際要求。清單數量看起來正常，只能表示已有內容匯入，不能證明驗證有效、伺服器可連通，或目前規則會選取這些項目。

區分訂閱中的伺服器資料與 Config 中的規則檔案。更新 Subscribe 不一定能修正 Config 的規則順序；重新載入 Config 也無法讓失效訂閱恢復。若曾手動修改訂閱項目，更新可能會讓這些修改重新對應至上游內容。因此，若要長期保留自訂設定，應先確認其儲存位置與更新行為，再決定如何維護，而不是每次失敗後憑記憶重新填寫。

復原時盡量採用小範圍驗證：先保留現有群組，再驗證新地址的內容與其中一個伺服器，確認無誤後再整理重複項目。刪除前請檢查是否有規則或策略依賴相應名稱。匯入入口的基本操作可參閱入門指南；購買與既有資料的差異可查看常見問題。本頁僅說明如何處理使用者已有的資料，不涉及任何訂閱來源推薦。

速度慢與頻繁卡頓：依發生階段定位

先說明慢在哪裡：點擊後長時間沒有反應、首頁出現後圖片載入緩慢、播放期間中斷，還是大型內容傳輸到某個階段便停住。不同狀況對應不同檢查方向。延遲測試時間短，不代表持續傳輸速度一定快；單次頁面載入緩慢，也可能只是服務端回應較慢。先以固定目標重複測試，再判斷是否所有要求都受到普遍影響。

分開檢查解析、建立連線與傳輸

第一次造訪較慢、緊接著再次開啟卻變快，可能與 DNS 快取、連線重用或目標服務快取等因素有關，不能據此單獨判斷代理速度。選擇兩個不同服務的一般網頁，分別記錄首次與再次開啟的表現。保持相同網路與伺服器，並註明每輪之間是否重新連線。對照條件越明確，就越容易判斷等待發生在建立連線之前，還是內容開始傳輸之後。

若頁面很快顯示標題，但圖片或媒體仍持續等待，請檢查相關資源是否採用不同策略。同一網頁的主網域與資源網域可能使用不同路徑，不能只替主網域新增規則，就認定所有內容都會透過代理。先查看失敗資源的要求去向，再調整最小範圍的規則。確認路徑一致後，才繼續比較伺服器與目前網路的持續傳輸表現。

同時暫停照片同步、大型檔案上傳及其他持續占用網路的工作。上傳頻寬用盡時，一般網頁也可能回應遲緩；此時反覆更換伺服器無法消除本機網路競爭。先以單一裝置、單一工作觀察，再逐項恢復其他工作。測試時不要同時執行多種效能測試，彼此會占用頻寬，結果反而難以判讀。

檢查網路切換與傳輸條件

Wi-Fi 訊號強，不代表外部連線穩定。保持裝置位置不變，先觀察目前網路，再與另一個既有網路比較。若只在特定位置或某個無線網路出現卡頓，請檢查該網路的連線品質、驗證狀態與其他裝置的負載。移動時在 Wi-Fi 與行動網路間反覆切換，也可能使既有連線中斷並重新建立；請分別記錄靜止測試與移動測試。

只有部分協定在特定網路上表現異常時，請核對它們所需的傳輸條件。涉及 UDP 的協定，應確認目前網路實際支援情況；另一種測試有回應，不代表所有傳輸方式都可用。對照應使用自己已有且參數完整的設定，不要為了測試而猜測連接埠、驗證資料或傳輸方式。記錄「同網路、不同協定」時，也要註明它們是否實際使用不同伺服器。

小型要求正常、大型要求卻反覆停住時，可進一步檢查路徑與 MTU 相關問題，但應先確認地址、規則、DNS 與驗證都正常。MTU 不是通用的提速開關；設定過小可能增加負擔，過大也可能在部分路徑上造成分片或封包處理問題。只有在使用的協定與設定明確支援該項目時，才先記錄原值，再依資料建議進行單一變因測試，不要同時調整多個傳輸欄位。

透過有限測試取得可執行結論

比較伺服器時，固定網路、目標、要求類型及大致測試時段。若不同伺服器連線至不同地區或不同服務入口，表現便無法完全相比。目的不是找出看似最小的讀數，而是確認某項既有設定能否穩定完成實際要求。短時間內不斷切換會失去連線重用條件，也更難判斷持續卡頓是否為原本的問題。

如果只有一個目標很慢，而其他目標在相同條件下正常，先檢查目標服務本身及其資源路徑；如果所有目標都慢，再回頭檢查本機網路與所選伺服器。既有服務可能有自身狀態、用量或同時連線數限制，應依自己的服務資料確認，不要只憑用戶端介面推斷。App 的用戶端買斷與服務端傳輸條件是不同事項，購買狀態正常不代表遠端連線路徑始終不變。

測試完成後，請恢復暫時使用的模式、測試規則與傳輸參數，只保留有明確證據支持的修改。有效紀錄應能說明「什麼條件下變慢、哪種對照下恢復、改動了哪一項」。若只記下某次測試結果，卻沒有目前網路與目標資訊，後續便難以重複驗證。若尚未確認首次連線，請先閱讀首次連線驗證說明，不要在基本狀態未知時調校效能。

DNS 異常：先確認解析結果與要求路徑

DNS 會將網域名稱解析為後續連線所需的地址。網域存取失敗可能與解析有關，但憑證錯誤、連線遭拒或目標回應異常，也可能發生在解析成功之後。先查看錯誤與紀錄是否出現解析失敗，再決定是否修改 DNS。不要因某個 IP 有回應，就認定網域解析一定有誤：直接存取 IP 可能缺少目標主機名稱，也可能遇到不同憑證或完全不同的服務。

檢查基本網路與設定來源

先在中斷連線後測試一般網域，再於目前設定下測試相同目標。若基本網路本身無法完成解析，請檢查 Wi-Fi 驗證、網路接入狀態及系統中既有的 DNS 設定。若基本網路正常，啟用後才失敗，則重點檢查目前 Config 與 App 中的解析設定。記錄哪些設定來自設定檔、哪些是後來手動加入，避免只修改一個入口，卻仍受另一處設定影響。

確認所填解析地址的格式符合所選方式。一般伺服器地址與加密解析端點不能任意互換；設定若要求完整端點，只填網域可能缺少必要路徑；反過來，將完整網址填入只接受地址的欄位也會失敗。請依目前介面說明與自己的設定資料填寫，不要從不同範例各取一段拼成新的地址。

加密解析同樣需要建立網路連線；端點使用網域時，也涉及如何先找到該端點的地址。若解析要求依賴代理，而代理伺服器地址又必須透過同一條尚未可用的解析路徑取得，便可能形成啟動依賴。排查時應釐清「先解析哪個地址、要求透過哪條路徑傳送、該路徑是否已可用」，不要只增加更多解析服務地址；清單變長不代表依賴關係已獲解決。

了解網域規則與地址規則的關係

網域規則依目標名稱判斷，地址規則依 IP 範圍判斷；涉及地址判斷時，可能需要先取得解析結果。檢查規則時，應同時觀察要求所帶資訊、解析結果與最終策略。不要以為只要將 GEOIP 放在檔案某處，就能取代所有網域規則。規則先後順序仍然重要，過早命中的項目可能讓後續規則無法處理同一項要求。

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

此片段只展示網域、地理地址規則與兜底規則的順序，並非適用於所有網路的完整設定。GEOIP 判斷取決於使用的資料及實際解析地址，不能用來判斷網站內容或帳戶歸屬。修改前請先保存原始檔案，並核對 PROXY 使用的伺服器。若只有一個網域需要例外，優先採用範圍明確的規則，不要因此改變所有要求的兜底方向。

同一網域可能回傳多個地址，也可能同時回傳 IPv4 與 IPv6 結果。若只有部分網路或部分目標失敗，請確認目前網路是否真的能連通相應的地址家族，並查看失敗連線使用了哪個地址。不要把關閉 IPv6 當成固定解法；只能將其作為有紀錄的暫時對照，測試結束後再依實際網路支援情況決定是否保留原設定。

清除快取後驗證新的要求

修改解析設定後，舊快取與已建立的連線仍可能影響測試。優先使用 App 目前提供的清除快取功能；若介面沒有相應入口，可停止連線後重新建立，並完全結束再重新開啟目標 App。不要為了清除單一網域的狀態就清除所有 App 資料。每次測試都應重新發出失敗的要求，不能只查看仍停留在畫面上的舊錯誤頁面。

網頁部分資源載入失敗時，請分別觀察主網域、資源網域與驗證網域。它們可能使用不同解析結果與規則，單一網域恢復不代表整個頁面路徑已正常。若 App 自行使用其他解析方式，相關流量表現也可能不同於一般系統要求；應依可觀察紀錄定位，不能保證只修改一項 DNS 設定就會改變所有 App 的解析行為。

本章的結束條件是：目標網域能取得可用結果，後續連線使用預期路徑，且重新連線後仍然成功。若解析成功但交握失敗，請回到協定章節；若只有 Config 失敗，請回到規則章節。保存最後採用的解析方式與修改原因，方便日後更換網路時判斷問題來自環境變化，還是自己的設定再次引入依賴問題。

耗電與更新後異常：先恢復可比較的基準

排查耗電與更新問題都需要可比較的前後條件。先記錄異常開始前有哪些變更：App 更新、系統更新、訂閱更新、Config 修改、網路變化，或新增自動連線條件。同一天發生多項變更，不代表其中某一項就是原因。先保留目前狀態與備份，不要立刻刪除 App；否則可能遺失本機資料，也會失去可供比較的原始條件。

區分背景傳輸與連線重試

查看系統電池用量統計中的對應時段，同時記錄螢幕使用、媒體播放、檔案同步與網路切換情況。VPN App 涉及裝置網路處理，統計結果不能簡單理解為所有流量都是由它主動發起。若其他 App 持續上傳或下載，網路處理也會持續進行。比較前先暫停大量流量工作，在相近的螢幕使用與網路條件下觀察，不要直接比較完全不同的使用情境。

反覆逾時與自動重新連線也可能增加網路活動。查看是否只有某個伺服器失效，或裝置在訊號微弱的區域不斷切換網路。先改用自己已有且已驗證可用的設定，再觀察重試是否減少。若連線穩定後耗電狀況恢復，應繼續檢查失敗項目，而不是保留失效伺服器，再用其他開關掩蓋問題。記錄重試與網路變化的時間關聯，比只記下剩餘電量更有幫助。

暫時關閉 On Demand，測試手動連線與手動中斷能否穩定維持。自動條件觸發過於頻繁時，裝置可能在連線、中斷與重新嘗試之間反覆切換。排查完成後再逐項恢復條件，不要一次全部開啟。若啟用了持續診斷紀錄或頻繁手動測試，也應在取得必要資訊後停止；診斷操作本身會增加活動量，不要一邊持續製造負載，一邊評估待機表現。

更新後先核對保留的設定

App 更新後，先確認 Home 中的選取項目、Global Routing、目前 Config 與 On Demand 條件，再重新建立連線。清單中有項目，不代表預設選取項目保持不變；檔案名稱相同，也不代表啟用狀態相同。依更新前的紀錄恢復基準，使用一個已核對的伺服器與一個一般目標完成驗證。若此時可正常使用，再逐項恢復自訂規則及其他設定，避免直接將所有異常歸因於更新。

若同一時間也更新了訂閱，請核對伺服器內容是否改變；若系統也有更新，重新確認 VPN 授權與其他網路設定的狀態。時間接近只能提供線索，不能取代交叉測試。有些異常只是既有連線尚未重新建立，正常中斷、重新連線並重新開啟目標 App 即可驗證；若裝置系統狀態仍持續不同步，請依開關章節處理，而不是立刻重建所有設定。

更新只能透過 App Store 進行。確認 App 時，請核對開發者 Shadow Launch Technology Limited、官方圖示及 App ID 932747118；系統需求以 App Store 頁面標示為準。若需要重新安裝，請先閱讀已購項目復原說明；購買紀錄用於復原 App 的取得資格，不代表本機伺服器、規則檔案與自訂參數已有完整備份。

備份、復原與異常紀錄

備份時，請分別確認 Config、伺服器資料及其他需要保留的設定；不能只匯出一個規則檔案，就認為所有內容都已保存。開啟備份確認內容可讀，並確認自己知道每個檔案的用途與復原入口。含有驗證資料的檔案應存放在受控位置，不要放進公開分享目錄。使用 iCloud 時，請確認同步確實完成，不要只因開關已開啟就刪除原裝置上的內容。

確實需要重新安裝時，先完成備份與購買帳戶核對，再依 App Store 的購買與裝置適用性說明復原。首次復原只匯入最基本可用資料，驗證連線後再逐步還原其他設定；若還原某個檔案後再次出現異常，該檔案及其依賴項目就是下一步的排查重點。遷移順序可參閱設定備份與換機復原。

若異常仍可穩定重現，請整理操作順序、目前網路、失敗階段、是否只影響一種協定，以及哪些交叉測試已成功。提交前隱藏訂閱連結、驗證資料及個人要求內容。耗電紀錄應說明實際使用負載；更新問題則應說明哪些設定也曾變更。恢復正常後，請關閉暫時診斷功能並保留已驗證的備份，讓下次環境變動時有可還原的起點。

iPad 專項：拆分帳戶、網路與設定差異

iPhone 正常而 iPad 異常時，不要直接歸因於裝置型號。兩台裝置可能使用不同網路、購買帳戶、預設伺服器、Config 或解析設定。先確認要比較的是取得資格、App 開啟、建立連線，還是實際存取。每次只比較一個環節，以正常運作的裝置作為參照；但未備份前，不要覆蓋另一台裝置的專用設定。

先確認取得與授權狀態

iPad 的取得入口同樣是 App Store。若先前已購買，請先確認目前用於商店購買的 Apple ID 是否對應原購買紀錄，再查看已購項目的狀態。裝置登入的 iCloud 帳戶與商店購買帳戶可能不是同一個，應以實際購買紀錄為準。系統需求、購買適用性與家人共享條件，請以 App Store 頁面標示為準，不要只因另一台裝置可以安裝就推定相同。

成功取得 App 後，繼續檢查 iPad 本身的 VPN 授權。另一台裝置已授權，不代表這台裝置也已允許加入設定。首次連線時，請留意系統提示並完成裝置驗證；受管理的 iPad 還要確認組織政策是否允許相應網路設定。開關無法維持時，依第一章處理；無法以復原購買取代系統授權，也不應將授權問題誤認為訂閱格式問題。

App 介面可能會隨視窗大小、螢幕方向與系統顯示方式調整。查看 Home、Config 或 Settings 時，先確認實際所在頁面與目前選取項目，不要機械式對照另一台裝置上的按鈕位置。編輯後返回清單，再重新開啟確認儲存結果；使用分割畫面時尤其要確認操作確實送出，而不是仍停留在尚未確認的編輯內容中。

建立兩台裝置的最小化對照

先讓兩台裝置使用同一個可用 Wi-Fi，核對相同的既有伺服器、Global Routing 與目標網頁。不要一台使用行動網路、另一台使用無線網路後，就直接比較連線結果。即使網路名稱相同，也要分別確認是否需要網頁驗證。若 iPad 在中斷連線後基本網路仍異常，先修復網路接入，再繼續排查 App。

若 iPad 使用個人熱點，還需確認熱點來源裝置目前的網路與連線狀態，並以一般網頁驗證 iPad 的基本存取。熱點提供的是網路接入條件，不代表 iPad 會沿用來源裝置的所有規則與連線設定。請以 iPad 上實際建立的連線與要求紀錄為準，不要依來源裝置的狀態圖示判斷 iPad 流量必定採用哪條路徑。

逐項比較 Type、Address、Port、驗證欄位與 TLS 相關欄位，接著比較目前 Config 與 DNS。同步完成與連線成功是不同問題：檔案出現在兩台裝置上，不代表兩端實際啟用了相同檔案。若伺服器名稱相同但內容不同，應以欄位核對為準；若內容相同但表現不同，則繼續比較系統網路設定、地址家族的可連通性與目前接入條件。

檢查背景運作、休眠與喚醒後的連線

若只在鎖定螢幕或喚醒後發生異常，請記錄喚醒前後的 Wi-Fi 狀態、是否切換網路，以及 On Demand 是否觸發。先在固定網路上以手動連線重現，再加入鎖定螢幕與喚醒操作。不要因前景 App 介面沒有持續顯示狀態變化，就認定通道已停止；應一併判斷實際要求與系統狀態。反過來說，系統仍顯示已連線，也不代表休眠前的每一條遠端連線仍然有效。

若喚醒後第一次要求失敗，重新連線後便恢復，請檢查是否為舊連線未及時重建，或目前網路已變更。先完全重新開啟目標 App，再中斷並重新建立連線，分別記錄哪一步讓問題恢復。只有手動流程穩定後，才調整 On Demand 條件。不要把持續自動重新連線當成長期替代方案，否則可能掩蓋訊號微弱、驗證逾期或伺服器持續失效等問題。

遷移設定後，重新執行 Connectivity Test 並實際驗證網頁，再測試自己常用的 App。確認穩定後，保留這台 iPad 已驗證的備份，不必強求所有裝置的設定完全相同；不同接入網路可能需要有依據的調整。需要重新確認取得入口時，請前往iPad 取得說明；需要從頭建立連線時，返回入門指南依主要步驟操作。