Shadowrocket
疑難排解大全

連線開關無法啟用或連線立即中斷

先區分兩種情況：點按 Home 的連線開關後一直無法進入連線狀態，或已連線但幾秒後自動中斷。前者優先檢查系統授權、裝置限制及設定是否有效；後者還需檢查其他 VPN 設定、On Demand 條件與網路切換。記下點按後顯示的提示原文、系統是否跳出確認視窗，以及開關何時重設。只憑「無法啟用」無法判定是伺服器故障；如果系統尚未建立本機 VPN 工作階段，反覆更換伺服器通常無法解決問題。

檢查系統授權與裝置限制

首次建立連線時，系統可能會要求允許新增 VPN 設定，並透過裝置密碼或系統驗證確認。確認來源是目前開啟的 Shadowrocket 後再繼續；如果剛才選擇取消，請返回 App 重新發起連線，查看是否再次出現授權提示。前往系統 Settings 中的 VPN 管理位置，確認是否有對應設定；不同系統的入口名稱與層級可能不同，可使用系統設定搜尋。設定存在只代表系統已儲存連線描述，不代表伺服器驗證成功。

如果裝置由公司或學校管理，VPN 修改權限可能受到管理政策限制。先查看是否有管理提示，再向裝置管理員確認允許的使用方式，不要刪除不熟悉的管理設定。個人裝置也應檢查是否有其他 VPN 服務正在連線：先在該服務本身的設定中停止，再測試 Shadowrocket。排查時記錄原本狀態，避免直接清除原本用於工作網路的設定。如果系統設定中的開關也立即重設，應優先保留系統提示，而非繼續調整規則內容。

以最少變更區分設定與自動連線

暫時關閉 On Demand，並記下原本的條件。網路變更後，它可能重新發起連線，讓「手動停止後又連線」看起來像是開關失效。接著確認 Home 已選擇參數完整的伺服器，並在 Config 確認目前使用的設定檔可正常讀取。如果問題是在編輯設定後立刻出現，先複製該檔案，再還原最近一次可用的副本；不要未經檢查就用大段設定覆蓋唯一副本。規則、DNS 與改寫內容應分開還原，才能找出影響連線的項目。

結束目前的操作流程後重新開啟 App，再試一次；仍然失敗時，可先儲存工作，再重新啟動裝置，以排除暫時性的系統網路延伸功能狀態異常。重新啟動不是修復伺服器的方法；如果每次都只能短暫恢復，應繼續找出觸發條件，例如從 Wi-Fi 切換到行動網路、鎖定螢幕後重新喚醒，或另一項 VPN 服務開始連線。逐一測試每個條件，並記錄發生時間與現象，避免把不同問題混為一談。

確認連線是否穩定恢復

開關保持啟用後，先造訪平常可正常使用的網站，再鎖定、解鎖裝置並重複造訪。如果只看開關顏色而未發出實際請求，可能會漏掉「工作階段已建立，但服務無法使用」的問題。若開關穩定但網頁無法開啟，請前往下一章；若再次出現系統授權錯誤，保留提示並確認裝置權限。需要重新取得 App 時，請依照已購項目復原說明操作；App 更新與復原均透過 App Store，系統需求以 App Store 頁面標示為準。

對外說明問題時，請寫清楚是「手動連線後立即中斷」還是「切換網路後中斷」，並附上系統提示的文字摘要。設定名稱、網路類型及是否啟用 On Demand 有助於重現問題；請勿在公開截圖中放入伺服器密碼、訂閱網址或身分憑證。這份紀錄也能作為後續比較基準：修復後在相同網路下重複相同觸發動作，才算完成驗證。

顯示已連線，但網頁或 App 無法上網

連線標示表示系統 VPN 工作階段已建立，不代表每個請求都能到達目的地。一次連線還可能經過 DNS、規則比對、伺服器連線及目標網站回應。先暫時中斷 Shadowrocket，測試同一個網頁：若中斷後仍無法使用，優先檢查 Wi-Fi 登入認證、行動網路權限、路由器與目標網站狀態。公共 Wi-Fi 可能需要先完成系統認證頁面；基礎網路尚未連上網際網路時，修改 PROXY 或 DIRECT 規則只會增加變數。

