Shadowrocket
故障排除手冊

01 / VPN CONFIGURATION

連線開關無法開啟或立即關閉

先區分授權失敗與連線失敗

Home 中的連線開關無法維持開啟時，請先確認系統是否允許建立 VPN 設定。首次連線時，系統可能會要求確認加入 VPN 設定，並以裝置密碼或系統認證完成授權。這個程序只允許 App 建立網路通道，不代表遠端伺服器已通過驗證。若取消提示視窗，請返回 App 再次啟動連線並完成確認，不要反覆修改伺服器密碼。先記下開關是在確認前關閉，還是開啟片刻後才關閉；這兩種情況的排查方向不同。

開啟系統 Settings，在 VPN 相關設定中查看是否有 Shadowrocket 的設定。不同系統版本的設定入口可能不同，可使用設定搜尋功能尋找。確認目前是否有其他 VPN 連線正在執行；一般個人 VPN 通常無法同時維持多條連線。先結束其他連線，再返回 Shadowrocket 測試。若不清楚用途，請勿刪除所有網路設定；工作或學校裝置上的受管理項目可能負責必要的存取控管。

依可還原的順序處理殘留狀態

1. 停止目前的連線，等系統 VPN 狀態解除後，再重新開啟 Shadowrocket。
2. 暫時關閉 On Demand，避免系統自動連線與手動測試交錯進行。
3. 確認已選取既有伺服器，儲存設定後只測試連線一次。
4. 若仍立即退出，請重新啟動裝置，接著在相同網路下再次測試並記錄結果。

若系統中已有設定，但 App 持續無法建立連線，請先確認設定已完整備份，再移除明確屬於 Shadowrocket 的 VPN 設定，並由 App 重新提出授權要求。移除的是系統網路授權紀錄，並非重設遠端帳號，也無法修復服務到期或參數錯誤。操作前請確認能重新取得既有設定；不要一開始就重新安裝 App，否則本機伺服器、Config 與診斷紀錄可能一併遺失。

檢查系統限制與觸發條件

受管理裝置可能禁止新增 VPN、修改網路設定或執行特定網路延伸功能。若系統按鈕無法編輯、提示裝置由組織管理，或設定會自動還原，請聯絡裝置管理人員確認政策。裝置密碼、螢幕使用時間限制與管理政策屬於不同層級的問題，遠端伺服器資訊無法改變這些限制。個人裝置也請先確認系統儲存空間是否不足，以及其他 App 是否同樣異常，再判斷是否為網路延伸功能啟動失敗。

On Demand 會依設定條件觸發連線，因此「關閉後又自動開啟」不一定是開關故障。先停用 On Demand，確認手動連線能否穩定維持，再逐項恢復觸發條件。若只在切換 Wi-Fi、鎖定螢幕或離開某個網路後發生異常，請記錄具體操作，不要只寫「偶爾中斷」。固定觸發條件後，才能重複驗證同一組設定，並分辨是系統重建連線，還是 App 意外停止。

若仍無法開啟，請整理裝置型號、系統要求核對結果、授權提示內容、裝置是否受管理，以及重新啟動後重現問題的步驟。App 取得方式與系統要求請參閱正版核驗說明；系統要求以 App Store 頁面標示為準。不要反覆刪除設定來掩蓋最初的錯誤提示；原始提示通常比最後一次嘗試更有助於判斷問題。

02 / REQUEST PATH

已連線，但網頁無法開啟

先建立關閉連線時的對照

先停止 Shadowrocket，在目前的 Wi-Fi 或行動網路上開啟平時可正常瀏覽的頁面。若關閉連線後仍無法使用，請先檢查網路本身：Wi-Fi 是否需要網頁認證、路由器能否連網、行動數據是否允許使用，以及裝置所在位置的訊號是否不穩。公共 Wi-Fi 的認證頁面可能需要在停止連線時完成；通過認證後再繼續測試。底層網路尚未連通時，繼續修改規則通常只會增加變數。

若關閉連線時正常、開啟後失敗，請進一步確認故障範圍。分別測試兩個不同目標，判斷是所有請求、單一 App，還是特定網域失敗。使用相同頁面與操作進行對照，避免其中一次開啟的是快取內容，另一次卻需要重新發出網路請求。瀏覽器顯示舊頁面不代表連線正常；請重新載入需要連網的內容，同時查看 App 的請求紀錄是否出現相應存取。

