OFFICIAL MANUAL / DIAGNOSTICS

Shadowrocket
疑難排解大全

依症狀找出連線、訂閱與設定問題。每次只變更一個條件，保留原始設定，並在相同條件下再次確認結果。

本頁為官方手冊的系統性查閱內容。首次匯入現有訂閱、選擇 Global Routing 並建立連線的完整步驟，請參閱使用教學；若已完成設定但出現異常，請從下方目錄選擇相應章節。

01 / CONNECTION SWITCH

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

開關無法維持開啟，與開啟後網頁無法載入，是兩種不同問題。前者應優先檢查系統是否允許建立 VPN 設定、是否有其他連線設定正在使用，以及目前設定能否正常載入；此時反覆修改 DNS 或規則通常無法提供有效線索。先記下開關是在授權前、授權後，還是連線數秒後跳回關閉，後續排查應依此分流。

先分辨授權失敗或連線失敗

首次啟用連線時，系統可能會要求允許加入 VPN 設定，並透過裝置驗證確認。這是系統授權流程，不是訂閱驗證。請先確認彈出視窗所指的應用程式，再確認來源無誤後完成授權。若先前取消了彈出視窗，可返回 Home 再嘗試啟用；若裝置顯示限制提示，請檢查裝置管理政策，不要反覆點按開關試圖繞過限制。

先關閉 Shadowrocket 連線，再前往系統 Settings，查看 VPN 相關項目是否已有其他設定正在連線。
暫時停止其他由使用者自行啟用的 VPN 連線或自動連線功能，返回 Shadowrocket，只測試一次開啟。
若仍立即關閉，請確認 Home 已選取實際存在的伺服器，並檢查 Config 中目前的設定是否可讀取。
記錄系統提示與應用程式內的錯誤，再判斷要處理權限、還原設定，或繼續檢查伺服器參數。

裝置上有多個 VPN 設定，不代表必須全部刪除。需要隔離的是同時運作的連線或自動重新連線行為。公司或學校管理的設定可能受到政策保護，刪除也可能影響正常存取；遇到這種情況，請先確認管理要求。若一個連線停止後，另一個立即恢復，應優先檢查雙方的 On Demand 或系統自動連線設定，而不是認定應用程式開關故障。

以最少變更確認設定能否啟動

若異常是在匯入設定後開始，先保留原始檔案，再切換回先前已確認可啟動的設定。不要同時更換伺服器、網路、規則又重建 VPN，否則即使恢復正常，也無法判斷是哪一項發揮作用。設定載入錯誤可能來自區段標題、選項拼字、策略引用或檔案內容不完整；請查看實際錯誤位置，不要把所有啟動失敗都歸因於伺服器無法連線。

若開關能維持開啟，但連線沒有流量，請前往下一章；若開關維持開啟但測試伺服器逾時，請參閱伺服器逾時章節。開關顏色或系統連線標示只能反映部分連線狀態，不能取代實際請求測試。測試時請選擇固定網頁，先觀察是否成功建立連線，再查看應用程式內是否有相應的請求記錄，不要只憑圖示下結論。

修改設定後問題仍存在時，可先正常重新啟動裝置，再重現一次。重新啟動能清除暫時的執行狀態，但無法修正錯誤密碼或伺服器參數。只有在確認本機資料已備份、帳號還原條件明確，而且一般重新啟動與切換設定均無效後，才考慮重建自己的 VPN 設定。重置系統網路設定影響範圍較大，不應列為第一步。

恢復後的檢查項目

連線穩定開啟後，先維持目前網路不變，依序開啟網頁、返回 Home、鎖定螢幕再解鎖，確認沒有再次出現關閉提示。接著再恢復確實需要的 On Demand 條件，觀察是否因此反覆連線。若問題只在鎖定螢幕後發生，請記下當時網路是否從 Wi-Fi 切換到行動網路，這比只描述「背景中斷」更有助於找出原因。

02 / TRAFFIC PATH

連線已開啟，但無法上網

開啟連線表示系統已建立相關網路處理路徑，不代表伺服器、DNS、規則與目標網站都正常。先判斷故障範圍：所有應用程式都失敗、只有瀏覽器失敗，還是只有特定網域失敗。也要分辨網頁完全無法開啟，或頁面文字已出現但圖片、登入功能失敗；後者常與不同網域套用不同策略有關，不應直接視為整條連線失效。

