Shadowrocket 故障排除指南

連線開關無法開啟或自動關閉

先判斷開關停在哪個階段

點選連線後毫無反應、短暫開啟後關閉，以及開啟後反覆重新連線，是不同的現象。先停留在 Home，觀察操作後是否出現系統授權提示，再前往系統設定查看 VPN 狀態。系統授權僅代表允許建立連線所需的設定，不代表伺服器已通過驗證，也不代表已成功連上目標。若提示仍顯示在畫面上，請先閱讀並完成確認；不要在提示後方反覆點選 App 開關，以免將等待授權誤判為連線停滯。

首次連線需要允許新增 VPN 設定，也可能要求輸入裝置密碼或進行系統身分驗證。若先前取消授權，可返回 App 再次發起連線。系統設定中的入口名稱可能因系統版本而異，可搜尋 VPN 查看設定。只檢查能確認屬於 Shadowrocket 的項目，不要任意刪除單位、學校或裝置管理要求保留的設定。若受管理裝置禁止新增 VPN，請洽裝置管理員確認；修改伺服器參數無法解除系統策略限制。

分開檢查本機網路與連線設定

先關閉連線，用瀏覽器開啟平常能正常瀏覽的頁面，確認 Wi-Fi 或行動網路本身可用。公共 Wi-Fi 可能需要先登入網頁完成認證；此時即使圖示顯示已連線，也不代表已能存取網際網路。完成網路認證後再連線。若基礎網路也無法使用，先處理訊號、網路帳戶狀態或路由器連線，不要同時更換 Config。改用另一個可用網路再測一次，可判斷問題是否只發生在目前的網路環境。

確認基礎網路正常後，檢查 Home 是否確實選取一部伺服器，而不只是訂閱群組名稱。開啟所選項目，對照既有服務提供者提供的協定、位址、連接埠與驗證資訊。先備份目前的 Config，再以已知可用的設定進行比對。若啟用某份設定後連線立即中斷，而其他設定能維持連線，應優先檢查該設定的語法與引用關係。不要直接覆蓋唯一副本，以免失去問題發生時的狀況與還原依據。

處理自動連線與重複啟動

若開關剛關閉又重新開啟，請檢查 On Demand 是否已啟用，以及目前網路是否符合其連線條件。排查期間可暫時關閉 On Demand，再手動測試，避免自動規則改變連線狀態。裝置上其他使用 VPN 設定的功能也可能影響目前連線；暫停可確認且允許暫停的相關功能後再測一次。觀察結果時，記下觸發狀態變化的動作，例如切換 Wi-Fi、鎖定螢幕或返回前景，不要只記錄「偶爾斷線」。

若開關短暫開啟後立即關閉，請留意 App 顯示的錯誤訊息或連線記錄。設定解析失敗、必要欄位缺漏、擴充功能啟動中斷及遠端逾時，需要採取不同處理方式。可先停止連線，返回主畫面後重新開啟 App，再進行一次可控測試；仍無法恢復時，再重新啟動裝置。重新啟動可清除暫時性的系統狀態，但無法修正錯誤密碼、無效伺服器位址或設定語法。恢復後也應重做原本的操作，確認問題並非只是暫時消失。

開關已開啟，但無法上網

建立可重複的存取對照測試

開關已開啟只表示本機連線正在執行，不能據此判定遠端伺服器、DNS 與規則都正常。先選擇兩個平常可存取、用途不同的目標，分別記錄是整個頁面無法開啟、只有圖片載入失敗，還是某個 App 無法連線。關閉連線後再存取相同目標，作為基礎網路對照。若關閉後仍失敗，應先排除目標網站故障、網路登入狀態與裝置網路問題，不要繼續在代理規則中尋找不存在的原因。

測試時盡量使用相同瀏覽器、相同頁面與相近時間，避免把快取命中誤當成問題已排除。必要時重新載入頁面，或改用先前未開啟過的一般網頁。不要只因某個 App 首頁能顯示內容，就判定網路正常；它可能讀取的是本機快取。若瀏覽器正常、只有單一 App 異常，也要檢查該 App 是否獲准使用行動網路、是否正在執行背景工作，以及是否需要重新建立登入連線；暫時不要將問題擴大判定為整台裝置的網路故障。

透過 Global Routing 區分規則與連線通道