使用 Global Routing 判斷問題範圍

先記下原本的 Global Routing，再分別進行短時間對照。Config 會依目前設定中的規則處理請求；Proxy 通常會將一般業務請求交由所選代理路徑處理；Direct 則用於對照基礎網路。這些是排查模式，不是三台獨立伺服器。系統流量、設定中的特殊處理及具體功能仍可能影響結果，因此不要只憑一次對照就推斷所有請求的路徑。每次切換後都應重新發起請求，而不是只查看已快取的頁面。

如果 Proxy 可以連線而 Config 不行，請開啟目前實際啟用的設定檔，確認目標網域會先符合哪條規則。常見情況包括寬泛規則排在精確規則前、策略指向已失效的名稱，或 REJECT 規則擋住 App 所需資源。不要只搜尋首頁網域：開啟 App 時還可能請求認證、圖片與 API 等多個網域。比起將所有流量永久改為 Proxy，搭配請求紀錄核對實際失敗項目更有助於定位原因。

依序檢視規則，不要只搜尋關鍵字

以下片段用於說明比對順序，不能直接取代使用者的完整設定。規則通常由上而下比對，第一個符合的規則決定處理方式；FINAL 負責處理先前都未符合的請求。範例中的私人網段僅用來說明區域網路直連，實際使用時仍需確認本機網路與設定需求。涉及 IP 判斷的規則與網域解析有關，不能將它們視為完全獨立的設定。

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

如果 Config 和 Proxy 都失敗，而 Direct 正常，請先檢查所選伺服器與代理路徑；如果只有一個網站無法使用，則應進一步區分目標服務異常、DNS 回傳不合適的結果、規則誤比對及伺服器拒絕存取。瀏覽器能開啟網站，也不代表其他 App 一定正常；它們可能使用不同網域、連線方式與快取。使用兩個互不相關的網站及一個常用 App 交叉測試，可避免把單一服務的問題誤判為整體斷網。

還原原設定並驗證實際請求

排查結束後，還原原先的 Global Routing，只保留已確認必要的規則變更。重新連線後發起新請求，確認網頁本文與附屬資源都能載入，再測試先前失敗的具體操作，例如登入或上傳圖片。如果仍有問題，記錄網域、符合的規則、策略及錯誤類型，並參閱規則分流說明確認其意義。不要一次加入大量例外規則；臨時直連也應限於已確認的目標，避免改變其他請求的處理路徑。

如果現象是「網域無法開啟，但測試仍有結果」，請不要只繼續切換路由模式，改看DNS 問題一章。連線測試與實際瀏覽網頁涵蓋的鏈路不同，測試成功只能證明該測試實際執行的部分正常。

節點逾時、連線遭拒或協定交握失敗

先保留錯誤類型，再檢查伺服器參數。逾時通常表示在測試等待時間內未收到預期回應，問題可能發生在基礎網路、伺服器連接埠、協定交握或目標請求階段；連線遭拒通常較可能是目標連接埠未接受連線；身分驗證失敗則應優先確認憑證。不同測試方式的結果不能直接互換。記錄 Connectivity Test 結果時，也應一併記下測試方式；單一數值不能證明所有協定功能都正常。

先排除選錯項目與地址錯誤

返回 Home 確認目前選取的伺服器，而不只是查看最近開啟的編輯頁面。訂閱更新後可能出現名稱相似的項目，舊項目也可能仍留在清單中。開啟對應的編輯資訊，逐項比對協定、伺服器網域與連接埠，留意複製時帶入的空格、全形符號，以及誤將完整分享連結填入伺服器地址欄位。網域與連接埠用途不同，通常應填入各自的欄位；不要只根據名稱中的地區或備註判斷實際使用的地址。

同一個項目在 Wi-Fi 下逾時、在行動網路下正常，表示問題與接取網路或連往伺服器的路徑有關，但還不能直接斷定伺服器完全正常。先確認兩種網路都能連線造訪一般網站，再在相近時間進行一次對照，避免把不同時段的負載變化也算進結果。如果所有現有項目在同一網路都失敗、換到另一網路卻正常，應檢查路由器限制、網路認證與 UDP 可用性；不要批次修改每個項目的密碼碰運氣。