先確認基本網路，再隔離路由模式

關閉 Shadowrocket 連線，用同一部裝置瀏覽平常能正常開啟的網頁。如果基本網路也無法使用，請先完成 Wi-Fi 登入驗證、檢查行動數據權限，或處理路由器連線問題。公共網路的驗證頁面有時必須在關閉連線時完成。基本網路恢復後再開啟連線，避免把原本就無法連上網際網路的網路誤判為設定錯誤。

基本網路正常後，記下 Global Routing 目前的選項。Config 模式依目前設定中的規則決定流量路徑；Proxy 模式適合暫時確認所選伺服器能否處理請求；Direct 模式可用來對照直連路徑，但仍不能取代關閉連線後的基本網路測試。測試結束後請恢復原本的運作模式，不要為了開啟單一網頁而長期改變所有流量的處理方式。

Global Routing	排查用途	結果無法證明的事項
Config（設定）	依設定規則檢視實際命中規則與策略	單一目標正常，不代表所有規則都正確
Proxy（代理）	暫時排除規則分流因素，確認所選伺服器	請求正常，不代表 Config 模式中的策略引用正確
Direct（直連）	對照目前連線中的直連處理路徑	不能取代關閉連線後的基本網路檢查

從失敗請求反查規則與策略

如果 Proxy 能存取而 Config 失敗，請優先檢查該網域實際命中了哪條規則，以及規則對應的策略是否指向預期伺服器。規則依序比對，較廣泛的規則若排在前面，可能會先攔截請求。不要只查你認為應該命中的規則；請根據當次請求記錄確認實際結果，尤其留意 DIRECT、REJECT 與最後的 FINAL。

以下規則片段用於說明順序，不是可直接替換使用的完整設定。example.com 是教學用網域；PROXY 在實際設定中必須有有效的對應項目。第一條規則處理該網域及其子網域，第二條依地理資料庫比對位址，最後一條接收前面未命中的請求。實際設定應依自己的存取需求設計，並核對使用的策略名稱。

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

若 Proxy 也無法連線，請先改用自己已有且曾確認可用的其他伺服器進行比對。如果所有伺服器都失敗，繼續檢查 DNS、目前網路與共同設定；如果只有一台失敗，請參閱伺服器逾時章節。此時不要一次大量更新所有設定，因為多處變更會讓原本可用的狀態失去參照，反而擴大排查範圍。

分辨網站異常與用戶端路徑異常

只有一個網站失敗時，請檢查是否只有登入、影片或附件網域無法存取。網頁通常會同時請求多個網域，主頁成功不代表資源網域也都正常。也請留意系統時間、憑證提示與目標服務本身的狀態。出現憑證警告時不要直接關閉驗證；請先判斷是裝置時間錯誤、驗證頁面攔截，還是伺服器參數指定的名稱不一致。

完成調整後，使用同一個目標重複測試，並記錄目前網路、模式、伺服器與命中策略。再選擇一個採用不同策略的目標，確認修復局部問題時沒有影響其他存取。規則比對原理可繼續閱讀規則關鍵字與比對順序；常見連線問答請參閱常見問題。

03 / SERVER REACHABILITY

伺服器逾時、驗證失敗與連線中斷

伺服器測試逾時，只能表示這次測試未能在限定時間內完成，不能單憑這個結果判斷伺服器永久無法使用。測試方法、網域解析、傳輸交握與目標請求都可能影響結果。先記下測試名稱與錯誤原文，再比較實際網頁存取情況；如果測試失敗但實際瀏覽正常，請檢查測試目標與方法，不要立即刪除現有伺服器。

依序核對位址、連接埠、驗證資訊與傳輸設定

進入現有伺服器的編輯頁面，逐項對照自己的原始資料，特別留意複製時是否帶入空格、換行或全形標點。位址欄位只能填入該欄要求的伺服器位址，不要貼上完整分享連結；連接埠必須與伺服器端一致。伺服器名稱只是本機辨識標籤，修改名稱無法修復位址或驗證資訊，也不應將名稱當作伺服器端的識別參數。