檢查 Global Routing 目前採用 Config、Proxy 還是 Direct；對應介面用詞為 Config、Proxy、Direct。診斷時只暫時切換模式，並記下原本設定。Direct 用來觀察基礎網路路徑，Proxy 用來測試經目前伺服器的連線，Config 則依目前設定比對規則。這些不是三種伺服器，也不是速度等級。Proxy 模式可用來排除規則問題，但不代表所有目標都適合長期透過同一部伺服器存取。

若 Proxy 正常但 Config 失敗，請檢查目標是否被分配至 DIRECT、REJECT 或無法使用的策略群組。閱讀設定時，由前往後尋找符合項目，特別留意範圍過廣的 DOMAIN-KEYWORD、網段規則及提前出現的預設規則。若 Direct 正常但 Proxy 失敗，先確認目前伺服器，不要急著修改網域規則。完成對照後，恢復原本模式再進行下一項修改，避免讓測試設定留在日常使用環境中。

檢查命中規則與相關請求

網頁通常不只會請求網址列中的網域，也可能需要圖片、指令碼、登入及 API 網域。若主頁正常但登入失敗，請查看 App 目前提供的連線記錄，找出故障發生時對應的請求與策略。若記錄顯示目標命中 REJECT，先確認該規則的用途，再於副本中進行範圍較小的調整。不要為了一個圖片請求刪除整組規則，也不要只憑網域名稱猜測用途；應優先依據實際故障記錄與服務說明判斷。

以下片段僅示範規則語法與順序：範例網域經由 PROXY，符合地理資料庫條件的位址使用 DIRECT，其餘流量交由 FINAL 處理。這不是可直接套用的完整設定；PROXY 必須在實際設定環境中指向可用策略。測試規則前，先確認編輯的是目前啟用的 Config；儲存後視需要重新連線，並以相同目標再次測試。修改未啟用的檔案，不會改變目前的執行結果。

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

若兩種路徑都能建立連線，但只有網域存取失敗，請繼續檢查 DNS；若只有特定伺服器失敗，請參閱逾時章節。不要把瀏覽器回報的所有網路錯誤都歸因於規則；憑證、目標維護與帳戶登入也可能造成存取中斷。完整記錄「目標、模式、伺服器、結果」後再尋求協助，比只提供開關畫面更有參考價值。也可參閱開關已開啟卻無法上網的逐項排查，再次確認檢查順序。

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

釐清測試結果能證明什麼

延遲測試、建立協定連線與開啟實際網頁，是不同層次的檢查。測試得到回應，只能表示該測試當時使用的路徑可正常完成，不代表所有網頁請求都能通過。反過來，測試顯示逾時，也可能與測試方式或目標有關，不能只憑單一數值就判定伺服器永久失效。先記錄測試方式，再用同一部伺服器存取固定目標，並依實際錯誤判斷問題出在連線前、驗證期間，還是請求轉送之後。

若一組伺服器同時逾時，先切換基礎網路進行比對；若同一網路中只有單一項目失敗，優先檢查該項設定與遠端狀態。測試期間不要反覆大量測速，以免額外請求干擾觀察結果。每輪保留一個已知可用項目和一個失敗項目，比較結果即可。若既有服務提供者有維護或帳戶狀態公告，請核對相關資訊；本手冊只說明設定的使用方式，不提供或推薦伺服器來源。

依序核對位址、驗證與傳輸欄位

先檢查伺服器位址是否誤含協定前綴、路徑、空格或換行，並確認連接埠與提供的資訊相符。若欄位要求填寫主機名稱，就不應貼上整條訂閱連結。複製內容時也可能把全形標點帶入密碼或識別欄位，造成看似一致卻無法驗證。不要憑經驗更換連接埠或加密方式，應逐項比對原始設定；敏感欄位只在裝置本機核對，公開截圖時請遮住完整密碼、識別碼與訂閱憑證。

接著核對協定所需的驗證與傳輸參數。Shadowsocks 的密碼與加密方式必須相符；VMess 與 VLESS 的 UUID、傳輸方式及 TLS 相關欄位不可混用；Trojan 通常需要一併確認密碼與 TLS 資訊。Hysteria2 與 WireGuard 也各有必要欄位，不可直接套用其他協定的參數。協定名稱相同，不代表所有伺服器都使用相同選項；實際參數一律以使用者既有服務的設定為準。

檢查 TLS、時間與網路差異