依協定檢查交握所需參數

對於使用 TLS 的設定，請確認伺服器提供的網域相關欄位、裝置時間與憑證有效性。裝置時間明顯不正確會影響憑證判斷，應先校正時間再測試。不要將關閉憑證驗證當作一般修復方式，這會改變連線的身分驗證界線。對於含有傳輸層設定的協定，Host、Path 與 TLS 相關名稱可能分屬不同層；即使內容相似，也不能互相替代。欄位說明請參閱協定與欄位填寫說明。

從分享連結匯入後，也應確認解析結果是否完整。如果原始資訊缺少傳輸參數，匯入成功不代表設定可用；請向原資訊提供者確認，不要照著其他項目的設定猜填。手動修改由訂閱產生的項目前，先複製一份，否則後續更新可能覆蓋變更，導致問題再次出現。記錄修改依據，例如「與既有伺服器說明核對後修正 Path」，會比只寫「換了一個參數」更方便追蹤。

透過實際使用確認，不要連續大量測試

選擇參數已確認的項目，測試一次並造訪實際需要的網站。如果仍然失敗，保存錯誤摘要與網路條件，間隔一段時間後再測；連續大量測試可能增加請求負擔，也不利於觀察偶發故障。如果只有某個伺服器項目持續失敗，請整理錯誤類型、發生時間與已做過的對照，再向你的服務供應商確認服務狀態。提交前移除身分欄位、金鑰與完整訂閱網址；排查所需的是現象與參數類別，而非公開憑證。

如果交握成功，但大型頁面或上傳工作失敗，請轉到速度章節檢查持續傳輸、封包遺失與 MTU 相關因素，不要把所有問題都稱作節點逾時。明確判斷故障發生在哪個階段，才能選擇相應的修復步驟。

訂閱更新失敗、匯入後清單空白或項目重複

訂閱處理至少包含取得網址、向伺服器發出請求、接收內容、解析格式及寫入本機清單等階段。更新失敗不一定代表現有項目失效；舊項目可能仍可連線，出錯的只是更新請求。先記錄原有項目的數量與名稱範圍，保存可還原的副本，再更新一次並查看提示。訂閱請向你的服務供應商取得；不要以來源不明的網址取代原訂閱，也不要將用於驗證的完整連結貼到公開討論區。

確認匯入內容與入口是否相符

單一節點分享連結、伺服器清單訂閱與完整設定檔是不同類型的內容。前者描述一個項目，清單訂閱用於持續取得一組項目，設定檔則可能包含規則與 DNS。將網頁網址或設定檔網址填入不相符的入口，可能出現「請求成功，但沒有可辨識項目」的結果。先查看原提供者對格式與入口的說明，再依照入門指南操作。需要辨別分享連結結構時，可參閱分享連結與訂閱連結的差異。

複製網址時，確認是否只複製到畫面上顯示的標題、漏掉問號後的參數，或因通訊 App 插入換行而截斷。網址中的大小寫與編碼字元不要任意修改，尤其不要將半形符號換成中文標點。需要重新取得連結時，請向原服務供應商索取並確認用途。訂閱網址通常含有存取憑證，系統剪貼簿、截圖與瀏覽記錄也可能留存網址；診斷結束後，妥善清除不再需要的副本，不要在不同 App 間反覆轉傳。

區分網路錯誤、回應錯誤與解析錯誤

請求逾時時，先檢查訂閱網域解析及目前網路是否可連線；憑證錯誤應確認裝置時間、網域與憑證狀態；明確的 HTTP 狀態碼則表示請求已到達一定階段。401 或 403 通常與身分、權限或存取限制有關，但具體原因仍需由伺服器端確認；404 可能表示路徑已變更或網址不完整；429 表示請求可能受到頻率限制，此時應停止連續重新整理，並依回應內容等待。不要反覆點按，以免掩蓋最初出現的有效錯誤訊息。

如果收到登入頁、說明頁或網路認證頁面，客戶端可能取得的是 HTML，而不是預期的訂閱內容。這說明了為何「瀏覽器能開啟」不等於「可作為訂閱解析」。如果原服務提供受保護內容的檢查方式，請依其說明確認回應類型；不要將訂閱憑證交給陌生的線上轉換頁面。有些訂閱提供客戶端格式選項，請確認選用 Shadowrocket 可識別的格式，不要只憑網址後綴推斷。

