Shadowrocket
訂閱與伺服器管理

01 / SUBSCRIBE

Subscribe 匯入訂閱

訂閱是可重複存取的伺服器資料入口，不是某一台伺服器的位址。匯入時，Shadowrocket 會向該入口發出請求，並將回傳的支援內容解析為伺服器項目。之後更新同一筆訂閱，清單中的項目可能增加、減少或替換。因此，管理訂閱的第一步是分清「入口」與「結果」：入口決定下次從哪裡取得資料，結果才是 Home 中可選用的伺服器。只有顯示名稱，無法證明入口正確或內容完整。

匯入前先確認資料類型

準備使用者已有的完整訂閱連結，確認複製的內容來自自己的訂閱資料，而不是帳戶頁面、說明頁面或單一伺服器分享連結。訂閱入口可能包含查詢參數，這些參數也是位址的一部分。複製後不要自行刪除問號後方的內容，也不要連同通訊軟體附帶的中文說明、句號或換行一起貼上。若資料分別提供訂閱入口與帳戶登入頁面，兩者不能互換。

在 Home 點選新增入口，進入 Add Server 後將 Type 設為 Subscribe，再把完整連結填入 URL。若目前介面提供訂閱專用入口，也可以從該入口進入；判斷依據是最後填入訂閱位址，而不是手動輸入伺服器連接埠。為訂閱設定容易辨識的備註，例如用途與來源代號，然後儲存並等待取得結果。按鈕位置與選項依目前 App 內的介面為準，不要依圖示位置猜測功能。

首次取得後檢查三個層次

第一層確認訂閱本身是否儲存成功，重新進入編輯頁面核對位址是否完整。第二層檢查訂閱下方是否出現伺服器，查看名稱、協定類型與群組歸屬，而不只是確認是否顯示成功提示。第三層選擇其中一項進行連線驗證。訂閱成功儲存、訂閱內容成功解析、伺服器實際連線成功，是三種不同結果，不能以其中一項代替其他項目。

如果取得後清單是空的，先保留現有項目，並記下錯誤提示與發生階段。位址能在瀏覽器中開啟，也不代表回傳的是可解析的訂閱內容：伺服器可能回傳登入頁面、存取限制說明或空白回應。反過來說，瀏覽器顯示一段難以閱讀的文字，也不能據此判定內容已損壞。應依據 App 的解析結果與使用者現有資料中註明的格式確認，不要將完整回應貼到公開討論區。

訂閱清單不等於規則設定

Subscribe 主要用來取得與維護伺服器資料；Config 中啟用的設定則決定規則、策略及相關行為。匯入訂閱後，不應假設所有網站都會使用新伺服器。還要檢查目前選擇的 Global Routing、實際選取的伺服器，以及設定中的策略引用。若要建立首次連線，依快速入門步驟逐一驗證，比同時修改訂閱與規則更容易判斷問題。

反覆匯入同一連結可能產生多個管理入口，讓後續更新、刪除與排解問題更加混亂。再次新增前，先在清單中尋找既有訂閱並嘗試更新。只有需要保留獨立測試副本時，才明確標示副本用途。若清單為空，可接著閱讀訂閱匯入失敗或清單為空的自我檢查；已匯入的舊清單應先保留，避免排查時失去可用的參照。

02 / ADD SERVER

Add Server 手動填寫欄位

手動新增適用於使用者已持有一台伺服器的完整連線資料，或需要逐項核對某個項目的情況。先在 Add Server 選擇正確的 Type，再填寫該協定顯示的欄位。協定選擇不是名稱標籤，而是會決定驗證方式、資料封裝與連線參數。不能因為兩個項目都使用密碼，就將 Shadowsocks 與 Trojan 互換；也不能只靠更改連接埠，把一種協定改成另一種。

分別核對位址、連接埠與驗證資料