啟用 TLS 的連線需要確認伺服器要求的名稱。伺服器位址、SNI 與傳輸層 Host 可能各有用途，不應因名稱不同就全部改成相同。裝置時間明顯不正確，也會影響憑證有效期判定；請檢查系統日期與時區。遇到憑證錯誤時，先核對名稱、時間與伺服器端設定，不要將略過憑證驗證當成一般修復方式；這會改變驗證範圍，也可能掩蓋原本應發現的設定或憑證問題。

若 Wi-Fi 無法連線但行動網路正常，或情況相反，表示值得進一步檢查網路環境差異。某些傳輸會使用 UDP，網路設備對 UDP 的處理方式可能不同於一般網頁連線。先以服務提供者已提供且確認支援的設定進行比對，不要任意更改協定名稱，也不要盲目調整 MTU。只有在已確認協定、驗證與路徑正確，且可重複觀察到小封包正常、大型請求失敗時，才進一步調查路徑與分片相關問題。

訂閱更新失敗或匯入結果異常

先辨別連結類型與失敗階段

訂閱是用來取得伺服器清單的網址，不等同於單一伺服器，也不等同於 Config 設定檔。先確認既有服務提供者提供的內容屬於哪一種，再使用相應的匯入方式。若將網頁網址、帳戶管理頁網址或單一分享資訊貼進訂閱欄位，App 可能無法取得預期清單。檢查時只核對連結結構與來源說明，不要在公開對話中貼出完整連結；其中的查詢參數常含存取憑證，外洩後可能影響帳戶安全。

將更新失敗分為四類：無法發出請求、收到錯誤回應、內容解析失敗，以及清單更新後無法使用。無法發出請求時，先檢查網路與網域解析；若出現帳戶或連結失效提示，確認原服務帳戶與連結狀態；若解析失敗，檢查回傳內容是否符合 App 支援的訂閱格式。若清單已更新但仍無法連線，表示取得內容的步驟可能已完成，問題應轉向伺服器欄位或遠端狀態，不要繼續反覆點選更新。

確認訂閱請求使用的網路路徑

先確認基礎網路可正常存取，再手動更新一次。若目前連線已失效，而訂閱請求又依賴該連線，可能陷入無法更新、也無法恢復連線的循環。可先保留舊清單、停止目前連線，再透過可用網路重新嘗試，並記錄兩種狀態下的結果。不要假定所有訂閱都應使用相同請求路徑，也不要因一次失敗就覆蓋原始連結；應依既有服務提供者的存取要求與實際比對結果處理。

公共 Wi-Fi 尚未完成認證時，請求可能被導向登入頁面；某些服務異常時，也可能回傳網頁說明，而非伺服器清單。即使這些內容能在瀏覽器中顯示，也不代表訂閱格式正確。若出現解析錯誤，應優先確認回應內容的類型，不要將整個網頁複製到 Add Server。若需要進一步確認，向既有服務提供者描述 App 顯示的錯誤類別並提供已移除敏感資訊的內容即可；不要公開提交含帳戶資訊的回應本文。

比較更新前後的群組與選取狀態

更新前記下目前群組、所選伺服器名稱及手動新增的項目，必要時另存副本。訂閱更新可能會替換由該訂閱管理的項目，手動修改的欄位也可能被新內容覆蓋。因此，不應把對訂閱項目的暫時修改當成長期保存方式。更新後先確認項目數量與群組是否符合預期，再檢查目前選取的項目是否仍存在。名稱變更、名稱重複或伺服器遭移除，都可能使原本熟悉的選項不再指向同一條連線。

若更新後只剩部分項目，先檢查是否有篩選條件、群組收合或顯示範圍變更，再判斷資料是否遺失。若同名項目的參數不同，應查看協定與位址，不要只靠名稱辨識。成功取得訂閱不代表帳戶服務一定有效；服務期限、遠端維護與驗證資訊仍須分別確認。反覆刪除整個群組再匯入，通常無法修正伺服器端回傳內容，反而會失去原有比對資料，增加後續排查難度。

恢復至可驗證的訂閱狀態

復原時保留來源明確的訂閱群組，先手動更新，確認清單可用後再考慮自動更新選項。自動更新的實際入口與可用條件，請以目前 App 介面為準；不要把它當成修復無效連結的工具。若每次開啟 App 都會更新並覆蓋暫時修改，先確認相關自動更新設定，再決定如何另存測試項目。測試結束後清除重複匯入的群組，避免日後誤選舊項目。

