Shadowrocket 疑難排解指南

01 / 系統連線層

開關無法啟用：先檢查 VPN 設定與系統限制

開啟開關後立即跳回、一直停在連線中，以及系統未顯示預期的授權提示，是三種不同狀況。若開關立即跳回，優先確認系統是否接受 VPN 設定；若停在連線中，則需搭配錯誤記錄判斷是否已開始連接伺服器；若沒有提示，可能是先前已授權，也可能受到裝置管理政策限制。先記下觸發後的狀況，不要快速連續切換開關；反覆嘗試會混淆前一次失敗與後續重新連線的記錄，也無法取代權限檢查。

區分首次授權與既有設定

首次從 Home 開啟連線時，系統可能會要求新增 VPN 設定。請確認操作是由剛開啟的 Shadowrocket 發起，再依照系統提示允許，並完成裝置要求的身分驗證。這項授權會讓用戶端建立系統網路通道，不代表伺服器資料有效，也不表示 App 購買包含連線服務。若取消授權，請返回 App 重新發起連線；不要為了再次顯示提示而先刪除其他網路設定。權限正常但仍無法連線時，請接著檢查本章後續的設定與網路狀態。

曾使用過的裝置，可在系統設定中搜尋 VPN，確認是否存在對應設定，以及目前由哪個設定建立連線。系統設定中的分類位置可能因系統版本而異，建議直接搜尋，不要依循固定路徑。若另一個 VPN 正在運作，請先停止，再單獨測試 Shadowrocket；工作或學校管理的設定，請勿自行移除。裝置管理、內容過濾與網路延伸功能可能共同影響連線，若限制來自管理政策，請向裝置管理員確認。

依序排除連線衝突

先關閉 Shadowrocket 的連線，暫時停用 On Demand，再確認系統是否自動啟用了其他 VPN。接著離開目前的設定頁面，返回 Home，確認實際選取的 SERVER 仍是預期項目，再重新連線一次。若開關能維持開啟但網頁無法載入，表示問題已轉到存取層，請前往下一章；若開關立即跳回，請查看故障時間附近的錯誤訊息，分辨是權限遭拒、建立設定失敗，還是伺服器交握失敗，不要只依開關顏色判斷原因。

若系統設定明顯殘留異常，請先保存 App 內的伺服器與設定檔，再關閉連線及自動觸發條件。只移除能確認屬於 Shadowrocket 的 VPN 設定，然後返回 App 重新觸發系統授權。移除系統 VPN 設定與刪除 App 內的設定並非同一操作：前者會重建系統連線入口，後者可能會遺失規則與參數。若裝置受管理，遇到無法刪除或新增的提示時，請停止反覆操作，先確認管理規範。

網路尚未就緒時，別急著重新安裝

若使用需要登入網頁的 Wi-Fi，請先中斷 VPN，完成網路登入，並確認一般網頁可以正常存取，再嘗試連線。顯示已連線不代表已取得可用的網路出口；路由器未分配 IP 位址、登入狀態已過期，或目前網路限制存取，都可能讓連線程序停住。換用另一個自己能使用的網路再次測試；若只有原網路失敗，請保留目前的 App 設定，繼續檢查該網路；若所有網路都失敗，再檢查系統權限、伺服器參數與裝置時間。

本章的檢查完成後，系統應已接受 VPN 設定；連線操作應產生可辨識的結果，且能區分「通道尚未建立」與「通道建立後無法存取」。如需重新確認 App 來源、系統要求或已購項目還原方式，請參閱正版核驗說明；系統要求以 App Store 頁面標示為準。首次開啟各區塊的用途可參閱Home 與 VPN 設定授權說明，避免將系統授權問題誤判為訂閱故障。

02 / 存取與分流層

已連線卻無法上網：透過三種模式縮小範圍

顯示已連線，只代表系統通道已建立，不能證明網域解析、伺服器轉送與目標網站都正常。先中斷連線，開啟平常可正常存取的網站，確認底層網路可用；再連線並存取同一網址，記錄前後差異。若中斷連線後也無法存取，請先處理目前網路或目標網站，不要只在規則檔中尋找原因。若只有某個 App 或網站出問題，請記下具體網域、錯誤訊息與操作步驟，避免把局部問題描述成全面斷網。

先了解 Global Routing 的檢查用途