透過 Global Routing 判斷問題所在

Global Routing 決定整體請求如何進入後續處理。Config 模式會依目前規則進行比對；Proxy 模式可用來檢查所選伺服器的連線路徑；Direct 模式則用來觀察不經代理策略的存取情況。這三種模式適合短時間對照，不是通用的修復按鈕。測試結束後，請恢復原本需要的模式，並確認目前啟用的 Config 是預期檔案；不能只確認檔案列表中有沒有某份設定。

若 Proxy 模式正常、Config 模式失敗，請優先查看失敗請求命中了哪條規則，以及最後採用的策略。範圍較廣的 DOMAIN-KEYWORD、過早出現的 REJECT，或不符合預期的 DIRECT，都可能改變請求路徑。規則通常依序判斷，請先找出實際命中的一行，再檢查它前面是否有條件更寬的規則。不要只在設定檔末尾新增一條正確規則，因為請求可能早已符合前面的規則。

以最精簡的規則理解判定，不覆蓋原設定

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

此處的 example.com 僅用來說明語法，並非連線測試服務。DOMAIN-SUFFIX 會比對指定網域及其子網域；GEOIP 依 IP 位址的地理歸屬判斷；FINAL 則為尚未符合其他規則的請求提供預設策略。若要測試，請複製目前的 Config，另存為測試檔並保留原檔。不要把這三行視為適用所有情境的完整設定，也不要連同原有 DNS、策略及其他必要設定一起刪除。

若 Proxy 與 Config 模式都失敗，但 Direct 模式正常，請改查伺服器參數、遠端可用性，以及代理路徑中的 DNS。若只有某個 App 失敗，請確認它是否使用獨立連線方式、是否保留舊連線，以及系統是否允許它使用行動數據。必要時完全結束該 App 後重新開啟，確保測試的是新連線。重新啟動目標 App 與重建 VPN 連線應分開進行，才能判斷是哪個步驟改變了結果。

若發現命中 REJECT，先確認網域用途，再暫時停用單一疑似規則並重新測試；不要一次移除所有封鎖規則。一個頁面可能依賴多個網域，其中一項請求遭拒，就可能造成部分內容空白或無法登入。相關說明請參閱REJECT 規則寫法說明。若所有模式都失敗，而底層網路正常，請保留失敗請求的時間與錯誤類別，接著查看下一章。

03 / SERVER PARAMETERS

節點逾時與協定交握失敗

先依層次解讀測試結果

Connectivity Test 或伺服器延遲測試，只能說明特定測試方式當時是否能在目前網路中完成，不代表瀏覽器中的所有請求都正常。測試失敗可能與伺服器位址解析、連接埠連線、協定交握或測試目標有關；測試成功也不保證遠端能存取所有目標。先記下使用的測試方式，再開啟實際失敗的頁面驗證。比較結果時請使用相同方法，不要直接比較不同測試產生的數值。

核對伺服器位址時，留意複製過程是否帶入空格、換行或標點。位址欄位應與既有服務資訊一致，連接埠也必須對應目前使用的協定入口。網域能解析不代表連接埠可連線；連接埠可建立連線也不代表認證成功。若既有資訊包含多個連接埠或不同傳輸方式，請依對應關係逐項填寫，不要將某個入口的位址與另一個入口的 TLS 或傳輸參數混在一起。

檢查協定欄位之間的相依關係

TLS 中用於憑證驗證的伺服器名稱，與實際建立連線的位址可能用途不同；請以既有設定提供的資訊為準。傳輸層的 Host、路徑或其他欄位，也不應只憑名稱猜測。若服務端設定有所調整，舊訂閱中的參數可能仍可匯入，卻已無法完成交握。請先更新自己的訂閱並確認更新成功，再比較更新前後的欄位差異，避免在多個相似項目中選錯舊設定。

檢查系統日期、時間與時區，並優先使用系統自動設定。時間明顯不準可能影響憑證驗證或有時間限制的認證。遇到憑證錯誤時，不應將關閉驗證當成固定解法；請核對伺服器名稱、裝置時間與遠端憑證狀態。略過驗證會掩蓋真正原因，也讓後續無法判斷是修正了參數，還是單純跳過錯誤。恢復正確的驗證方式並再次測試，才算完成排查。