連線正常，但速度緩慢或間歇卡頓

先明確界定「速度慢」的情況

頁面首次開啟等待時間長、下載持續速率偏低、影片間歇緩衝及遊戲回應延遲，不能用同一個延遲數值解釋。先記錄緩慢發生在建立連線還是傳輸過程，是所有目標還是單一 App，是持續發生還是只出現在特定時段。若只有第一次開啟較慢，後續請求正常，應留意 DNS、交握與快取；若連線迅速但大型檔案持續停頓，則應優先檢查連線穩定性、傳輸量與遠端負載，而不是只看測試清單上的數字。

測試時固定目標、伺服器與網路，暫停系統更新、照片同步及其他大量傳輸，再觀察相同工作。不要同時執行多個測速工作，它們會共用頻寬，讓結果失去可比性。比較測試盡量安排在相近時段，避免把早晚網路負載變化誤認為設定生效。若服務提供者說明有流量或速率條件，請確認目前帳戶狀態；用戶端設定無法取代遠端服務實際提供的容量。

依序比對基礎網路、伺服器與目標

先在關閉連線的情況下，存取基礎網路可連線的固定目標，觀察 Wi-Fi 訊號、路由器上行連線及其他裝置的使用情形。訊號格數多不代表無線環境穩定；干擾、距離與網路設備負載都可能影響傳輸。接著保持目標不變，使用目前伺服器重測。再切換至使用者既有且確認可用的另一部伺服器，比較是否只有單一路徑變慢。不要同時更換伺服器與 DNS，否則無法判斷改善來自哪一項。

若同一部伺服器對多數目標正常，只有某個目標較慢，可能與目標網站負載、內容傳遞位置或雙方之間的路徑有關。先確認 Config 是否讓相關網域使用預期策略，特別是主站與圖片、影片網域是否採用不同處理方式。必要時暫時使用 Proxy 進行比對，再恢復原本模式。單一影片無法達到預期畫質，不足以證明整體連線故障；也要考慮影音服務本身的自動調整機制、帳戶權限與快取狀態。

分別看待延遲、封包遺失與傳輸量

延遲描述往返時間或某個測試流程的等待時間；傳輸量則描述單位時間內實際傳送的資料量。兩者彼此相關，但並不相同。路徑回應迅速，持續傳輸時仍可能受限；路徑回應稍慢，也可能維持穩定下載。App 中的 Connectivity Test 適合協助觀察連線可達性，不應視為所有使用情境的總分。選擇伺服器時應依日常工作結果判斷，不要只為了更低的顯示數值頻繁切換，徒增重新連線與交握成本。

間歇卡頓更需要觀察連線是否持續穩定。若短時間內時好時壞，記錄是否同時發生 Wi-Fi 漫遊、行動網路切換、鎖定螢幕後喚醒或背景大量傳輸。對於依賴 UDP 的服務，也要分別確認網頁與該服務是否可用；主要網頁路徑正常，不代表所有傳輸都受到相同處理。不要為了測試任意修改 MTU、並行連線數或傳輸參數。只有在有明確證據與原始設定依據時，才於副本中修改，並安排可還原的比對測試。

保留穩定設定，不要一味疊加最佳化

若排查後發現問題只是規則繞道，修正規則範圍後，應重新測試其他常用目標，避免局部改善造成新的存取問題。若只在某種網路發生，保留該網路與另一網路的比對記錄，進一步檢查網路設備；若多個網路上的同一伺服器都很慢，則應轉而確認伺服器狀態與遠端路徑。不要把所有不明選項一概開啟；最佳化項目疊加越多，就越難判斷是哪一項改變了連線行為。

DNS 解析失敗與規則結果不一致

區分解析、連線與憑證錯誤

DNS 負責將網域轉換為後續連線使用的位址。網域無法解析、已取得位址但連線失敗，以及連線完成後憑證不符，是不同階段的故障。先確認錯誤訊息是否明確涉及解析，再比較多個網域的結果。不要直接以某個網站的位址取代網域來驗證整個流程，因為 HTTPS 通常也依賴正確的主機名稱與憑證；直接連線至位址失敗，不能單獨證明網路路徑無法使用。

若多個 App 開啟新網域時都會等待，但既有連線仍可繼續使用，應優先檢查解析路徑；若只有單一目標異常，先確認目標本身狀態與相關規則。瀏覽器、App 與系統可能各自保留快取，因此切換設定後，結果不一定會立即一致。測試前記錄原本設定，重新建立連線後重做相同的存取，並區分新開啟的請求與仍在沿用舊連線的頁面，避免將快取差異誤判為隨機故障。