在 Home 查看 Global Routing。設定模式 Config 會依目前生效的設定處理流量；代理模式 Proxy 與直連模式 Direct 可用來建立對照。模式名稱與規則中的 PROXY、DIRECT 關鍵字相關，但兩者並非同一個設定位置。診斷時先固定網路與選取的伺服器，再依序切換模式，每次重新存取目標。這裡只比較測試結果，不要將暫時測試模式留作日常設定；涉及本機位址、特殊規則或系統流量時，還需搭配實際記錄判斷。

若 Proxy 可以存取、Config 卻不行，表示所選伺服器有可用路徑可連到該目標，應優先確認目前設定是否將該目標交由 DIRECT、REJECT 或其他策略處理。反之，若 Direct 正常而 Proxy 失敗，請優先檢查所選伺服器的參數、狀態與出口路徑。三種模式都失敗時，先確認測試目標本身可用，再檢查 DNS 與目前網路。單次成功無法證明所有流量正常，單次失敗也不能證明某類規則一定有誤，需搭配存取記錄與重複測試判斷。

檢查目前生效的設定，而不只看編輯內容

進入 Config，確認目前實際使用的是剛才檢查的設定檔。編輯了一個檔案，卻仍啟用另一個檔案，是「規則寫對卻沒有作用」的常見原因。保留原始檔案後，建立獨立的測試設定，先用少量規則驗證目標，再逐步加入原有規則。規則會依序比對，第一條符合的規則即生效；範圍較廣的規則若放在前面，後續的特定規則就不會有機會命中。檢查時也要確認比對類型、網域範圍、策略名稱與 FINAL 的位置。

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

上例用於說明規則結構：範例網域及其子網域交由 PROXY 處理，指定的私有網段使用 DIRECT，其餘請求由 FINAL 處理。這不是適用所有網路的完整設定，也無法取代既有設定中的 DNS 與其他參數。測試實際故障時，應將目標網域換成自己要檢查的網域，並先確認伺服器可用。若原本使用策略群組，尚未確認群組定義前不要直接更名，以免將規則問題變成策略參照問題。

透過一筆存取記錄完成查核

重新開啟目標頁面，查看 App 提供的連線或診斷記錄，找出相同時間的請求，確認實際網域、命中規則、策略與錯誤訊息。一個頁面可能會連線登入、圖片、介面等多個網域；若首頁能顯示但登入失敗，通常需要檢查第二個請求，而不只是新增首頁網域。確認後還原正常的 Config，並關閉暫時測試設定。模式說明請參閱Global Routing 三種模式說明；規則範圍請參閱規則類型詳解。

若存取記錄顯示請求已依預期策略送出，但目標仍回傳拒絕或登入錯誤，請進一步檢查目標帳戶、瀏覽器工作階段與伺服器出口條件。不要一味擴大代理規則來處理所有網站服務錯誤；先保存明確證據，再決定是否前往伺服器逾時或 DNS 章節。

03 / 伺服器與協定層

伺服器逾時：分開檢查位址、交握與轉送

Connectivity Test 顯示逾時，不代表已確認伺服器停止運作。測試方式、目標、目前網路與伺服器設定都會影響結果。先查看使用的測試方式，再核對實際網頁存取情況；連接埠可連通，不代表協定驗證成功；測試目標有回應，也不代表所有網站都能存取。將測試結果視為線索，不要把單一數值或逾時標籤當成完整結論。固定使用同一台伺服器、同一個網路與同一個測試目標，才有可比較的基準。

先確認伺服器資訊完整且一致

開啟目前 SERVER 項目的編輯資訊，逐項核對使用者自己的伺服器資料。位址、連接埠、協定類型、驗證欄位與傳輸設定必須彼此相符。手動複製時，請留意前後空格、漏字與換行，不要將說明文字一併貼入欄位。若伺服器位址使用網域名稱，也要確認該網域可解析；填入位址後仍無法連線，也不能因此跳過憑證與伺服器名稱檢查。不要因為某個欄位「看起來相似」就認定已核對完成。

依錯誤階段判斷下一步

若記錄顯示網域解析失敗，請先前往 DNS 章節；若連線遭拒，表示目標路徑與單純等待逾時不同，應確認位址、連接埠及伺服器端的監聽狀態；若連線建立後出現驗證錯誤，則應優先核對密碼或身分資訊。TLS 相關錯誤也需檢查裝置日期與時間、伺服器名稱及憑證狀態。錯誤文字可能因協定而異，回報時保留原文會比只寫「連不上」更有幫助；同時請遮蔽其中可能包含的私密欄位。