透過不同網路對照定位路徑問題

保持伺服器與參數不變，分別透過 Wi-Fi 與行動網路測試。若只有一種網路失敗，請檢查該網路是否有限制、UDP 處理方式是否不同，或位址族是否有差異。這只能將問題範圍縮小至網路路徑，不能直接判定是某個特定裝置故障。若只有一台伺服器失敗，而同一訂閱中其他既有伺服器正常，可優先向原服務提供者確認該入口狀態，不必先重建所有客戶端設定。

使用 WireGuard 時，需同時確認 Peer 能正常通訊，以及 AllowedIPs 是否涵蓋希望透過通道連線的目標範圍。交握與路由是兩個不同問題；前者正常，不代表後者設定正確。私鑰與遠端公鑰不可互換，分享診斷資訊時也不可洩露私鑰。欄位用途請參閱WireGuard 參數說明；不要靠隨意更換金鑰排查路徑問題。

完成檢查後，請將故障描述整理為「在某網路下，某協定交握逾時；另一網路的結果如何」，並附上已核對的欄位類別，不要提交完整認證資訊。若需要更明確的檢查順序，請參閱節點逾時檢查清單。短時間內反覆重試通常無法修復遠端狀態，反而會讓不同時間的結果更難比較；取得可重現的樣本後，再決定下一步。

04 / SUBSCRIPTION UPDATE

Subscribe 匯入失敗或更新異常

區分取得失敗與內容解析失敗

訂閱更新至少包含取得網址、向伺服器發出請求、接收回應及解析內容等階段。「更新失敗」只是結果，首先要判斷停在哪個階段。未收到回應與收到內容卻無法辨識，處理方式不同。前者要檢查網路、網址與認證；後者則要確認回應內容是否為 Shadowrocket 可辨識的訂閱資料。請先保留原有可用項目，不要每次更新失敗就刪除整個訂閱群組，否則會失去可供比較的舊設定。

從自己的服務資訊重新複製完整訂閱網址，檢查前後空格、換行、遺漏的查詢字串，以及誤加的中文標點。訂閱網址通常包含存取憑證，不可放進公開截圖、聊天紀錄或診斷附件。若必須展示請求結構，只保留網域與欄位名稱，並移除欄位值。不要為了測試而反覆將完整網址貼到不同網頁；若網址被他人取得，可能造成帳號或服務使用風險。

依回應狀況選擇檢查方向

若出現認證失敗、權限不足或存取遭拒，請優先前往原服務提供者的帳號頁面，核對訂閱狀態、網址是否已重設，以及是否設有存取限制。重新購買客戶端無法恢復遠端認證。客戶端一次買斷 ≠ 線路方案；App 購買紀錄與使用者既有服務的憑證，是兩組獨立資訊。購買相關資訊請參閱價格與買斷說明；App Store 的已購狀態不代表訂閱仍然有效。

若回應內容是登入頁面、維護通知或其他網頁，即使請求本身已完成，也不代表訂閱更新成功。客戶端需要可辨識的訂閱資料，而非瀏覽器能顯示的任意內容。遇到重新導向時，也要確認最終回應仍屬於預期的服務流程。不要手動刪除網址中的認證部分來解決解析錯誤；這通常只會讓請求變成未登入狀態，使問題更加複雜。

若目前連線本身無法使用，訂閱請求也可能被送往失敗的代理路徑。在保留舊項目的情況下，先比較停止連線與使用既有可用連線時的更新結果，並留意目前 Config 如何判定訂閱網域。不要假設所有更新請求都走相同路徑，也不要因為瀏覽器能開啟服務頁面，就認定 App 的訂閱請求一定成功；兩者的連線工作階段、認證及回應內容可能不同。

更新成功後仍須核對實際變更

1. 確認操作回報成功，並查看訂閱群組中實際出現的伺服器，不要只看提示文字。
2. 確認目前選取的項目是否仍指向舊入口；必要時重新選取已有的新項目。
3. 核對名稱相似的伺服器屬於哪個訂閱群組，避免測試到另一份殘留設定。
4. 連線測試通過後再整理舊紀錄，並保留可供追溯的設定副本。