確認目前 Config 的解析路徑

開啟目前啟用的 Config，確認 DNS 相關設定確實屬於正在使用的檔案。先了解原設定預期透過哪條路徑完成解析，再檢查解析伺服器是否可連線。單純將位址改成熟悉的值，不代表適合目前網路，也可能使原本可用的路徑失效。若使用加密解析方式，其連線本身也需要網路、正確時間及相應的交握條件；不要以為「加密」就代表在所有網路環境中都能自動使用。

特別留意循環依賴：目前伺服器位址需要先解析，但解析請求又只能透過尚未建立的連線完成，可能導致連線啟動時停滯。排查時應依現有設定說明，檢查初始解析路徑；不要同時更換伺服器網域與 DNS 設定。若服務提供者明確提供不同的連線位址與交握名稱，應分別填入相應欄位。不要為了避開解析，就任意以查得的位址永久取代網域；遠端位址可能變動，也可能影響傳輸條件。

了解網域規則與位址規則的適用範圍

DOMAIN 用於比對完整網域，DOMAIN-SUFFIX 用於比對指定網域及其子網域，DOMAIN-KEYWORD 的比對範圍更廣。IP-CIDR、IP-CIDR6 與 GEOIP 則依位址或位址資料庫進行判斷。請求能否使用網域資訊，取決於請求來源、解析流程與目前設定；不要假設每條連線都一定能命中網域規則。排查時先查看實際記錄，再判讀規則，不要只根據網址列推測命中結果。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

範例中的兩個網段是文件示例位址，不應直接替換成未經確認的大範圍實際網段。no-resolve 用來避免為比對相應位址規則而額外進行網域解析，不代表關閉所有 DNS，也無法修復解析伺服器無法連線。規則依順序處理，範圍過廣的前置比對可能使後面的精確規則無法生效。修改時先以最小範圍的目標測試，再決定是否擴大，避免將局部問題影響到其他 App。

檢查 IPv6 與裝置端的疊加設定

同一網域可能解析出不同類型的位址，Wi-Fi 與行動網路也可能有不同的 IPv6 條件。若只有某種網路無法連線，應檢查位址類型與目前路徑的支援情況，不要立刻停用所有相關功能。系統中的描述檔、網路過濾或其他解析設定也可能改變實際行為；只檢查自己能確認的設定，受管理裝置請交由管理員處理。每次調整後重新建立連線，減少舊工作階段造成的誤判。

耗電增加、發熱與背景活動異常

先確認統計區間與實際用量

系統電池頁面顯示的比例，是所選時間區間內的相對結果，不代表 App 在任何情況下都會有相同耗電量。當天其他 App 用量較少時，相同的連線活動也可能顯示較高比例。先記錄統計區間、螢幕使用時間、實際電量下降幅度及是否持續傳輸，再判斷是否異常。只看單一百分比，無法區分長時間網路轉送、基礎網路訊號不佳，或反覆連線失敗所造成的額外活動。

比較時盡量維持相近使用條件：相同網路、相似螢幕亮度、相近工作內容與使用時間。播放影片、雲端同步及個人熱點分享都會改變整台裝置的負載，不能直接比較兩天完全不同的工作情況。也不要把充電時發熱與單獨使用時發熱混為一談。若裝置明顯過熱、出現系統溫度警告或電量異常下降，應先停止高負載工作，待裝置恢復正常後，再進行短時間且可控的診斷。

檢查持續重新連線與背景大量傳輸

連線不穩時，反覆解析、交握與重建工作階段可能增加耗能。先觀察開關與系統 VPN 狀態是否頻繁變動，再確認是否只有特定伺服器或網路出現問題。若伺服器持續逾時，一直自動重試通常無法修復遠端狀態。暫停連線、檢查基礎網路，再以使用者既有且可用的項目進行比對。相較於單純比較連線時間，故障次數與觸發條件更能說明異常原因。

也要檢查是否有 App 正在同步照片、更新內容或還原資料。開啟連線後，原本等待網路的背景工作可能開始傳輸，因此看到的耗電變化不一定來自連線本身。可在系統允許的情況下暫停相關工作，再觀察是否恢復正常。不要為了降低某項統計數據而關閉必要的安全設定，也不要反覆清除 App 資料。應以相同時間區間比較傳輸量與電量變化，避免把正常資料處理誤判為故障。