使用 TLS 的連線中，連線位址、伺服器名稱與傳輸層的 Host 不一定相同，應依現有伺服器資料填寫，不可為了減少欄位而全部改成同一個值。使用 WebSocket 等傳輸方式時，還需核對路徑、大小寫與相關要求標頭設定。路徑只差一個字元，也可能連上正確主機，卻無法進入預期服務。不要透過關閉憑證驗證來掩蓋名稱錯誤；這麼做既無法釐清根因，也會改變正常的驗證界線。

透過不同網路的對照，區分用戶端與路徑問題

保留同一份伺服器設定，分別在兩個自己可用的網路上測試。若一個正常、另一個持續逾時，請優先檢查原網路的出口限制、登入狀態及對該協定傳輸方式的支援；若兩個網路都失敗，再比較同一訂閱中自己原有的其他項目。只有某個項目失敗時，問題較可能出在該伺服器或其設定；所有項目同時失敗時，則需繼續確認訂閱是否整體變更、驗證資訊是否失效，以及裝置共用設定是否被修改。

不要連續修改連接埠、協定與驗證欄位碰運氣。若伺服器資料由自己使用的服務提供者管理，請提供測試時間、網路類型、錯誤階段與已遮蔽的設定差異，詢問該項目目前的要求是否有變。若伺服器由自己管理，請檢查對應時間的伺服器端記錄，確認是否收到連線、是否接受驗證，以及後續請求是否送出。用戶端未收到回應與伺服器明確拒絕驗證，是兩種不同的處理方向。

調整完成後儲存項目，重新選取並建立新連線，避免繼續觀察舊連線的結果。確認可穩定存取後，再還原日常自動觸發與規則設定；協定欄位的意義可參閱術語手冊。

04 / Subscribe 資料層

訂閱失敗：先區分取得失敗與內容無法匯入

Subscribe 更新失敗時，先保留目前仍可使用的項目，不要立刻刪除整份訂閱。訂閱更新包含取得網址、接收回應、解析內容與更新項目等階段；任何一個階段失敗，最後都可能顯示更新不成功。先記下具體提示與更新時間，再確認舊項目是否仍可連線。若更新失敗但舊項目仍可用，通常應優先檢查訂閱取得路徑或內容，而不是先修改所有伺服器參數。

核對網址來源與完整性

訂閱網址應來自使用者自己的服務資料；複製時請保留完整查詢參數，並檢查是否混入空格、引號、換行或說明文字。有些服務會同時提供管理頁面、說明頁面與訂閱網址，可在瀏覽器開啟的頁面不一定是可匯入的訂閱內容。不要將登入頁面網址當成 Subscribe 網址，也不要因為連結很長就刪除末尾參數。訂閱網址可能包含身分憑證，分享截圖或診斷記錄前，請遮蔽所有敏感內容。

若服務資料中的網址已變更，請先透過原有管理管道確認，再修改用戶端記錄；不要依賴轉傳訊息中的舊網址。用瀏覽器存取可協助確認是否出現登入頁面、錯誤頁面或重新導向，但瀏覽器與 App 的請求環境可能不同，因此瀏覽器能開啟，不代表 App 一定能匯入。尤其瀏覽器已有登入狀態時，顯示的內容可能依賴工作階段；訂閱請求需要的是能獨立取得且格式受支援的資料。

依回應結果選擇排查方向

若能查看 HTTP 狀態，遇到驗證相關錯誤時，先核對訂閱憑證與帳戶狀態；資源不存在時，檢查路徑是否已變更；請求過於頻繁時，停止連續更新並依服務要求等待；伺服器錯誤則需由訂閱管理方確認。連線逾時不屬於內容格式錯誤，應先檢查目前網路與訂閱網域的解析。每次重新測試都應使用相同網址，避免同時更換網路與連結，導致結果無法判讀。

若提示較像解析失敗，請確認回傳內容究竟是協定項目、設定檔，還是網頁文字。訂閱與 Config 中使用的完整設定檔不是同一種資料，不能只因兩者都以連結呈現，就放進同一個入口。部分項目可能包含 App 目前不支援的欄位組合；若少數項目匯入成功、少數失敗，應針對失敗項目的協定與參數進行核對，不要因此認定整個網址都無效。實際支援範圍以目前 App 說明為準。