處理重複項目與更新後的變更

遇到重複項目時，先判斷是「同一訂閱新增多次」還是「伺服器端內容名稱重複」。前者可在確認備份與歸屬後保留一個來源；後者應比對地址、連接埠與協定，不能只看名稱就刪除。訂閱更新也可能移除舊項目或修改名稱，導致原先的選擇改變。更新完成後返回 Home，確認目前選取的項目仍存在且參數完整，再進行實際連線。清單出現新名稱，不代表更新一定完全正常。

如果本機個別項目經過手動調整，更新前應複製為獨立項目並標明用途。長期維護時，分開管理訂閱產生的內容與個人修訂內容，可減少變更遭覆蓋而反覆出錯。如果只有更新請求失敗、舊項目仍可使用，可先維持目前可用狀態，記錄錯誤與回應時間，再向你的服務供應商確認。驗收修復時，應確認更新完成、項目可辨識、目前選取正確且實際連線成功，而不只是錯誤提示消失。

連線正常，但速度緩慢或傳輸不穩定

先把「慢」描述成可重現的現象：首次開啟時等待很久、頁面開始載入後持續緩慢、影片播放中斷，還是大型檔案上傳停滯。首次等待較可能與解析及交握有關；持續傳輸則還會受到接取網路、伺服器負載、目標服務、封包遺失及傳輸方式影響。低延遲不代表高吞吐量，短連線測試也無法預測長時間傳輸表現。不要只憑某次 Connectivity Test 的排序，就認定某個伺服器在所有使用情境下都比較快。

在相同條件下進行對照

選擇內容與大小相對穩定、可合法測試的目標，在同一裝置、同一接取網路及相近時段進行對照。暫停其他大量資料傳輸工作，確認 Wi-Fi 訊號與行動數據狀態，再分別測試基礎網路與目前的代理路徑。記錄開始等待時間、持續載入情況及是否中斷，不要只記一個平均數值。測試本身會使用流量，也可能改變伺服器負載；測到足以重現問題即可，不必長時間執行大量並行工作。

如果所有網站都很慢，先檢查接取網路與所選伺服器；如果只有一項服務很慢，則應檢查該服務的資源網域、分流路徑與伺服器回應。有些頁面的正文載入很快，圖片或影片卻很慢，代表不同資源可能使用不同網域與路徑。搭配請求紀錄找出耗時環節，並在 Config 下確認規則；直接用另一份複雜設定取代整個設定檔，會同時改變 DNS、規則及其他處理，反而失去可比較的基準。

檢查交握、重複連線與傳輸限制

頻繁中斷並重新連線會使 TLS 或其他協定反覆交握，短請求尤其容易因此載入緩慢。觀察速度變慢時是否同時出現逾時、連線關閉或網路切換；如果只在電梯、移動途中或訊號微弱的 Wi-Fi 下發生，應先改善接取條件。若換到穩定網路後恢復，就不應優先修改規則。對依賴 UDP 的傳輸，請確認目前網路支援所需的通訊方式；一般網頁能開啟，不代表 UDP 路徑品質良好。

小型頁面正常，但大型傳輸停頓，可能與封包遺失、路徑 MTU 或伺服器端限制有關，單憑現象無法確定原因。不要在多個位置任意填入不同 MTU 值；只有目前協定明確提供相關設定，且有原伺服器說明或可重現的證據時，才在副本中調整一項並進行對照。對 WireGuard 等設定，也應確認允許的地址範圍與實際路由。若要還原預設值或原始參數，應先留下紀錄，避免暫時測試值一直保留。

排除設定處理造成的額外等待

複雜規則、遠端資源或請求改寫可能增加處理步驟，但不代表所有功能都有問題。先複製目前的設定檔，在副本中只停用最近新增的一組處理，再測試相同的使用情境；若有改善，再逐項縮小範圍。涉及 HTTPS 檢查或改寫的設定會改變處理方式，操作前應先了解用途與憑證驗證界線，不要為了追求速度而擴大處理範圍。完整設定檔的區段用途請參閱設定檔區段說明。