參數項目	檢查重點	常見情況
位址與連接埠	位址拼字、連接埠、目前網路是否可連線	解析失敗、連線逾時或連線遭拒
驗證資訊	密碼、UUID、加密方式與伺服器端要求	交握後失敗、驗證錯誤或連線關閉
TLS	伺服器名稱、憑證、裝置時間	憑證驗證或交握失敗
傳輸設定	傳輸類型、Host、Path 等相關參數	基本連接埠可連線，但無法建立應用程式請求

不同協定的欄位並不通用。Shadowsocks 的密碼與加密方式必須相互配合；VMess、VLESS 需核對相應的身分資訊及傳輸設定；Trojan 應檢查密碼與 TLS 相關參數；Hysteria2 也涉及以 UDP 為基礎的傳輸條件。不能因為兩台伺服器位址相同，就把一種協定的參數整組複製到另一種協定。請以自己的伺服器資料為準，不要根據錯誤提示猜測密碼。

透過受控比對判斷網路與伺服器的問題範圍

先在目前網路測試自己已有的另一台可用伺服器，再讓原伺服器於另一種可用網路下重試。前者更換伺服器、維持網路不變；後者更換網路、維持伺服器不變。若同一台伺服器只在某種網路下失敗，請優先檢查該網路的存取限制、驗證狀態或 UDP 條件；若它在不同網路都失敗，但其他伺服器正常，問題可能較接近伺服器或帳號狀態。

測試時不要同時執行多個持續測速工作。短時間內密集建立連線，可能觸發伺服器端的並行連線限制，也會改變裝置負載和網路壅塞等測試條件。完成一次測試後再進行下一次，至少保留一份完整錯誤記錄。切換網路後應重新建立連線，避免將舊連線尚未恢復的狀態誤認為新網路的穩定結果。

驗證失敗通常需要核對原始憑證、帳號有效狀態及伺服器端變更，單純修改 DNS 無法修復密碼錯誤。連線遭拒與連線逾時也不相同：前者可能表示目標連接埠沒有提供預期服務；後者則可能發生在更早的傳輸路徑或交握階段。記錄中的錯誤只是定位線索，仍須搭配可重現的比對結果，不要把某個詞句當成唯一結論。

不要藉由降低驗證要求掩蓋根本原因

遇到憑證問題，請先檢查裝置日期、伺服器名稱與原始設定。任意略過憑證驗證會失去一項身分核對機制，也可能讓真正的名稱設定錯誤繼續存在。若伺服器端採用特殊憑證配置，請依自己掌握的部署資料處理；若沒有可靠資料，請保留原狀並向現有服務的維護方說明錯誤，不要把安全選項當成通用的加速開關。

04 / SUBSCRIPTION UPDATE

訂閱匯入失敗、更新失敗或列表異常

訂閱更新至少包含取得網址內容、辨識內容格式、儲存伺服器列表三個階段。匯入錯誤不一定代表伺服器本身無法連線；同樣地，訂閱更新成功也不代表列表中的每台伺服器都可用。排查時先確認失敗發生在哪個階段：請求完全沒有回應、收到錯誤頁面，或已取得內容但無法辨識；這三種情況需要不同處理方式。

先確認連結屬於哪種內容

單一分享連結、伺服器列表訂閱與完整設定檔用途不同。單一分享連結描述一台伺服器；訂閱網址用來取得可更新的列表；設定檔則可能包含規則、DNS 與策略。不要只憑網址外觀判斷用途，請對照自己現有資料的說明。匯入入口不相符時，重複貼上不會改變內容性質，還可能在列表中產生難以辨識的重複項目。

複製網址時，請檢查是否一併複製到聊天軟體自動加上的結尾標點、換行或顯示用省略號。有些網址包含查詢參數，少一個字元就可能導致驗證失敗；也不能擅自把網址中的協定、路徑或參數改成看起來較熟悉的形式。訂閱網址本身可能具有存取權限，應視為憑證保存，不要為了求助而將完整內容貼到公開頁面。

記下目前伺服器群組名稱與數量的大致變化，保留更新前仍可用的內容。
確認自己的原始訂閱網址完整，且匯入入口適用於該類內容。
手動更新一次並查看錯誤提示，分辨是網路、驗證還是格式辨識失敗。
更新成功後，檢查目前選取的伺服器與策略引用，再進行實際連線測試。

檢查訂閱請求使用的網路路徑