保留舊項目，避免更新時失去連線依賴

有時必須透過目前已有的連線路徑才能取得訂閱網址。若先刪除所有伺服器再更新訂閱，可能會失去原本可用的取得條件。請先保存現有設定與可用項目，再確認更新請求確實經由預期路徑傳送；不要假設它一定使用剛才開啟網頁時的相同連線。若目前選取的伺服器已失效，只在自己原有的可用項目與可用網路之間交叉測試，不要使用來源不明的資料繞過排查。

更新成功後，檢查項目數量變化只是初步步驟；還需確認目前選取的項目是否仍存在、關鍵參數是否被覆寫，以及重複名稱是否導致選錯項目。若手動調整過項目，請確認下次訂閱更新是否會重寫欄位，必要時保留獨立副本以供比較。不要將「更新完成」等同於「伺服器可連線」；取得資料與實際連線至伺服器，必須分別驗證。

本章結束時，應能確認問題屬於網址錯誤、取得路徑失敗、回應異常，還是格式不符。匯入入口的基本步驟請參閱快速入門教學；若匯入的是規則設定，可繼續閱讀設定檔各區段說明，不要混用伺服器訂閱與規則檔。復原後，只執行一次必要的更新與連線驗證，避免頻繁重新整理而增加其他限制因素。

05 / 效能與路徑層

速度慢：區分首頁等待、持續傳輸與局部卡頓

「速度慢」至少包含三種情況：開啟頁面前等待很久、頁面開始載入後傳輸緩慢，以及只有特定 App 或網站卡頓。先描述慢在哪個階段，再選擇測試方式。首頁等待可能與 DNS、交握和重新導向有關；持續傳輸更受路徑容量與壅塞影響；局部卡頓則可能與特定網域、協定或目標服務有關。Connectivity Test 的回應時間只是特定測試的結果，不能直接代表持續下載能力，也不能取代實際服務驗證。

建立可重複的測試條件

先固定裝置、網路、伺服器、模式與測試目標，暫停大型同步、系統下載及其他持續傳輸工作，等目前請求結束後再重新測試。記下測試時間，以及當時是否處於低電量、分享熱點或訊號較弱的狀態。不要比較不同時間、不同目標的一次性結果，也不要同時執行多個速度測試；並行測試本身會佔用頻寬，讓原本正常的路徑看起來不穩定。短時間重複測試幾次、觀察趨勢，比追求單次最高結果更有參考價值。

在同一個網路下，先中斷連線觀察目標的直連狀況，再連線並以 Proxy 檢查伺服器路徑，最後使用 Config 確認日常分流。若 Proxy 正常、Config 卻很慢，請檢查目標的部分資源是否交由不同策略處理；若兩種模式都很慢，而其他既有伺服器正常，問題較可能出在目前的伺服器路徑。若所有方式都很慢，請優先檢查 Wi-Fi 訊號、網路壅塞與目標服務，不要一開始就大幅修改設定。

找出頁面中載入緩慢的請求

一個頁面可能同時請求文字、圖片、指令碼、影片與登入介面；主頁載入完成，不代表所有相依網域都正常。若圖片載入緩慢、登入畫面持續轉圈或播放開始後停頓，請查看同一時段的連線記錄，找出持續失敗或反覆重試的請求。只為首頁網域新增規則，可能無法涵蓋實際卡住的資源；反過來，為了省事而擴大到很廣的網域範圍，也可能改變原本正常的存取路徑。規則調整應以實際請求為依據。

若每次首次存取都很慢，之後明顯改善，請優先觀察解析、建立連線與快取因素；若長時間傳輸時週期性停頓，則可考慮網路切換、封包遺失、路徑壅塞或伺服器資源競爭。快取會影響比較結果，瀏覽器重新整理也可能繼續使用既有連線。重新測試時，盡量建立新的存取流程，並註明是否為首次請求。不必為了測試清除所有 App 資料，更不要把清除資料當成通用的加速方法。

調整協定與 MTU 前，先確認有明確依據