伺服器位址通常是網域名稱或 IP 位址，應依欄位要求填寫主機部分，不要直接填入網頁位址中的路徑。連接埠是伺服器端的監聽連接埠，不是任意選擇的數字。備註只用來辨識項目，不會參與驗證；把使用者名稱填在備註欄，或把顯示名稱當成主機名稱，都無法建立正確連線。填寫後先收起鍵盤，逐項對照原始資料，特別留意前後空格與外觀相似的字元。

協定參數應成組核對

Shadowsocks 的加密方法與密碼必須同時相符，不能只確認密碼正確，就忽略加密方法。VMess、VLESS 常見的識別欄位是 UUID，也應檢查資料中指定的傳輸方式。Trojan 的密碼與 TLS 相關欄位各有用途。HTTP、SOCKS5 若需要使用者名稱與密碼，應分別填寫；資料未要求驗證時，不要自行新增一組值。實際可用欄位會依所選協定與目前介面而異，請以畫面顯示為準。

啟用 TLS 時，連線位址與伺服器名稱可能不同。SNI 用於 TLS 交握時的伺服器名稱，憑證驗證也會檢查伺服器憑證涵蓋的名稱。使用 IP 作為連線位址，不代表 SNI 也要改成該 IP。遇到憑證錯誤時，應先核對名稱、裝置時間與原始資料，而不是直接關閉驗證。關閉驗證會改變信任邊界，也無法修正錯誤密碼或傳輸路徑。

若資料指定 WebSocket 等傳輸方式，Host 與 Path 應連同傳輸選項一起核對。路徑通常區分大小寫，斜線也有意義；多一個空格或少一個開頭斜線，都可能造成交握失敗。Hysteria2、WireGuard 等協定也有各自的專用參數，不能以另一種協定的欄位表取代。缺少必要資料時，應先補齊現有資料，不要採用「逐一嘗試開啟所有開關」的排解方式。

儲存後保留可供比對的原始項目

對於已有但無法連線的伺服器，先複製或記錄目前欄位，再一次只修改一個可疑參數。若同時修改位址、連接埠與 TLS，連線結果改變後就很難判斷是哪個項目造成影響。手動維護的項目應使用獨立備註，避免與訂閱中的同名項目混淆。訂閱管理的項目可能在更新後重新產生，本機暫時修改不一定會保留，不適合作為長期維護方式。

03 / IMPORT

Scan QR Code 與剪貼簿匯入

QR Code 與剪貼簿只是傳遞文字的方式，不會改變伺服器資料本身。一個 QR Code 可能包含單一分享連結，也可能是訂閱位址；一段複製的內容也可能只是說明文字。開始操作前，應先判斷要匯入的資料類型，再檢查 App 解析後出現的是單一伺服器，還是需要取得內容的訂閱入口。成功辨識只表示讀取到文字，不代表其中參數完整或服務可用。

掃描前先確保影像清晰

在 App 中使用 Scan QR Code，對準使用者現有資料中的 QR Code，盡量讓四個角完整進入掃描範圍。避免反光、傾斜與過度縮放；若 QR Code 顯示在另一台裝置上，可適度調高螢幕亮度並保持穩定距離。較長的連結會讓圖樣更密集，經過壓縮的通訊軟體預覽圖可能無法正確辨識，建議使用原始清晰影像，不要反覆掃描同一張模糊預覽圖。

若相機權限遭拒，請前往系統設定檢查 Shadowrocket 的相機存取權限，再返回 App 重試。權限問題與 QR Code 內容問題應分開判斷：完全無法開啟取景畫面，通常先檢查權限；可以取景但一直無法辨識，則先檢查影像品質。若目前 App 入口支援從照片圖庫讀取 QR Code，可依介面提示選擇現有圖片；若畫面沒有此入口，就不要假設所有掃描頁面都支援相同操作。

剪貼簿匯入時只複製目標內容

複製前確認已選取完整連結，特別留意長文字在螢幕邊緣折行的部分。畫面上的換行不一定代表文字中真的有換行，但手動拼接可能引入多餘空白。返回 Shadowrocket 後，使用目前介面提供的剪貼簿匯入入口，或將訂閱位址貼到 Subscribe 的 URL 欄位。系統詢問是否允許貼上時，確認這次操作是自己發起的，再選擇允許；若拒絕，內容就不會匯入，不要誤以為是協定不受支援。