若更新時出現網域解析或連線逾時，先確認基本網路是否正常，再判斷訂閱請求是否依賴目前已失效的連線。有些網址透過直連路徑與現有連線存取時，結果可能不同；應透過一次受控切換確認，不要不斷點選更新。若必須依賴現有可用連線才能取得訂閱，請先使用自己已確認可用的伺服器完成更新，避免形成相互依賴。

如果收到的內容是登入頁面、驗證頁面或存取錯誤說明，用戶端就無法將它正常解析為伺服器列表。瀏覽器能顯示頁面，只能證明有收到內容，不代表內容是有效訂閱。不要將另存頁面的文字當成設定強行匯入；請核對自己的帳號狀態、網址有效性及原始資料，必要時詢問現有服務的維護方，確認該網址實際回傳的內容類型。

更新後列表變空或大量項目變動時，請先停止連續更新，檢查是否匯入了另一個網址、原訂閱已撤銷，或伺服器端調整了回傳列表。若保留了更新前的記錄，可比較群組名稱與伺服器名稱，但不要依名稱推斷連線參數完全相同。名稱相同的項目也可能已變更位址或驗證資訊，仍須進行實際連線驗證。

處理重複項目與失效引用

手動新增的伺服器與訂閱產生的伺服器可能同時存在。清理前請先確認來源，避免連同仍需保留的手動項目一起刪除。若規則策略直接引用某個伺服器名稱，訂閱更新後的重新命名可能使引用失效；此時應檢查策略實際指向，而不是只看列表中「還有很多伺服器」。先修正引用，再決定是否整理重複項目。

用戶端列表、訂閱服務的帳號狀態與設定中的規則，是三個不同層面。更新伺服器列表通常不等於更新所有規則，也不能假設會自動修復手動修改的 DNS。恢復後請確認更新時間或結果提示、列表內容、目前選取項目，以及一次實際存取。若仍不清楚內容類型，可閱讀分享連結與訂閱的差異。

05 / PERFORMANCE

延遲正常但速度慢、影片播放卡頓

延遲、傳輸量與網頁載入完成時間衡量的並非同一件事。延遲測試主要反映特定互動所需時間，不能直接換算為持續下載速度；影片播放也會受到目標服務、快取、位元率與分段請求影響。先將「很慢」描述成可觀察的狀況，例如首次開啟等待很久、剛開始很快但隨後停頓，或只有大型檔案傳輸緩慢，再選擇相應的測試方式。

建立可重複的比對條件

固定使用同一網路、同一裝置、同一目標與同一伺服器，結束其他大量傳輸工作後再測試一次。若同時更換測速網站與伺服器，兩次結果就難以比較。網頁快取也會影響第二次開啟速度，因此請記錄是首次載入或再次載入；影片則記錄是否只有拖曳播放進度後才卡頓。測試目標本身的負載變化同樣會影響結果，不要只憑一次測試判斷整條路徑。

先關閉連線，比較基本網路速度，再開啟連線並確認目標採用預期策略。如果基本網路本身就很慢，請先檢查 Wi-Fi 訊號、路由器負載與行動網路涵蓋範圍。Wi-Fi 顯示已連線，不代表訊號品質和對外頻寬都良好；離路由器太遠、頻繁切換基地台，或其他裝置同時佔用，都可能造成連線測試偶爾正常，但持續傳輸不穩定。

暫停背景備份、應用程式更新與其他主動傳輸，並記錄裝置是否發熱。
使用固定目標，比較基本網路與開啟連線後的結果，確認 Global Routing 及命中策略。
只切換到自己已有的另一台可用伺服器，維持其他條件不變，再重複請求。
最後才切換網路，比較問題是否隨伺服器、目標或網路改變。

分辨解析等待、交握等待與持續傳輸

首次開啟時長時間顯示空白，之後內容迅速出現，可能與 DNS 或連線交握有關；頁面持續逐步載入，則較可能涉及傳輸量、重傳或資源請求問題。請搭配請求記錄查看失敗網域、連線建立情況與錯誤，不要只憑使用感受就修改所有設定。若主頁正常但圖片載入緩慢，請檢查圖片網域是否採用不同策略；下一步應檢查規則，而不是進行整體測速。