傳輸方式不是越複雜越快，協定是否合適取決於伺服器設定與目前網路條件。若懷疑某類傳輸受到限制，先比較自己已有且參數正確的項目，不要只在用戶端單方面更改協定名稱。MTU 等參數也不應照抄網路文章中的固定數值；只有在小型請求正常、大型請求停住，且重複交叉測試也支持這個判斷時，才進一步排查。調整前保留原始值，每次只修改一項，並以相同目標重新測試；若效果不明確，就還原設定。

目標服務也可能因登入狀態、資源類型或出口條件而呈現不同結果。若其他網站正常，只有某個目標持續緩慢，請分別檢查目標狀態與伺服器到目標的路徑，不能因此認定用戶端整體效能不足。裝置過熱、背景工作集中執行與弱訊號造成的重傳，也會影響使用者感受到的速度；先讓裝置恢復正常運作，再重新測試，避免將短暫的系統負載誤認為規則設定問題。

確認根因後，只保留能說明並改善問題的修改，刪除暫時測試規則，回到日常 Config 再檢查一次。只代理指定網站的設定方式請參閱指定網域分流說明；若問題出在解析階段，請接著閱讀下一章，不要以更換所有伺服器取代 DNS 排查。

06 / 名稱解析層

DNS 問題：區分伺服器網域與目標網域解析

DNS 故障不只有「所有網域都無法開啟」一種情況，也可能是伺服器位址無法解析、某個子網域失敗、首次開啟很慢，或切換網路後存取異常。先確認失敗發生在連接伺服器之前還是之後：伺服器網域解析失敗會阻止協定連線；目標網域解析失敗則可能發生在通道已建立之後。這兩個階段的路徑與依賴條件不一定相同，不能只修改一處 DNS 就認為已涵蓋所有問題。

透過錯誤記錄確認解析階段

依照故障時間，查看錯誤訊息中出現的是伺服器位址還是存取目標。若伺服器網域沒有取得可用結果，先確認底層網路正常，再核對網域拼寫、目前設定的解析方式與系統網路狀態。若伺服器已連線，只有特定目標失敗，請比較該網域在不同模式下的結果，並查看實際請求是否交由預期策略處理。成功解析網域只代表取得位址，不代表該位址對應的服務一定可連線，後續仍需單獨檢查連線狀況。

不要只用「直接輸入網站位址就能開啟」作為唯一驗證方式。許多網站會依賴網域選擇網站、驗證憑證與要求標頭；直接使用位址存取失敗，不代表網路不通；某個位址能回應，也不代表原網域解析正確。更可靠的方式是保留原網域，在相同目標與相同網路下比較解析及連線記錄。若 App 提供相關診斷資訊，請記錄結果類型、耗時與錯誤階段，不要只截取一個看似異常的位址。

檢查解析路徑是否形成相依迴圈

使用加密解析時，解析服務本身的網域也需要先解析並建立連線。如果解析路徑依賴尚未建立的代理，而代理伺服器的網域又依賴該解析服務，就可能形成相互等待。修改前，先釐清三個步驟：由誰解析伺服器網域、由誰連線至解析服務，以及由誰解析目標網域。優先還原至已驗證可用的解析設定，再逐項加入自訂設定；不要同時疊加多個解析服務，卻只憑感覺判斷哪個正在生效。

設定檔中的 DNS 參數、系統網路的解析設定，以及其他網路延伸功能，都可能共同影響結果。請先確認目前生效的 Config，再檢查是否有 [Host] 本機對應或其他覆寫項目。舊的本機對應會略過正常解析，將網域固定到已不適用的位址。若必須保留對應，請註明用途並定期複查；若來源不明，先保存副本，再單獨停用該對應進行測試，不要刪除整份設定檔。

[Host]
example.com = 192.0.2.10

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

以上為結構範例，文件中的範例位址不應作為實際存取目標。[Host] 會影響網域與位址的對應，網域規則與位址規則則決定後續分流。範例中的 no-resolve 用來避免因這條位址規則而主動觸發網域解析，不代表所有請求都不再使用 DNS，也不保證網域會在伺服器端解析。不要將這個選項當成通用 DNS 修復開關，應搭配目前的規則順序與實際連線路徑判斷。

留意雙堆疊網路與快取變化

同一個網域可能回傳不同類型的位址，而目前網路對這些位址的連線能力也可能不同。若某個網路正常、另一個失敗，請比對實際使用的位址類型與連線錯誤，不要直接關閉某類網路功能。若只有部分位址無法連線，問題可能出在路徑或伺服器端；修改解析只是改變所選位址，未必能排除根因。切換網路後短暫異常，也可能與舊快取或舊連線有關，請先結束受影響的請求，再建立新連線進行判斷。