更新後項目數量減少，不一定代表匯入時遺失資料。原服務可能調整了項目、帳號權限或訂閱內容，也可能因篩選條件而隱藏部分紀錄。請比較實際回應與群組結果，先確認原始內容是否包含預期項目。名稱變更不代表伺服器參數一定改變；反過來說，名稱相同也無法證明位址、連接埠與認證資訊仍一致。排查時應檢查欄位，不要只比較列表外觀。

手動新增的伺服器與由訂閱管理的伺服器應分開看待。直接修改訂閱項目，下一次更新時可能會被遠端內容覆蓋；若要暫時驗證參數，請先保留原始值並記錄修改原因。不要長期依賴每次更新後都重複修改欄位；若遠端持續提供錯誤參數，請向原服務提供者確認。客戶端中的暫時變更只能作為驗證依據，無法修復訂閱來源本身。

若不清楚匯入步驟，請返回入門指南核對新增既有訂閱的流程；若是混淆帳號與購買概念，可參閱常見問題。先確認問題發生在哪個階段，再調整設定，會比同時更換網址、規則與伺服器更容易得到明確結果。

05 / PERFORMANCE BASELINE

速度緩慢、載入停頓與網路切換

將速度問題拆分為不同狀況

「慢」可能是首次開啟頁面等待較久、下載持續速度偏低、影片間歇停頓，或切換網路後很久才恢復。這些狀況分別可能與 DNS、建立連線、持續傳輸速度及重建連線工作階段有關，不能只用單一延遲數值解釋。先說明緩慢發生在哪個階段，再選擇相應的測試。頁面開始傳輸後的速度，應與送出請求前的等待時間分開觀察，否則容易將解析問題誤認為頻寬不足。

建立對照時，盡量保持裝置位置、目標內容、網路與測試時段一致。先停止連線，觀察底層網路，再使用同一台既有伺服器測試；接著只更換另一個使用者已有的入口進行比較。不要一邊切換網路、一邊修改協定，否則無法判斷結果來自哪個變數。測試內容應盡量貼近實際故障情境；單次短請求正常，不代表長連線或較大資料傳輸時不會出問題。

分別判斷延遲、封包遺失與傳輸速度

連線建立較快，只表示目前測試的往返與交握過程較順利，不代表持續傳輸能力良好。遠端負載、網路壅塞、目標服務限制及 Wi-Fi 干擾，都可能影響傳輸速度。若多次測試的等待時間忽高忽低，請先觀察裝置是否移動、訊號是否變化，以及裝置是否自動切換存取點。若與路由器距離較遠，較高的無線重傳率可能比客戶端規則更值得優先檢查。

若只有某個目標速度慢，而同一路徑上的其他目標正常，請檢查該目標的存取路徑、內容快取與服務狀態。有些頁面會先顯示主體內容，再等待其他網域的資源；若附屬請求套用錯誤策略或被 REJECT，看起來也會像持續載入。此時應查看請求紀錄中最後等待或失敗的網域，不要直接認定整體連線速度不足。針對相關規則完成對照後，再測試同一頁面。

設定中的不同請求可能套用不同策略，因此同一裝置上不同 App 的使用體驗不一定相同。透過 Proxy 與 Config 短暫對照，可檢查是否為規則路徑不同；測試結束後務必恢復所需的設定模式。若 Proxy 模式有所改善，請繼續找出具體命中的規則，不要把代理模式當成所有情境的固定解法。若兩種模式都慢，請回頭比較伺服器與網路，避免不斷增加規則。

有證據時才調整 MTU 與長連線

小型請求正常、較大資料傳輸卡住，或特定協定在某種網路下持續停頓時，才值得檢查 MTU 與網路路徑相關問題。MTU 會影響可承載的封包大小，數值不是越大越快，也不是越小越穩定。優先使用既有設定提供的數值或 App 預設行為；需要測試時，每次只調整一個數值，並記錄調整前後的狀況。不同協定與網路適用的設定各異，不要把固定數值套用到所有項目。

從 Wi-Fi 切換到行動網路後，原有連線可能失效，需要重新建立連線工作階段。若切換後只有已開啟的頁面停住，但新請求正常，請優先重新整理目標 App 中的連線；若所有新請求也失敗，再重建 Shadowrocket 連線。On Demand 可能影響自動復原的觸發時機，請先驗證手動連線，再檢查自動連線條件。測試時請明確記錄切換前後使用的網路，不要短時間內反覆來回切換。