確認 On Demand 與診斷活動

On Demand 會依據設定條件觸發連線；若網路環境不斷切換，觸發條件又頻繁成立與失效，就可能反覆建立連線。排查期間先記下規則，再暫時關閉 On Demand，手動維持一次穩定連線。若活動明顯減少，接著檢查具體觸發條件與目前網路變化，不要直接認定此功能本身無法使用。恢復設定時，每次只啟用一項條件，確認鎖定螢幕、切換網路與返回前景時的行為都符合預期。

持續大量測試、長時間保留詳細診斷記錄及反覆更新訂閱，也會增加網路或本機處理負擔。診斷結束後，停止不再需要的測試，只保留足以定位問題且已移除敏感資訊的記錄。若使用複雜的 Config，先複製保存，再停用與目前測試無關的額外處理，觀察差異。不要直接刪除所有規則；規則減少不一定能改善耗電，真正要確認的是哪項工作造成持續活動或反覆故障。

透過分組測試確認調整是否有效

可分三輪觀察：基礎網路下執行一般工作、手動維持穩定連線後執行相同工作，以及恢復 On Demand 後再執行相同工作。每輪的時間與工作內容盡量相近，記錄電量變化及連線是否重建。若只有某個 Wi-Fi 環境明顯異常，請繼續檢查訊號與路由器；若多個網路都在相同設定下反覆發生，則保留設定副本與觸發步驟。重新啟動後短暫改善不能取代長期驗證，至少還要重測一次原本容易出問題的使用情境。

App 或系統更新後出現異常

先確認實際變動的項目

問題在更新後發生，不一定是更新本身造成。同一時間也可能更新了訂閱、遇到伺服器維護、切換網路或更換 Config。先列出上次正常使用到首次故障之間發生的變化，確認更新的是 App 還是系統，以及是否同時更新訂閱。保留現有設定，不要接連重新安裝、清除資料與重新匯入；多項變更疊加後，很難判斷真正影響結果的步驟，也無法為後續排查保留可靠的現場資訊。

更新 App 後，先開啟 Home，確認伺服器清單、目前選取項目與啟用的 Config 是否仍符合預期。介面位置變動不代表原有內容已遺失；先檢查群組與目前使用的檔案，再決定是否重新匯入。若只是入口名稱或位置不同，請依目前介面操作，不要照著舊截圖猜測。App 的取得與更新一律透過 App Store；如需確認購買或回復流程，請參閱已購項目回復說明，不要改用其他取得方式。

依序重新測試系統狀態、設定與遠端連線

先關閉連線並確認基礎網路，再手動重新建立一次連線。若系統再次要求 VPN 授權，請閱讀提示並確認；若裝置受到管理限制，請交由管理員核對策略。更新系統後若連線異常，可先停止連線並重新啟動裝置，再重做相同測試；不要把重新啟動後短暫成功直接視為問題已解決。也應重測先前的故障操作，例如鎖定後喚醒或切換 Wi-Fi，確認連線在相同條件下能否維持正常。

接著使用原伺服器，在 Direct、Proxy 與 Config 之間進行可控比對，完成後恢復原本模式。若只有 Config 異常，請檢查設定語法、策略引用與規則順序；若所有經由伺服器的存取都失敗，請重新檢查位址、驗證與傳輸欄位。部分舊設定依賴較嚴格的欄位關係；問題出現後，應依既有服務提供者目前的設定說明逐項確認，不要盲目加入不熟悉的選項，或全面放寬驗證要求。

處理設定移轉與訂閱覆蓋

若異常緊接在訂閱更新後出現，請比較更新前保存的副本與目前項目，重點檢查協定、位址、連接埠、TLS 與傳輸欄位。名稱未變不代表內部參數沒有變更。若曾手動修改由訂閱管理的項目，更新後可能會還原為訂閱內容；此時應另存已確認有效的測試設定，並向既有服務提供者確認差異。不要反覆修改同一個訂閱項目後又立即更新，否則每次測試使用的參數都可能不同。

設定移轉也可能涉及檔案選取與策略關聯。先確認目前啟用的是預期檔案，再檢查其中引用的策略是否仍有對應項目。複製檔案不代表所有外部相依項目也一併複製；匯入成功也不代表所有引用都可正常使用。遇到解析錯誤時，保留具體錯誤訊息及對應行附近已移除敏感資訊的片段，只修正能解釋問題的部分。不要用來源不明的設定檔取代整份 Config 來「驗證」，這會同時改變分流、解析與處理邏輯。