也要確認規則是否將原本需要區域網路存取的服務交給代理，或將依賴特定路徑的資源改走直連。區域網路列印、檔案存取與一般網站的診斷方式不能混為一談。針對已確認的目標修正规則後，應返回原本的 Global Routing 進行驗證；長期停留在 Proxy 可能只是繞過規則問題，並未真正修復設定。設定副本的用途是隔離變因，不是讓多份未整理的檔案同時承擔不同的隱含用途。

最後應以實際工作驗收，例如完成一次頁面載入、連續播放一段內容或完成上傳，並確認原本的停頓是否再次出現。如果只有特定時段變慢，記下時段、接取網路與錯誤摘要，向你的服務供應商確認服務狀況。不要把偶爾一次較快的結果當作修復完成，也不要把目標網站本身的限速歸因於客戶端設定。

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

DNS 會將網域轉換成可連線的地址；伺服器連線、規則判斷與目標存取都可能依賴 DNS。常見現象包括伺服器網域無法解析、網頁顯示找不到地址、部分資源未載入，以及 Connectivity Test 有結果但實際網頁無法開啟。先確認失敗的是伺服器網域還是目標網站網域，兩者發生在不同階段。前者可能導致代理連線根本無法建立；後者則可能發生在工作階段已建立之後，不應一概用同一項設定處理。

先檢查目前生效的解析來源

在 Config 中確認目前使用的檔案，再查看其中的 [General] 區段與相關 DNS 設定。系統 DNS、設定檔中的 DNS 與加密 DNS 設定可能共同影響不同請求；不能只因某一行寫了 system，就推斷所有解析都只走同一條路徑。先記錄原值，閱讀該項在目前 App 中的說明，再單獨進行對照。以下片段只示範鍵值語法，不是適用於所有網路的建議設定，也不應用來覆蓋使用者的完整檔案。

[General]
bypass-system = true
dns-server = system
ipv6 = false

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

如果問題是在更換 DNS 後出現，先在設定副本中還原原本可用的設定，再重新連線並發起新請求。瀏覽器、系統與 App 都可能快取結果，因此舊頁面繼續失敗或舊連線仍然成功，不一定代表變更未生效。請關閉既有請求後重新造訪，必要時重新啟動受影響的 App；不要把清除裝置所有設定當作一般的清除快取步驟。每次只調整解析來源或一項相關選項，並保留還原方式。

區分逾時、查無紀錄與地址連通性

解析逾時表示未能及時收到回應，應檢查 DNS 服務的存取路徑；明確查無對應紀錄時，則要確認網域拼寫、紀錄類型與目標服務狀況。解析已回傳地址，但連線至該地址時逾時，問題可能在路由或目標服務，而不是繼續更換 DNS 就能修復。使用加密 DNS 時，也要考慮其服務地址如何解析與連線，以及是否需要先經過尚未建立的代理路徑，避免形成啟動依賴循環。

如果只有啟用 IPv6 後才出現問題，請確認目前網路是否有可用的 IPv6 路徑，以及目標回傳的地址是否與實際路由相符。可在副本中暫時關閉 IPv6 進行對照，但不能據此認定所有網路都應關閉 IPv6；還原後仍須測試實際服務。如果網路依賴特定地址轉換機制，直接連線數字地址或只測試一種地址族可能造成誤判。描述成「某網路下的某地址族連線失敗」，會比籠統寫「DNS 有問題」更精確。

檢查本機對應與規則之間的關聯

[Host] 中的本機對應可能覆蓋正常解析結果；舊地址失效後，就會出現只有特定網域一直無法開啟的情況。搜尋設定檔中該網域的對應項目與相關規則，確認沒有留下過去測試的內容；刪除前先保存副本，並記下原本用途。網域規則與 IP 規則也有先後順序：有些 IP 判斷需要先取得解析結果。如果網域已符合前面的規則，後面的 GEOIP 或 IP-CIDR 就不會再作為同一請求的一般後續規則繼續比對。