測試期間請減少其他大量傳輸、系統備份與 App 更新，讓結果更容易比較。同時檢查低數據模式、目標 App 的流量設定與裝置溫度，這些因素都可能改變 App 的行為。若裝置明顯發熱，請先讓它恢復正常運作狀態，再測試持續傳輸。不要為了觀察速度而同時啟用更多診斷功能或自動測試；額外活動本身也可能影響網路與耗電，讓原本的狀況更難判讀。

若速度問題主要出現在首次存取新網域時，請查看 DNS 章節；若伴隨大量重新連線，請回到節點逾時章節。若在多組相同條件的對照後，問題仍只出現在某個既有入口，可將去除敏感資訊後的時間、目標類型與重現條件提供給原服務提供者確認，不要繼續隨機調整客戶端參數。

06 / NAME RESOLUTION

DNS 解析失敗與網域存取異常

解析、連線與加密驗證各不相同

存取網域通常要先取得目標位址，再建立連線，最後完成上層協定交換。網頁無法開啟可能發生在任何階段，DNS 只是其中之一。若紀錄明確顯示解析逾時、沒有可用位址或解析結果異常，再依本章檢查。直接將網頁網域換成 IP 並非可靠的通用測試，因為 HTTPS 也涉及憑證名稱與伺服器依網域選擇內容；替換後出現的新錯誤可能與原問題無關。

先確認故障範圍：是所有新網域、單一網域，還是只有 Config 模式下發生。先前存取過的目標可能使用快取，短時間內重複開啟，不能證明解析一直正常。重複測試同一網域時，請留意 App 與系統可能各自保留快取；重建連線工作階段後的結果，也不一定代表所有層級的快取都已清除。因此應同時查看實際請求紀錄，不要只根據重新整理頁面的快慢判斷。

檢查解析器能否透過目前路徑連線

查看目前 Config 中與 DNS 相關的設定，並確認設定來自哪個檔案。訂閱中的伺服器項目與 Config 中的解析設定不一定會同步更新；只更新訂閱，無法保證 DNS 設定也會變更。若使用自訂解析器，請確認目前網路與策略能連線至該解析器。使用加密 DNS 時，還可能涉及解析器網域的首次解析、TLS 驗證與請求路徑；不能只因位址格式完整，就認定一定可用。

若停用自訂 DNS 後恢復正常，代表問題可能出在自訂解析路徑，但還不能斷定是解析器服務本身故障。接著比較解析器在不同網路下是否可連線、請求是否套用錯誤分流，以及相關設定是否與目前 Config 的其他部分相容。優先恢復自己已驗證過的設定，再逐項加入自訂項目。不要一次填入多個來源不明的位址，否則難以追蹤請求順序與實際使用的解析器。

了解網域規則與位址規則的差異

網域規則與位址規則所依據的資訊不同；位址規則的行為也可能受到是否觸發解析及相關選項影響。排查時請查看請求實際使用的網域、位址與命中規則，不要假設每項請求都依相同流程比對。若同一網域回傳多個位址，其中部分路徑無法連線，可能會間歇性成功。此時應將解析結果與連線失敗對照，不要只保留一次成功紀錄。

IPv4 與 IPv6 的可連線狀況可能不同。某網路宣告支援 IPv6，不代表目前使用的伺服器、目標或所有中間路徑都能順利處理相應連線。若故障與位址族有關，請在其他條件不變的情況下，比較解析結果與實際連線狀況。沒有證據時，不要將停用某個位址族當成長期解法；即使調整後恢復，也應記錄它解決的是哪條路徑，以及是否影響原本正常的其他存取。

區域網路名稱與分流範圍

家庭或工作網路中的本機裝置名稱，可能依賴本機解析或探索機制。若將所有 DNS 請求都送到遠端解析器，遠端通常無法解析只存在於區域網路中的名稱。若外部網頁正常，但無法存取本機裝置，請檢查本機網路授權、區域網路路徑及相關網域的處理方式，不要不斷更換外部解析器。區域網路名稱能否解析，以及是否允許存取裝置位址，也應分開驗證。

修正後，請分別用原先失敗的網域、新建立的連線及目標 App 驗證一次，並還原暫時關閉的診斷設定。若只修復瀏覽器，而其他 App 仍失敗，請確認 App 是否保留舊連線工作階段，或使用自己的解析方式。調整 DNS 不是解決所有連線錯誤的通用方法；確認解析成功後，就應轉查連接埠、TLS 與策略，不要持續反覆清除快取。