伺服器所在地、當時負載、目標網站的連線品質與路徑壅塞都會影響效能。低延遲伺服器不一定能為目前目標提供較高傳輸量；同一台伺服器連線不同網站，表現也可能不同。使用自己現有的伺服器進行比對即可，無須為了排查而新增服務。只有在相同條件下多次得到一致結果，才適合判斷某條路徑不適合目前用途。

涉及 UDP 的應用程式或協定應分開觀察。有些網路對 UDP 的處理方式與一般網頁連線不同，網頁能開啟不代表即時影音或以 UDP 為基礎的傳輸一定正常。不要一次更改傳輸協定、連接埠和進階參數；先確認伺服器端支援條件，再進行有記錄的單項測試。隨意填入較大的頻寬參數不會提升實際對外傳輸能力，還可能讓壅塞更明顯。

控制進階調整的範圍

MTU 等網路參數不適合當作通用的加速選項。如果只有較大的請求會卡住，而小型請求反覆成功，應先記錄具體重現方式與網路比對結果，再依已確認的環境需求調整。每次修改前記下原值，修改後重試同一個失敗請求；若沒有改善就恢復原值。沒有明確症狀時，保留預設值通常比疊加多項未經驗證的設定更容易維護。

測試期間裝置過熱、電量過低或持續錄影，也可能改變實際使用體驗。請先讓裝置恢復正常溫度，再進行短時間比對；不要透過持續滿載網路來驗證日常網頁問題。恢復正常的標準應是原先失敗的工作能穩定完成，而不是某次測試數字變得更漂亮。若主要症狀是首次解析等待，請前往DNS 章節；若伴隨持續發熱，請繼續查看耗電章節。

06 / NAME RESOLUTION

DNS 解析失敗與特定網域無法開啟

DNS 負責將網域轉換為後續連線所需的位址。伺服器延遲測試正常但網頁無法開啟，可能是因為測試與網頁使用不同網域、解析路徑或規則。請先確認失敗發生在解析階段，還是取得位址後連線失敗；兩種狀況都可能讓瀏覽器一直等待，但處理方向不同。應用程式內顯示的錯誤與請求記錄，比單看空白頁面更有參考價值。

從一個具體網域開始檢查

選定一個反覆失敗的網域，記下失敗時間與目前網路。再用平常運作正常的網域進行比對，觀察是否所有解析都失敗。如果所有網域都失敗，先檢查設定中的 DNS 位址是否有誤，以及該解析服務能否透過預期路徑連線；只有特定網域失敗時，再考慮網域本身的記錄、快取、分流或位址類型差異，不要直接替換整套 DNS 設定。

設定中可能包含系統解析、指定解析服務，以及不同請求路徑的安排。請先檢查目前實際生效的 Config，確認不是在修改未啟用的檔案。如果伺服器位址本身也是網域，也必須先完成解析；若解析路徑又依賴尚未建立的伺服器連線，就可能形成相依問題。排查時應分別記錄「伺服器網域解析」與「目標網站網域解析」。

從規則理解解析與連線的關係

網域規則與位址規則的比對對象不同。DOMAIN 比對特定網域，DOMAIN-SUFFIX 比對網域後綴及其子網域；IP-CIDR 依位址網段比對，GEOIP 則依賴位址與資料庫資訊。某個請求最終採用哪條策略，必須根據實際命中結果判斷。不能因為設定中出現某個網域，就認定它一定優先於前面的其他規則。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

此片段僅用於說明比對對象。範例網段是文件專用位址，不代表可用服務；no-resolve 表示該位址規則不會為了比對而主動觸發網域解析，不代表關閉所有 DNS。若不了解這個範圍而為位址規則大量加入此參數，可能使原本依賴解析結果的判斷不再符合預期。完整規則仍應配合現有策略與實際目標設計。

修改解析設定前先保留原始設定，每次只變更一個解析來源或一項相關選項，然後重新建立連線並重試同一個請求。瀏覽器、應用程式、系統與連線內都可能有快取，修改後短時間仍出現舊結果，不一定代表新設定無效；但也不要反覆清除整個環境。先關閉再開啟目標應用程式，必要時正常重新啟動裝置，再比對記錄中的解析與連線結果。

分辨位址類型、加密解析與目標服務問題