從備忘錄或訊息複製內容時，常見問題是連同連結前方的序號、後方的說明，以及包住連結的引號一起複製。先在本機確認連結的開頭與結尾，再重新複製。不要為了「清理」位址而刪除其中的百分比符號、等號、加號或問號；這些字元可能是編碼或參數的一部分。若平台已將原文替換成摘要或截斷顯示，應回到原始資料複製，不要依預覽文字自行補齊。

匯入後依欄位而非數量驗收

解析出項目後，開啟編輯頁面核對 Type、主機、連接埠與驗證欄位是否符合原始資料。QR Code 可能對應舊參數，顯示名稱也可能與目前訂閱中的名稱相同，因此「清單多了一項」不足以作為驗收標準。若重複匯入產生多個同名項目，先逐一檢查歸屬與關鍵欄位，保留驗證通過的項目，再清除確定重複的項目；辨認清楚前不要批次刪除。

掃描取得訂閱位址後，仍需透過網路取得內容；掃描單一分享連結通常只會建立本機伺服器項目。前者應依訂閱取得錯誤排查，後者應依欄位解析或連線錯誤排查。若掃描後開啟網頁，而不是顯示伺服器資料，也應先確認 QR Code 承載的內容類型。不要把網頁中的任意位址當成伺服器位址填入，否則會把入口問題變成欄位問題。

匯入與連線之間，還要選擇伺服器、確認 Global Routing，並允許系統設定 VPN 等步驟。首次操作可返回使用說明完成主要流程。若掃描與手動填寫匯入的是同一筆資料，結果卻不同，應優先比對兩筆項目的欄位，找出解析差異，而不是反覆切換網路來掩蓋差異。

04 / LINK FORMAT

分享連結格式與匯入界線

單一分享連結通常會將協定、驗證資料、伺服器位址與部分附加參數放在同一段文字中。它與訂閱的差別在於：前者描述一個連線項目，後者則指向一組可更新的內容。判斷時不要只看連結長度，也不要只看是否包含網路位址。帶有協定前綴的單一連結、用來取得清單的位址，以及供說明用途的網頁，都是不同類型的資料，應使用各自對應的匯入入口。

先看結構，再核對參數

常見前綴包括 ss://、vmess://、vless:// 和 trojan://。前綴用來識別解析方式，但不保證目前 App 能辨識該格式的所有擴充欄位。不同協定的本文結構並不相同，有些包含編碼內容，有些則採用類似位址與查詢參數的結構。不能一律用「冒號前是使用者名稱，後面是密碼」來拆解，更不應直接修改編碼片段。

有些連結會在結尾以井字號附加備註，參數部分則可能使用百分比編碼。編碼可能用來保護特殊字元，也可能表示非英文名稱；手動替換字元會改變解析結果。備註通常不參與實際連線，但查詢參數可能會決定 TLS、傳輸方式與路徑。若名稱顯示亂碼但可以連線，先處理備註顯示；若連線失敗，則應檢查協定欄位，不要把兩者混為一談。

解析成功不代表參數完全相同

一個連結可能同時包含基本驗證參數與額外傳輸選項。匯入後只看到位址與密碼，不代表其他選項也已完整匯入。應開啟項目，對照原始資料檢查所需的傳輸方式、安全連線與伺服器名稱等設定。若連結格式有不同寫法，應以目前 App 的實際解析結果為準；未辨識的欄位應依現有資料逐項核對，不要將未知參數隨意填入備註或位址欄。

從伺服器項目匯出分享連結時，也應留意接收端是否需要完整參數。分享單一項目通常不能取代整個管理環境的分享：訂閱更新關係、目前 Config、規則策略與部分全域設定未必會包含在連結中。需要移轉裝置時，應採用本頁最後一章的分層備份方式，不要只保存一條目前可用的連結，就以為所有設定都已備份。