07 / ENERGY AND LIFECYCLE

耗電、發熱與反覆重新連線

先比較相同使用條件下的變化

判斷耗電異常時，需一併考量實際使用情境。持續傳輸、行動網路訊號較弱、頻繁切換網路、播放影片與螢幕長時間亮起，都可能增加耗電。系統電池頁面顯示的是特定統計期間的使用情況，某個 App 佔比較高，不代表耗電全由它造成。請先比較使用時間相近、網路相同、操作相近時的狀況，再判斷是否與 Shadowrocket 的連線或設定變更有關。

記錄異常開始前變更過哪些設定，例如新增 On Demand 條件、啟用更詳細的診斷、改用另一台既有伺服器，或匯入新的 Config。每次只還原一項到先前狀態，並留出足夠時間觀察。不要用幾分鐘的短暫待機推斷整天的電池表現，也不要一邊充電、一邊大量傳輸，再拿來與未充電時的輕度使用比較。測試條件差異太大，數字變化就很難解讀。

檢查重新連線循環與持續失敗的請求

連線反覆建立又中斷，會增加額外的網路活動。先觀察 VPN 連線是否穩定，以及異常是否集中在鎖定螢幕、離開 Wi-Fi 或訊號變弱之後。若伺服器參數錯誤導致持續失敗，請先處理連線問題，不要只靠降低診斷顯示量處理表面狀況。同一 App 持續重試失敗請求，也可能增加活動量；請一併確認是哪個 App 發出請求，以及失敗原因。

On Demand 是觸發連線的機制，與請求進入連線後的規則比對並非同一層。若觸發條件不符合實際使用情境，可能會在不需要時頻繁建立連線，或在網路變更後反覆重新連線。先停用 On Demand，確認手動開啟後是否穩定，再逐項恢復條件。每新增一項，都應經過正常的鎖定螢幕與網路切換流程測試；不要一次恢復所有條件後，再猜測是哪一項造成變化。

只在排查期間啟用診斷功能

詳細日誌、頻繁執行 Connectivity Test，以及持續檢視請求紀錄，適合短時間排查，不宜因擔心故障而長時間反覆測試。收集到能重現問題的紀錄後，請恢復日常使用所需的診斷層級。日誌可能包含目標網域、位址與使用時間，儲存及分享時也應遵守最小必要原則。關閉額外診斷後，仍須在相同情境下再次測試，確認改善不是因為同時停止了大量實際使用。

若設定中有高頻率自動工作，或依賴外部資源的處理程序，請檢查它們是否反覆失敗，以及是否確實需要。先複製設定作為對照，再暫時停用新增部分，同時保留核心連線與規則。不要清空整份設定後，看到耗電下降就認定某條規則有問題，因為流量路徑與使用行為也可能隨之改變。排查應逐步縮小到單一元件，並能在恢復該元件後重現相同狀況。

區分閒置連線與實際傳輸

VPN 標示持續顯示，不代表裝置始終以相同程度運作。閒置連線與大量資料處理的耗電量不同，背景 App 同步也可能讓看似閒置的裝置持續傳輸。若鎖定螢幕後仍持續發熱，可先查看系統電池與網路活動，再逐一停止非必要的背景工作。不要為了觀察而不斷點亮螢幕、重新整理測試頁面；這些操作本身會讓裝置難以進入日常的閒置狀態。

協定、網路與伺服器路徑的組合可能影響耗電，但不能只憑協定名稱一概而論。只有在服務入口與其他參數盡量相同的情況下進行對照，結果才有參考價值；使用者既有的不同入口，往往也存在遠端位置、負載與傳輸設定差異。優先處理可確認的重新連線、失敗請求與訊號微弱問題，再考慮進一步調整參數。尚未確認原因前，不要關閉所有背景連線需求，以免影響正常通知或同步。

有效的耗電問題紀錄應包含觀察時間、螢幕使用情況、網路類型、是否充電、On Demand 狀態，以及連線是否重新建立。若問題在更新或更換裝置後才出現，請保留這些條件並查看下一章。系統對耗電來源的歸因有其統計限制；單張電池截圖無法取代可重複的對照測試，也不能據此推定固定的耗電量。