同時存在 IPv4 與 IPv6 記錄時，不同網路的可達性可能不同。如果只在特定網路下出現等待，請核對最終使用的位址與連線錯誤，而不是立即認定網域不存在。直接輸入 IP 位址瀏覽網頁也不是可靠的替代測試，因為網站可能依賴主機名稱、憑證名稱與虛擬主機設定。IP 位址無法存取，不能單獨證明原網域解析錯誤。

使用加密 DNS 時，它本身也需要可連線的網路路徑，並可能涉及憑證與系統時間。啟用加密不代表在任何網路下都能成功解析。若變更後所有網域都無法解析，請先恢復先前可用的設定，確認是否為解析服務無法連線或路徑相依，再逐項調整。不要藉由關閉憑證驗證來掩蓋解析連線的身分驗證問題。

若同一網域在其他正常網路中也無法解析，問題可能出在網域本身；若能解析但連線失敗，請回到伺服器與規則章節。修復後至少檢查一個原先失敗的網域、一個正常的比對網域，以及目前的伺服器網域，確認不是只修好其中一段。更多症狀對照請參閱DNS 解析失敗排查筆記。

07 / BATTERY AND ACTIVITY

耗電異常、發熱與背景反覆連線

理解系統電池用量中的占比時，需一併考量統計時段與裝置整體使用量。某個應用程式占比上升，可能是其他應用程式使用減少，也可能與經過連線處理的流量、持續重試或前景診斷有關；不能只看單一百分比就判定耗能異常。請先記錄充電狀態、螢幕使用情形、網路類型與實際發熱，再比較條件相近時的表現。

分開檢查閒置耗電與傳輸耗電

下載檔案、播放高畫質影片、雲端同步與個人熱點分享都會產生持續的網路活動。連線處理這些流量時可能增加裝置負載，但實際發出請求的應用程式未必是 Shadowrocket。請先暫停自己明確知道的大量傳輸工作，維持其他使用習慣一致，觀察閒置時是否仍持續發熱。不要一邊執行密集測試，一邊依電池變化判斷日常待機耗電。

在系統 Settings 的電池記錄中，選擇與問題發生時間相符的時段，查看前景與背景活動，以及其他應用程式是否也在運作。若裝置正在充電、剛完成系統更新或正在處理照片，也請分別註明。這些條件都會影響溫度與耗電，混在一起比較無法隔離原因。記錄最好描述為「同一網路、螢幕關閉、暫停同步後仍反覆連線」，而不只是「感覺比較耗電」。

檢查 On Demand 與網路切換

On Demand 用來依條件建立連線，並非排錯時必須持續啟用的功能。若問題表現為關閉連線後又自動開啟，請先檢查自己的 On Demand 條件，以及系統中的其他自動連線設定。可暫時停用相關自動行為，再手動連線進行比對；確認穩定後再逐項恢復，避免多個條件同時影響，導致反覆啟動與停止。

Wi-Fi 訊號微弱、頻繁進出無線涵蓋範圍，以及行動網路訊號變化，都可能讓連線重新建立。此時持續重試本身會消耗資源，也可能造成網頁短暫中斷。請將裝置放在訊號穩定的位置測試，再比較移動過程中的表現。若只有網路切換時才出現異常，請記錄切換前後的網路狀態，而不是直接將所有背景活動都視為用戶端問題。

記錄系統電池統計時段、目前網路與裝置溫度，並停止主動測速。
暫停已知的大量傳輸工作，觀察閒置時是否仍有持續請求。
暫時停用 On Demand，透過手動連線確認是否仍會反覆連線。
只切換到自己已有的穩定伺服器，觀察重試與發熱是否同時減少。
恢復必要功能後再次檢查，並保留可重現問題的最少條件。

減少不必要的診斷負載

長時間保留詳細診斷記錄、持續執行 Connectivity Test，或反覆更新所有訂閱，都會額外增加網路流量與處理負載。排查時可短暫啟用需要的記錄，取得一份有效的失敗樣本後就停止；不要將診斷工作長期留在背景，當作運作狀態指示。恢復一般設定後，也要確認沒有其他自動化流程繼續反覆觸發測試或請求。

若某台伺服器持續交握失敗，反覆嘗試連線可能比穩定連線更耗資源。此時應先依伺服器逾時章節修正位址、驗證資訊或網路條件，而不是只減少記錄。若只有某個目標應用程式持續請求失敗，也請檢查它對應的規則與 DNS；錯誤策略造成的重複請求可能讓耗電增加，根本原因卻在該目標的連線路徑。