伺服器資料與規則文字不能互相取代

以下是 Shadowrocket 的規則片段，屬於 .conf 設定中的 Rule 區段，不是伺服器分享連結，也不包含驗證資料。它表示示範網域使用 PROXY，其餘請求使用 DIRECT。實際編輯前應確認目前設定中對應策略的意義；只把這段文字貼到 Add Server，不會產生可連線的伺服器。

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

分享前先確認接收者需要的是伺服器參數、訂閱入口，還是規則片段。對外討論規則時，通常只需要比對條件與策略名稱，不需要提供任何伺服器憑證。比對連結錯誤時，可記錄協定前綴、是否有參數及錯誤現象，並隱藏完整驗證資料。編碼不等於加密保護，連結看起來難以閱讀，也不代表其中的資訊可以公開。

若目標只是讓指定網站使用現有伺服器，應調整規則，而不是不斷重新匯入清單。可參閱指定網站使用 PROXY 的情境設定，了解規則順序與 FINAL 的關係。先確認資料屬於哪個層次，再選擇操作入口，可減少「匯入成功但行為沒有改變」的誤判。

05 / UPDATE

訂閱更新與失敗後的回復

更新訂閱的目的是重新取得入口目前提供的伺服器資料，而不是修復所有連線問題。伺服器端調整位址、連接埠、驗證資料或可用項目後，更新可以將變更同步到本機；若問題來自裝置網路、目前規則或系統授權，單純更新訂閱通常無法解決。開始前先描述現象：是取得失敗、清單有變動，還是現有項目連線失敗。不同現象的後續檢查順序也不同。

建立可追蹤的更新流程

更新前確認目前選取的伺服器及其所屬訂閱，記下幾個重要名稱，必要時先備份。接著只更新目標訂閱，不要同時更新所有群組並修改規則。操作完成後，先查看是否出現錯誤提示，再檢查清單是否變動，以及原先選取的項目是否仍在。某個名稱消失可能是入口回傳的內容已變更，不一定是本機誤刪；名稱不變也無法證明背後的位址與憑證沒有變動。

若更新需要網路請求，應先確認裝置目前可連線至該訂閱入口。有些情況下，目前的連線路徑會影響存取結果，因此可在安全且可控的前提下比較不同網路狀態，但每次只改變一項條件。不要把連續點擊更新當成測試方式；短時間重複請求可能遇到限制，也會讓錯誤提示彼此覆蓋。第一次失敗後先記下原因，再進行有目標的重試。

依取得、解析、使用三個階段處理

取得失敗時，檢查位址是否完整、網路是否可用，以及入口是否仍有效。解析失敗時，重點確認回傳內容是否為支援的訂閱資料，是否已變成登入頁面或提示文字。更新成功但連線失敗時，則檢查新的伺服器欄位、選取狀態與規則策略。這三種情況應分開記錄；「訂閱更新成功」只代表取得與解析已達到某個結果，不代表每台伺服器都通過實際連線測試。

若入口更換了驗證參數，舊清單可能暫時仍顯示正常名稱，卻已無法建立連線；反之，更新請求失敗後，舊項目仍可能可以使用。保留現有清單有助於判斷變化發生在哪個階段，但不要把本機快取視為長期保障。若更新結果異常，先停止後續批次操作，核對入口狀態與原始資料；不要立刻刪除整個訂閱，再用同一個尚未確認的位址重新建立。

更新頻率與本機修改的關係

更新頻率應依實際變化安排，例如收到現有訂閱資料的變更通知、發現項目失效，或準備移轉前進行核對。若目前介面提供自動更新設定，再依裝置網路與使用習慣決定是否啟用。自動更新不保證每次都成功，也不能取代結果檢查。使用受限網路或需要節省流量時，請留意背景取得仍然會發出網路請求，並非單純重新整理本機資料。