不要將網站暫時解析出的地址直接長期寫入 [Host]。使用內容傳遞或動態地址的服務可能會依網路與時間回傳不同結果，固定地址可能破壞調度，甚至造成憑證、資源或連線問題。同樣地，直接用 IP 開啟 HTTPS 網站並不是可靠的等效測試，因為憑證名稱與伺服器虛擬主機選擇仍可能依賴網域。測試紀錄應說明實際驗證的是解析、連接埠連線，還是完整業務存取。

修復後，分別測試伺服器網域、先前無法開啟的網站及其附屬資源，再恢復 Config 下的日常使用模式。如果故障只出現在某個 Wi-Fi 網路，也應檢查路由器 DNS 與網路認證狀態。更多定位範例請參閱DNS 解析失敗排查；紀錄中保留網域類別、解析錯誤與符合的策略即可，不應公開完整請求網址中的敏感參數。

耗電增加、裝置發熱或背景活動異常

系統電池頁面顯示 Shadowrocket 活動量較高，不一定表示耗電都來自客戶端的某項功能。VPN 會承接其他 App 的網路流量，系統統計也會受到前景使用、背景通訊與連線時間影響。先比較相同裝置、相近時段與類似工作，記錄螢幕使用情況、接取網路、充電狀態及正在傳輸的內容。直接比較播放影片時與裝置閒置時的統計，無法定位額外耗電的來源。

先建立可比較的觀察時段

等裝置電量與溫度相對穩定後，選擇一段正常使用時間觀察，再查看系統電池與流量統計。不必追求固定的耗電百分比，重點是相同類型的工作之間是否出現明顯變化。先暫停大型檔案同步、長時間播放影片、個人熱點分享等已知高流量工作，並確認沒有同時進行系統更新或照片處理等活動。觀察時盡量使用相同網路；弱行動網路訊號造成的無線通訊耗能，可能比規則處理更值得優先檢查。

如果連線開關頻繁變化，或請求紀錄持續出現失敗重試，應先修復連線問題。重新連線、重新解析及反覆交握都會增加活動，讓背景持續運作。檢查是否有多個自動連線條件互相影響、On Demand 是否在網路切換後反覆觸發，以及裝置是否長時間處於訊號不穩的 Wi-Fi 邊緣範圍。暫時關閉自動連線進行對照時，應先記下原設定；診斷完成後依實際需求還原，不要忘在測試狀態。

檢查診斷工作與持續網路請求

大量執行 Connectivity Test、頻繁更新訂閱、記錄詳細請求及長時間除錯都會增加額外工作。排查結束後，停止不再需要的測試、恢復正常的記錄範圍，再觀察系統統計是否趨於穩定。不要同時執行多組測試來確認耗電情況，否則診斷過程本身就可能成為負載來源。日誌保留範圍應以排查所需為限；較長的紀錄也可能包含造訪網域與請求資訊，匯出或分享前請檢查敏感內容。

如果裝置閒置時仍持續有流量，先確認是否為其他 App 在背景同步。可在系統允許的設定範圍內逐項暫停相關背景工作，再比較流量變化；不要未經確認就一次關閉所有 App 權限。如果只有開啟某個 App 後才開始持續重試，請查看失敗資源與規則路徑，並參照無法上網及 DNS 章節定位。修復請求失敗比單純限制客戶端背景活動更接近問題根源，否則相關 App 仍可能不斷重新發出請求。

使用設定副本隔離額外處理

如果問題是在新增設定內容後立即出現，請複製目前檔案，在副本中只撤回最近新增的一組變更，例如新增改寫或更複雜的請求處理。保持伺服器、Global Routing 與業務操作相同，再比較發熱及活動情況。如果同時更換伺服器、DNS 與設定，即使結果改善，也無法判斷真正原因。不能只靠行數判斷設定是否複雜；應檢查哪些處理實際符合目前流量，以及是否持續觸發新請求或失敗重試。

對於特定協定，不應只憑名稱推斷它一定比較省電或耗電。接取網路品質、重傳、連線數量與業務類型都會影響結果。若要比較使用者現有的不同項目，應在相同工作中逐一測試，並確認每個項目都能穩定完成請求。若一條連線不斷失敗、另一條則正常，兩者的耗電差異首先反映的是可用性不同，而不是協定本身有固定結論。