最後再考慮重建與重新下載

只有在伺服器資訊、訂閱來源與 Config 副本都已妥善保存，而且清楚知道如何還原時，才考慮重建 App 自己的 VPN 設定或重新下載 App。重新下載前，先確認使用的是原購買帳戶，避免把商店帳戶問題與連線問題混為一談。儲存在外部位置的檔案，也要確認確實能開啟，不要只看到檔名就認為已備份。App 內的歷史狀態不一定能完整還原；若排錯需要依據這些狀態，請先完成必要記錄再清理。

iPad 連線、回復與多裝置差異

先區分購買狀態與設定狀態

同一購買帳戶下取得 App，與裝置上的伺服器設定是兩回事。先在 iPad 的 App Store 確認 App 購買狀態；系統需求、相容性及是否屬於通用購買，請以 App Store 頁面標示為準。能重新下載 App，不代表 iPhone 上的訂閱、伺服器選取與 Config 已自動出現在 iPad。首次開啟後應先確認實際內容，再依照快速入門教學匯入自己已有的資訊，不要以購買成功取代連線前的檢查。

若商店顯示的購買狀態與預期不同，請確認用於 App Store 的帳戶，而不只是查看系統畫面上方的帳戶名稱。App ID 應為 932747118，開發者為 Shadow Launch Technology Limited。相關回復步驟請參閱iPad 取得說明。購買問題應先在商店層面處理；伺服器驗證或存取問題則依本頁流程檢查，兩者無法互相取代。買斷用戶端取得的是 App 使用資格，不包含連線服務。

比對兩台裝置的實際設定

iPhone 正常但 iPad 失敗時，先讓兩台裝置連上同一個可用 Wi-Fi，並在相近時間存取同一目標。比較所選伺服器、Global Routing、目前 Config 與 DNS 條件，不要只看伺服器名稱。訂閱更新時間不同、同名項目參數變更或啟用的檔案不同，都可能造成差異。比對時，先讓兩台裝置都處於已記錄的測試狀態，每輪只修改其中一台的一項設定，避免兩邊同時變動而失去參照。

傳送設定時，使用自己能確認且可控的方式；匯入後逐項核對位址、連接埠、協定與必要驗證欄位。不要透過公開文件或公開圖片傳送完整訂閱連結，也不要以為 QR Code 天生不含敏感資訊。若某種同步方式只傳送 Config 檔案，也要確認檔案引用的伺服器或策略確實存在。檔案能開啟，不代表所有相依項目都已備妥；遇到不明策略時，應先補齊對應關係，不要隨意改成其他名稱。

檢查 iPad 的網路與系統限制

部分 iPad 僅支援 Wi-Fi，無法直接比照行動網路的測試方式；可改用另一個可信且可用的 Wi-Fi 網路檢查。支援行動網路的裝置，則分別確認網路權限與目前的數據連線。使用手機熱點時，iPad 使用的是熱點提供的網路環境，仍須確認基礎網路正常。不要因為 iPhone 本身可以存取，就推論熱點下的 iPad 一定有相同連線路徑；共享連線、訊號與工作階段條件都可能不同。

由學校、公司或家庭管理的 iPad，可能受到 VPN、帳戶或網路策略限制。首次連線若無法新增 VPN 設定，先查看系統提示並聯絡管理員；不要嘗試刪除管理要求保留的內容。公共網路需要網頁登入時，應先完成基礎網路認證再啟動連線。若只有某個 App 失敗，請檢查其網路權限與帳戶狀態；若所有 App 都失敗，再依序排查伺服器、DNS 與規則，避免把局部權限問題擴大處理。

測試鎖定螢幕、多工與長時間使用

iPad 常在分割畫面、多工與長時間待機之間切換；App 在背景執行，不代表連線已停止。應同時參考系統 VPN 狀態與實際請求，不要只看 App 視窗是否位於前景。若從鎖定螢幕恢復後發生故障，記錄喚醒前後連線的 Wi-Fi、On Demand 條件與開關狀態，再手動重建連線進行比對。若只有自動條件下能重現，優先檢查條件規則；若手動連線也失敗，則回頭檢查基礎網路與伺服器可達性。