修改訂閱中的項目之前，先確認更新可能會覆蓋這些變更。若要長期使用個別自訂項目，且 App 支援，可將它另存為獨立項目並註明維護方式；原訂閱則仍由原入口管理。不要將同一份伺服器資料同時視為自動維護與手動維護對象，否則更新後難以判斷應以哪份資料為準，也容易在排解問題時測到不同副本。

App 更新與訂閱更新也應分開理解。前者由 App Store 管理，後者用來取得使用者已有的連線資料；更新 App 不會自動補上遺失的訂閱，更新訂閱也不會改變 App 本身。購買、重新取得 App 及系統需求請參閱已購項目還原說明；連線與解析問題可接著查閱常見問題。

06 / ORGANIZATION

多訂閱整理與策略對應

管理多筆現有訂閱時，首要目標不是把項目合併成一份更長的清單，而是保留可追蹤的歸屬關係。每筆訂閱都應能回答三個問題：從哪個入口更新、哪些伺服器屬於它，以及目前使用的項目由誰維護。若缺少歸屬資訊，同名伺服器可能來自不同入口，更新其中一筆卻誤以為另一筆也已同步，之後的測試、刪除與備份都可能判斷錯誤。

先為群組命名，再標記例外項目

為訂閱設定簡短且固定的備註，例如「日常資料 A」、「測試資料 B」，以用途與自訂代號區分，不要在名稱中放入完整位址或驗證值。手動新增的項目則明確標示為本機維護。名稱最好能在窄螢幕上辨識前半段，不要讓所有項目都以相同的長前綴開頭。協定、地區等資訊可用來輔助篩選，但不能取代來源歸屬，因為這些資訊可能隨更新而改變。

同名不一定重複，名稱不同也不一定代表項目不同。確認是否重複時，應一併比較協定、主機、連接埠、驗證資料與傳輸參數；只比較顯示名稱容易誤刪。若不同訂閱恰好包含相同連線項目，應先決定是否要保留兩個入口的管理關係。保留入口不代表必須同時使用所有項目；刪除其中一個本機副本，也不代表另一筆訂閱不會再提供相同資料。

將清單管理與路由選擇分開

伺服器清單回答「有哪些連線項目可供選擇」，Global Routing 則回答「請求要如何處理」。使用 Config 模式時，還需了解目前啟用設定中的規則與策略。整理群組後，應檢查常用策略實際引用的是固定項目、目前選取項目，還是其他設定定義的對象。不要因為某台伺服器位於清單頂端，就認為所有規則都會自動使用它。

上表用於區分管理層次，不能取代個別設定的檢查。特別是在 Config 模式下，某個請求可能符合 DIRECT 規則，即使目前伺服器不可用，請求仍可能成功。反過來說，切換清單中的伺服器，也不保證某個固定策略會跟著改變。整理後應透過實際請求與可查看的診斷資訊確認連線路徑，不要只看連線開關或清單中的勾選位置。

透過小幅變更維持可管理性

一次只整理一筆訂閱，先修改備註並確認歸屬，再處理確定重複的項目，最後重新測試常用請求。每整理完一個群組，就保留可用狀態，避免同時進行更新、重新命名、刪除與規則調整。用途不明的項目可先標記待確認，不必急著刪除。若 App 提供篩選或摺疊顯示，優先利用這些顯示方式減少干擾，不要為了縮短清單而直接刪除尚未檢查的資料。

訂閱更新可能會重新產生名稱與項目，因此依名稱比對的策略也應重新檢查。名稱中包含地區或用途的自動選擇條件，可能因命名調整而選到不同項目。儲存設定前，應確認策略仍有可用成員，且沒有指向已刪除的項目。了解設定的引用方式後，才適合大幅重新命名；如果只是為了方便閱讀，先修改訂閱備註通常影響較小。

多筆訂閱不代表連線品質有保障，也不表示應逐一測試所有項目。選擇少數用途明確的候選項，依下一章的方法建立比較條件即可。常用清單以外的項目仍可保留在原群組，需要時再檢查。這樣既能保留更新關係，也能減少每次連線前重新辨認大量名稱的負擔；長期管理時，也比反覆清空重建更容易追溯。