復原驗證至少應包含伺服器連線、故障網域與一個原本正常的網域，以免修復局部問題時影響其他存取。記下是哪項解析設定或對應造成差異，再還原暫時測試項目。設定區段的作用請參閱[General]、[Rule] 與 [Host] 說明；若要了解網域規則與位址規則的適用範圍，請參閱術語手冊。解析結果中的位址與存取紀錄也可能涉及隱私，分享時僅保留診斷所需資訊即可。

07 / 執行狀態與變更層

耗電異常與更新後異常：依最近變更重新測試

耗電增加與更新後連線狀況改變，都應從時間軸開始排查。記下異常何時出現、此前修改了什麼、當時使用哪種網路，以及是否有持續傳輸。不要因為系統電量清單中出現 Shadowrocket，就認定耗電一定由某項設定造成；VPN 延伸功能會處理其他 App 的流量，系統歸屬方式與使用情境都會影響統計。請搭配螢幕使用時間、網路活動與可重複的交叉觀察，不要只比較時長不同的百分比。

耗電增加時，先檢查重試與持續活動

在相近的使用條件下，分別觀察連線穩定與故障重連期間的狀況。伺服器持續失敗、網路訊號較弱、頻繁切換網路，以及其他 App 不斷重試失敗的資源，都可能增加網路活動。先檢查是否有重複的連線錯誤，再找出反覆失敗的網域或背景請求。若某個 App 正在持續同步，先暫停其工作並觀察變化，比直接關閉所有規則更容易找出問題。不必耗盡電量才進行測試，重點是比較相近時段與相近負載。

確認 On Demand 是否符合預期，尤其留意網路條件改變後是否反覆觸發連線。暫時關閉自動觸發，手動建立穩定連線並觀察；若異常明顯減少，再逐項恢復觸發條件。On Demand 控制的是連線觸發，不等同於流量分流；修改它不能取代規則修復。若連線在中斷後總是重新開啟，請先確認是自動觸發，還是失敗後重連，不要只在系統設定與 App 之間反覆切換開關，卻未檢查觸發來源。

診斷期間保留足夠記錄即可，結束後請還原日常記錄設定，避免長時間保留不必要的詳細診斷資料。也要一併考慮裝置溫度、行動網路訊號、熱點分享與背景備份。若中斷連線後裝置仍持續發熱或耗電異常，請繼續檢查系統與其他 App。不要為了省電而犧牲憑證驗證、隨意修改協定參數或刪除系統設定；這些操作沒有建立耗電原因與改善結果之間的證據。

更新後出現異常，先確認實際變更範圍

App 更新、系統更新、訂閱更新與遠端設定更新可能在相近時間發生，但各自變更的內容不同。先確認是介面位置改變、某個項目失效、所有連線失敗，還是規則命中結果改變。查看 App Store 的 App 說明與更新記錄，並確認自己的訂閱和設定是否也在同一時期變更。App 與系統的相容性要求以 App Store 頁面標示為準，不應依據其他裝置的舊截圖推斷目前的裝置一定適用。

保留更新前可用設定的副本，並與目前內容比較協定參數、策略名稱、DNS、本機對應與規則順序。若同一份設定曾遭遠端更新覆寫，請先核實檔案內容，不要將所有變化都歸因於 App 本身。發現舊欄位已不適用時，依據目前 App 說明調整；不要為了恢復舊行為，一次加回多個不明參數。使用簡單的測試設定建立基準，有助於判斷問題來自設定，還是共用的執行環境。

復原時，先從可還原的操作開始

先關閉連線並重新開啟 App，再使用已核實的伺服器與最精簡設定進行測試；必要時保存記錄後重新啟動裝置。若只有原設定失敗，請逐段還原並找出觸發項目；若所有設定都失敗，則繼續檢查系統 VPN 狀態與網路條件。刪除 App 會影響本機資料，重新取得 App 也不代表原有伺服器與規則會自動還原，因此只有在完成備份、確認還原條件並排除其他原因後，才考慮此做法。購買項目還原說明請參閱已購項目與重新安裝指南。