裝置明顯發熱時，先停止高負載工作，並放在通風良好的環境中，待溫度恢復後再進行短時間測試。不要在溫度異常時長時間重複測量，因為裝置效能與網路行為可能已經改變。不能將短時間的電量變化直接推算成全天耗電；應使用時長、網路與使用量相近的記錄比較，才有參考價值。

08 / RECOVERY AND IPAD

更新後異常與 iPad 專項還原

更新後出現問題，請先確認實際變更了哪些項目：應用程式更新、系統更新、訂閱更新與設定切換可能發生在相近時間，不應一概歸因於應用程式。記下最後一次正常使用的環境與目前差異，再依前面章節找出症狀。價格、系統需求與裝置相容性請以 App Store 頁面標示為準；應用程式的取得與更新均透過 App Store，正版確認方式請參閱下載說明。

先備份，再依影響範圍逐步還原

保留目前設定、自己手動新增的伺服器資料與必要的訂閱網址，並確認備份儲存在自己可掌控的位置。含有密碼或訂閱參數的檔案不要公開分享。接著正常重新啟動裝置，在原本的網路與目標上重現一次；若恢復正常，再觀察是否只是暫時的執行狀態。若仍然失敗，請分別檢查基本網路、連線開關、伺服器、規則與 DNS，不要直接清除所有資料。

若異常緊接在編輯設定後發生，優先還原先前可用的設定副本；若緊接在更新訂閱後發生，核對伺服器變化與策略引用；若只有系統升級後 VPN 授權狀態異常，再檢查系統 Settings 中自己的 VPN 設定。請依已知變更逐層還原，不要把重新安裝、刪除設定與重置網路當成一連串步驟執行。

重新取得應用程式前，先確認購買時使用的 Apple 帳號與已購項目記錄。應用程式購買記錄不等於伺服器資料備份，重新下載也不會自動修復失效的訂閱。已購項目還原入口與注意事項請參閱換機與重新安裝還原，也可閱讀使用原帳號還原購買項目的說明。不要為了排查連線問題而先登出帳號，徒增其他變因。

在 iPad 上分別確認購買、設定與實際連線

在 iPad 上應分別確認應用程式是否可取得、自己的設定是否已匯入，以及連線是否確實開啟。這三件事不能互相取代。同一購買帳號的已購項目下載方式與通用購買範圍，請以 App Store 頁面標示為準；即使已成功取得應用程式，仍須核對自己的訂閱、伺服器與規則。不能因為另一台裝置運作正常，就假設這台裝置已有相同設定。

橫向、直向與分割畫面可能會改變功能入口在螢幕上的位置，但不會改變排查順序。編輯前先確認目前選取的伺服器群組與 Config，避免在分欄畫面中修改了另一個項目。若切換視窗後發現選項不如預期，請返回 Home 重新確認目前的選取項目，再進行實際請求測試；不要根據視窗位置或上次停留的頁面判斷目前生效狀態。

只有 Wi-Fi 連線能力的 iPad，與同時具備行動網路連線條件的裝置，可進行的網路比對不同。若無法切換至行動網路，可在自己有權使用的另一處正常 Wi-Fi 網路上測試。若同一設定在兩台裝置上的表現不同，請先比較網路、系統授權、Global Routing、目前伺服器與實際設定內容；只比較伺服器名稱，很容易忽略參數差異。

處理鎖定螢幕、切換網路與單一應用程式異常

若 iPad 在鎖定螢幕後恢復存取較慢，請先觀察 Wi-Fi 是否重新連線，再確認 VPN 是否重新建立。不要只依狀態列標示判斷，因為不同顯示環境中可見資訊可能不同。解鎖後使用固定網頁重現問題，記錄第一次請求是否失敗、之後是否自行恢復；若只在某個網路發生，應優先檢查該網路的連線穩定性與自動驗證條件。

外接鍵盤、瀏覽器多個視窗或不同應用程式中的網頁，可能使用不同的快取與工作階段。只有一個視窗異常時，先關閉該視窗並重新開啟目標，確認是否為登入或快取問題；若其他應用程式正常，不必立即重建整台裝置的網路設定。若所有應用程式都失敗，再回頭檢查基本網路與全域路由，依由局部到整體的範圍處理。