驗收時回到日常使用條件，觀察是否仍有相同的異常背景活動，並確認停止臨時紀錄後網路功能仍正常。向服務支援說明問題時，提供系統電池頁面的時間範圍、主要使用工作、是否正在充電、網路類型與重新連線的情況。不要只提供一張百分比截圖；缺少使用條件的統計，無法可靠區分客戶端處理、其他 App 流量與無線網路耗能。

更新後異常與 iPad 專項排查

更新後首次發現故障，表示問題發生時間接近更新，但不能因此認定更新是唯一原因。App、系統、訂閱內容與接取網路都可能在同一時段改變。先記錄實際發生的變更：App 是否剛更新、系統是否重新啟動、訂閱是否自動重新整理、設定是否遭到取代，再重現相同的失敗操作。更新紀錄與系統需求以 App Store 頁面標示為準，不要憑印象猜測某個特定版本造成了什麼行為。

保留舊設定，確認目前選取項目

先複製目前的設定檔與必要的個人項目資訊，並妥善保管其中的憑證。返回 Home 確認目前使用的伺服器，進入 Config 確認啟用的檔案，再核對 Global Routing 與 On Demand；清單中有項目，不代表目前選取內容與之前相同。訂閱更新造成項目更名、移除或參數變更，往往恰好與 App 更新同時發生。逐段比較本機副本與目前內容，比直接重設所有設定更容易找出真正差異。

如果異常只出現在舊設定中，請使用副本撤回最近的變更，或以已驗證的最少內容逐步還原。讀取設定時若出現明確錯誤，應先修正對應行的語法、區段與策略引用，不要忽略提示後繼續疊加其他設定。查看 App 內說明時保留英文設定用詞，避免因中文轉述而找不到正確選項。還原設定後仍需重新驗證實際請求；能開啟 Config 頁面，不代表每個欄位都適合目前的網路。

區分同一筆購買紀錄與相同的網路設定

iPad 請使用購買時的 Apple ID，在 App Store 查詢已購狀態；相關復原步驟請參閱iPad 取得說明與已購項目復原。購買紀錄決定 App 的取得資格，不代表所有本機伺服器、訂閱與設定都會自動復原。如果 App 提供匯入或同步入口，請確認來源、內容與目前生效的檔案；不要因為裝置上已顯示 App 名稱，就認定兩台裝置的網路設定完全相同。

比較 iPhone 與 iPad 時，先讓兩台裝置使用同一個 Wi-Fi、同一個現有伺服器及相當的設定，再造訪相同目標。如果一台使用行動網路、另一台使用 Wi-Fi，測試結果首先反映的是網路路徑差異。也要確認 iPad 是否連接鍵盤、擴充基座或乙太網路配件，以及系統是否使用不同的網路服務。配件改變接取路徑後，DNS、區域網路存取與 On Demand 條件都可能與原本的 Wi-Fi 環境不同。

檢查分割畫面操作、休眠與區域網路存取

iPad 的分割畫面或較寬的版面可能同時顯示清單與詳細內容。編輯某個檔案不一定代表已將它設為目前使用的設定；查看某台伺服器也不代表連線時選中了它。操作後返回 Home 和 Config，確認實際選取項目。使用多工切換時，也要區分「App 視窗重新顯示」與「連線重新建立」；應綜合開關狀態、系統狀態及請求結果判斷連線，而不是只看視窗是否仍在前景。

如果只有從休眠喚醒後才失敗，請記錄喚醒前後的網路、是否經過登入認證及 On Demand 狀態。先手動連線確認是否恢復，再觀察自動連線是否在相同條件下觸發。區域網路檔案、列印或裝置探索失敗時，請檢查系統是否已授權相關存取，以及目標是否仍在同一個網段；部分探索機制依賴多點傳送，一般網站能開啟不代表區域網路探索正常。不要為了處理單一區域網路目標而刪除所有分流規則。

重新安裝應留到已完成備份、設定比對且確有必要時再進行。這可能會清除本機內容，但無法替你修正伺服器端參數或訂閱權限。需要取得 App 時，請僅透過 App Store；確認正版時，可核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。處理完成後，分別測試手動連線、鎖定螢幕後喚醒、網路切換及先前失敗的特定工作；將有效步驟整理成簡短結論，並保留其他設定不變，才能作為後續可靠的重現基準。