確認復原後，再逐項開啟原本的 On Demand、日常設定與背景工作。若重新啟用某項功能後異常再次出現，請保留這項明確的觸發條件並繼續排查；若無法重現，應註明為暫時恢復，持續觀察，而不要宣稱已找出根因。

08 / 裝置與使用情境層

iPad 專項：交叉比對網路、設定與休眠後恢復

iPad 與 iPhone 的排查邏輯相同，但裝置所處網路、系統權限、App 版面與背景使用情境可能不同。不要因為一台裝置正常，就直接複製所有系統設定；也不要公開使用另一台裝置的訂閱憑證進行比較。請先確認兩台裝置使用的是同一份有效服務資料、相同目標與相近網路條件，再比對結果。App 購買範圍、相容性與系統要求以 App Store 頁面標示為準；取得入口說明請參閱iPad 下載與首次開啟。

排除「看似相同」的設定差異

逐項核對實際選取的 SERVER、Global Routing 模式與目前 Config。顯示名稱相同，不代表內容一致；舊訂閱項目可能仍使用相同名稱，卻採用不同位址或參數。比較時應檢查關鍵欄位與生效檔案，而非只看清單標題。iPad 較寬的版面可能同時顯示清單與編輯內容；儲存修改後，還需確認該項目確實已成為目前使用的設定。不要把編輯畫面中的選取狀態誤認為連線已切換。

每台裝置都需分別確認系統 VPN 授權；另一台裝置已允許，不代表本機也已授權。若 iPad 開關立即跳回，請依第一章檢查系統 VPN 設定、其他連線與裝置管理政策。學校或工作用途的 iPad 可能受到管理規範限制，若無法新增、修改或刪除設定，請先聯絡管理員確認。不要直接將受管理裝置與個人裝置的差異判定為用戶端故障，也不要自行移除管理項目。

分別測試 Wi-Fi 與熱點環境

只有 Wi-Fi 連線能力的裝置，可以改用自己可用的另一個 Wi-Fi 或個人熱點進行比較；熱點測試會改變底層網路路徑，不只是換一台裝置。兩台裝置即使連上同一台路由器，也可能使用不同頻段、隔離政策或登入狀態。先中斷 VPN，確認 iPad 已完成網路登入且一般網頁可正常存取，再啟用連線。若只有某個 Wi-Fi 失敗，請保留伺服器參數並轉而檢查該網路，不要先重建所有項目。

存取印表機、區域網路網頁或家庭裝置失敗時，應區分系統的本機網路權限與分流規則。若系統要求相關權限，請依實際用途檢查；規則則應將實際使用的本機網段交由合適路徑處理。不要假設所有路由器都使用相同的私有網段，請依目前網路資訊確認位址範圍。使用網域名稱的本機服務，也可能依賴區域網路解析與裝置探索機制；外部 DNS 回傳的結果不一定適用於本機存取，不能只靠新增一條範圍很廣的規則處理。

[Rule]
DOMAIN,localhost,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

以上片段用來說明私有位址範圍與預設策略之間的關係，不代表應直接覆寫至日常設定中。使用前請核對目前網路、既有策略，以及遠端服務是否也使用私有位址；若有需要透過代理存取的私有網路，一律直連可能會破壞該使用情境。具體規則應放在範圍較廣的規則之前，並透過一次實際的本機存取確認命中結果。關於首條命中與 FINAL 的意義，可回頭參閱規則類型說明。

裝置喚醒後，只檢查新增的變化

若鎖定螢幕前連線正常、喚醒後卻異常，請先記下喚醒時網路是否已改變，再查看 On Demand 與連線記錄。系統從休眠恢復後，舊連線可能已失效；開啟新頁面進行驗證，比繼續等待原頁面更可靠。多工視窗中的某個 App 停住，不代表所有網路都失敗；先比較同一台裝置上的其他存取，再決定是否重建連線。不要把反覆從最近使用項目中移除 App，當成維持背景連線的固定步驟。

完成排查後，應能明確判斷問題屬於本機授權、設定差異、特定網路限制、區域網路分流，或休眠後的連線恢復。若仍需協助，請整理兩台裝置的比較條件與已遮蔽的錯誤記錄，避免傳送整份訂閱。恢復日常使用後，請返回教學主流程，重新完成一次連線與分流驗證；功能範圍與 On Demand 用途可參閱功能介紹。保留已驗證可用的設定副本，下次遇到異常時即可從相同基準開始。