08 / RECOVERY AND IPAD

更新後異常與 iPad 專項檢查

更新後先保留設定，再重建連線

系統或 App 更新後出現異常，請先記錄首次觀察到問題時的條件，不要立即認定更新改變了所有設定。遠端服務、目前網路與訂閱內容也可能剛好同時變更。先結束舊連線，重新開啟 App 並建立連線；若問題仍存在，再核對選取的伺服器、Global Routing 與目前的 Config。保留更新前可用的設定副本，有助於判斷差異是否來自選取狀態或設定內容。

完整的復原順序可包括：確認底層網路正常、核對目前選取項目、暫時關閉 On Demand、手動重新連線，再依本頁相關章節檢查錯誤。重新啟動裝置有助於清除暫時狀態，但不能取代參數核對。若重新啟動後只短暫恢復，請記錄再次失敗前發生的情況，例如鎖定螢幕、切換網路或更新訂閱。復原持續時間與觸發操作，比單純寫「重新啟動無效」更能縮小問題範圍。

App 更新與重新取得一律透過 App Store；系統要求以 App Store 頁面標示為準。購買與復原方式請參閱已購項目復原說明。重新安裝前，請確認本機伺服器、Config 與所需紀錄都已妥善保留，並且仍能重新取得既有服務資訊。App 購買紀錄不等於本機設定備份；復原已購 App 也不會自動保證所有自訂參數都恢復原狀。

iPad 請先核對選取狀態與網路權限

即使 iPad 使用相同的既有訂閱，也應分別確認目前選取的伺服器與 Config；iPhone 能正常使用，不代表兩部裝置的狀態相同。較大的螢幕可能同時顯示列表與詳細資訊；開啟某項目的詳細資訊，不一定代表它已成為目前連線使用的項目。請返回 Home 核對實際選取項目，再建立新的連線工作階段。以目前介面顯示為準，不要根據列表位置或上次開啟的詳細資訊推測連線目標。

確認 iPad 目前使用的是 Wi-Fi 還是行動網路；不同裝置可能根本不在相同的網路路徑上。具備行動網路功能的裝置，也應確認系統是否允許該 App 使用數據。若只有存取區域網路裝置時失敗，請檢查本機網路相關授權與對應規則。比較 iPhone 與 iPad 時，應盡量連上同一網路、使用相同設定與目標；否則裝置差異與網路差異會交錯，無法據此判斷是 App 問題。

鎖定螢幕、多工與設定移轉

多工或分割畫面中，介面是否仍在前景，與系統 VPN 連線是否持續執行，是兩件不同的事。請透過系統狀態與新請求結果判斷連線，不要只看某個視窗是否重新整理。若鎖定螢幕後恢復使用時出現問題，請分別測試原 App 中的舊連線與新發出的請求；若只有舊連線失敗，先重新整理目標 App；若所有請求都失敗，再重建 VPN 連線。如此可避免把 App 連線工作階段問題誤認為整部裝置的連線停止。

移轉設定時，請分開處理伺服器資訊、Config 與系統 VPN 授權。前兩者需要確認匯入內容與選取狀態；後者通常需要在新裝置上重新授權。包含認證資訊的設定，應透過自己能掌控的安全方式保存，不要當成一般範例公開分享。移轉完成後，先驗證一台既有伺服器，再檢查規則與自動連線，最後恢復其他自訂設定，避免一次匯入所有內容後難以判斷問題來源。

整理出可交接的故障紀錄

若同一份設定在一部裝置正常、另一部異常，請逐項比較系統權限、網路、時間、App 設定與實際請求紀錄。不要直接複製所有系統網路設定，也不要清除裝置中與問題無關的管理設定。iPad 的取得與首次開啟說明請參閱iPad 說明；更換裝置後復原已購項目的步驟，另可參閱更換裝置後復原 App 說明。

最後，將問題整理成可重複操作的最短流程：使用什麼網路、採用哪種模式、執行什麼操作、出現什麼錯誤、哪些對照正常，以及最近只變更了哪一項。附上已去除敏感資訊的錯誤類別與時間即可，不必提交所有歷史紀錄。若復原後再次出現相同症狀，請依照先前驗證過的順序重新檢查；若症狀不同，則回到相應章節重新建立基準，不要將一次有效的復原方式視為永久適用的解法。