07 / CONNECTIVITY TEST

延遲測試與清單排序

延遲測試呈現的是特定測試方式在某個時間點的回應結果，不能直接等同於網頁開啟速度、持續傳輸能力或所有目標的可連線性。不同測試方式涵蓋的連線階段不同，因此比較前必須確認使用相同方法。單次測得較低的數值，只表示該次觀察到的等待時間較短；實際請求若還需要額外的網域解析、TLS 交握或目標伺服器處理，使用感受仍可能不同。

先固定測試條件

選定相同的網路環境，避免測試期間切換 Wi-Fi 與行動網路。確認裝置沒有同時進行大量傳輸，再對同一批候選項執行 Connectivity Test 或目前介面提供的測試功能。若可選擇測試方式或目標，應維持相同設定。記錄結果時一併記下測試方式與網路類型，比只記一個數字更有參考價值；否則下次看到差異時，無法判斷是伺服器變動，還是測試條件改變。

TCP 類測試通常較接近檢查連接埠是否有回應，不一定會完成協定驗證與目標存取；其他涉及實際請求的測試方式可能涵蓋更多階段，但結果仍取決於測試目標。連接埠可連線不代表密碼正確，測試目標可連線也不代表所有網站都能存取。應依目前 App 提供的測試方式解讀結果，不要將不同方法的數值直接放在一起排序，再據此推論穩定性。

分別判斷逾時、波動與實際體驗

逾時不一定代表伺服器永久無法使用，也可能與目前網路、解析、封包遺失、測試目標或伺服器狀態有關。先針對少數項目重新測試，並與已知可用的項目比較。若所有候選項都同時異常，優先檢查裝置網路與測試設定；若只有一項持續異常，再核對該項的位址、連接埠與驗證資料。不要因一次逾時就批次刪除，也不要因一次成功就認定設定沒有問題。

在相同條件下間隔進行少量測試，觀察是否持續出現明顯波動，比追求單次最低數值更實用。測試過於密集也會產生額外請求，不宜無限重複。接著選定候選項，使用常用網站進行實際請求，檢查是否能持續載入並完成必要操作。實際體驗驗證應符合工作需求，不要只開啟一個簡單頁面，就推論所有使用情境都沒有問題。

排序只會改變檢視順序

依延遲排序有助於快速找出候選項，但排序結果通常只反映測試當下的狀況，不是永久優先順序。清單頂端的項目不一定是目前選取的項目，也不一定是設定中所有策略使用的對象。排序後應重新確認勾選位置與群組歸屬。若使用 Config 中的自動選擇機制，還要另外檢查其測試目標與選擇邏輯，不要把手動排序當作策略設定的替代方案。

地區名稱與協定類型也只能提供背景資訊。顯示的地區可能只是維護者設定的名稱，無法完整描述請求路徑；某種協定在一種網路環境中表現正常，也不代表換個環境仍然如此。應在自己實際使用的網路中比較，不要只憑名稱下結論。更詳細的選擇方式請參閱如何判讀延遲測試、地區與協定類型，重點是讓測試條件保持一致。

透過診斷資訊確認是否採用預期策略

測試正常但目標存取異常時，先檢查請求在 Global Routing 下實際採用的策略。以下範例表示示範網域使用 PROXY，符合中國地區 IP 條件的請求使用 DIRECT，其餘使用 PROXY。規則會依序檢查；此範例僅說明邏輯，未了解現有設定前不適合整段覆蓋。不同請求可能符合不同策略，因此即使選用同一台伺服器，存取結果也可能不同。

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

排解問題時，分別記錄「測試是否有回應」、「協定是否成功建立連線」、「規則是否選中預期策略」及「目標是否正常回應」。如此才能判斷該修改欄位、切換伺服器，還是調整規則。若將所有問題都歸結為延遲高低，就會忽略驗證錯誤、規則比對錯誤與目標本身異常，也可能因此破壞原本可用的訂閱結構。

08 / BACKUP & REMOVE

刪除、備份與還原驗證

刪除前應先確認對象是單一伺服器、整筆訂閱，還是 Config 中的設定檔。三者影響範圍不同：刪除單一項目可能只影響本機清單，刪除訂閱會失去對應的管理入口，刪除設定檔則可能改變路由行為。也要區分 App 中的本機刪除與伺服器端資料變更；前者不會自動撤銷訂閱位址，也不會讓已分享出去的憑證失效。若資料已外洩，應處理原始憑證，而不只是清空裝置清單。

分層備份，不要只保存截圖

第一層是訂閱入口與歸屬備註，第二層是獨立手動項目所需的欄位，第三層是目前啟用的規則設定與需要記錄的選項。若目前 App 提供匯出或備份入口，先確認匯出內容涵蓋哪些層次，再將檔案儲存在自己能控管的安全位置。不同匯出對象可能只包含伺服器或只包含設定，不能因檔案成功產生，就假定所有狀態都已備份。

截圖適合記錄勾選位置與操作現象，不適合作為唯一的還原資料。長位址可能無法完整顯示，隱藏的驗證欄位也不會因截圖而保存。另一方面，截圖中的 QR Code、訂閱參數與密碼也可能洩漏連線資料。備份應優先保留可還原的原始資料，並限制存取範圍；供他人協助排解問題的截圖則應另外製作，遮蔽敏感部分，不要直接傳送完整備份。

刪除前先檢查引用關係

確認準備刪除的項目不是目前選取的伺服器，也沒有被常用策略固定引用。若是訂閱中的項目，單獨刪除後，下次更新可能再次出現；若目標是停止管理某筆訂閱，應處理訂閱入口本身，而不是逐項刪除回傳結果。若是手動項目，請先確認原始參數已存入備份，再進行刪除。遇到名稱相似的項目，先開啟編輯頁面辨認，不要只憑清單位置操作。

刪除 Config 檔案前，先確認目前啟用的是哪一份，保存必要內容並準備可用的替代設定。只刪除伺服器不會自動修正規則中的引用；反過來，刪除規則設定也不會撤銷訂閱入口。批次清理時依序進行「備份、核對、少量刪除、重新測試連線」。每個步驟都能回到已知狀態，比一次清空所有內容後再尋找遺漏資料更容易控制影響。

還原後逐層驗收

在新裝置或重新安裝後，先透過 App Store 取得已購 App，操作說明請見已購項目還原。App 購買紀錄與伺服器資料是兩回事，重新取得 App 不代表所有連線資料都會自動恢復。系統需求與購買適用性以 App Store 頁面標示為準。還原資料時，也不要假設系統備份一定包含所有項目，應檢查實際還原結果。

先還原一筆明確的訂閱或手動項目，核對欄位並驗證連線，再還原其他群組。重新取得訂閱內容後，檢查目前清單，不要只與舊截圖比較項目數量。接著還原規則設定，確認 Global Routing 的選擇、目前伺服器與策略引用；最後檢查所需的 On Demand 等設定。首次建立連線時，依系統提示授權 VPN 設定，不能以還原檔案取代系統權限確認。

舊備份中的入口與憑證可能已失效，因此還原失敗不一定代表檔案損壞。應分開驗證匯入是否完成、訂閱是否能更新，以及伺服器是否能連線。備份中的名稱也可能與新清單不同，需要重新檢查固定引用。還原成功後，保存一份目前狀態紀錄，並清楚區分舊備份與已驗證的新備份，避免下次誤用尚未核對的資料。

保留必要的最少副本，並定期清除已確認不再使用的敏感資料。修改後的規則與手動項目應及時加入備份，但不必為每次臨時測試保留大量難以辨識的副本。若還原過程仍有問題，請記下失敗階段、已執行步驟與已遮蔽敏感資料的提示，再查閱常見問題；若要重新建立操作順序，請返回使用說明逐步驗證。