01 / SUBSCRIBE
Subscribe 入口與資料範圍
先釐清訂閱、伺服器與 Config
訂閱是用來取得伺服器列表的位址；伺服器項目包含建立單次連線所需的具體參數；Config 則用於儲存規則及相關設定。三者可以搭配使用，但不能互相取代。將一般網頁位址填入 Subscribe，不會自動產生可連線的伺服器；把伺服器分享連結當作規則檔匯入，也不會得到預期的分流結果。操作前先確認手上資料的用途，比反覆嘗試不同入口更有效。
訂閱通常會在更新時傳回一批伺服器資料，其中可能包含位址、連接埠、協定與驗證欄位。它解決的是「列表從哪裡更新」的問題，不代表已選取其中某一個項目，也不代表連線已開啟。列表顯示名稱後，仍須核對項目、選取伺服器，並依實際需求設定 Global Routing。匯入成功、連線成功及目標服務可用，是三項需要分別驗證的結果。
本章以使用者已有自己的訂閱為前提。準備資料時，請保留訂閱位址原文，以及既有服務說明中的格式、驗證方式與更新要求。不要把管理網頁、登入頁面或付款紀錄頁面的位址當作訂閱位址。即使這些位址來自同一個網域，回傳的資料也可能完全不同；能在瀏覽器顯示頁面，不代表該位址能由 Subscribe 解析。
透過 Add Server 建立訂閱項目
在 Home 找到新增入口，進入 Add Server 後確認 Type。新增訂閱時選擇 Subscribe，輸入完整的訂閱位址，並填寫容易辨識用途的名稱或備註，再儲存。不同裝置的控制項排列可能不同，請以實際介面為準；重點是確認建立的是訂閱紀錄，而不是把整段網址貼進某種協定的伺服器位址欄。儲存前請從頭到尾再次檢查位址。
訂閱位址中的路徑與查詢參數通常是識別資料的一部分，不可只保留網域。尤其要檢查複製時是否多了句號、引號、換行或開頭空格。若位址來自會自動換行的訊息，畫面上的折行不一定是真正的換行，請勿憑外觀手動拼接。較穩妥的做法是複製原始文字，貼上後檢查首尾與重要參數，而不是重新輸入整段長位址。
儲存後執行一次更新，再查看訂閱底下是否出現伺服器項目。確認數量是否符合既有服務說明、名稱是否容易辨識，以及協定欄位是否完整。這裡不預設固定數量，因為列表會隨帳戶權限與遠端內容而變動。若結果為空，請先查看更新錯誤或回傳的內容類型，不要立刻刪除現有列表；保留原紀錄有助於比對位址是否遭到修改。
建立可重複驗證的初始基準
首次更新完成後，選擇一個參數明確的伺服器作為驗證對象，記錄當時使用的本機網路、Global Routing 狀態與測試目標。不要同時更換訂閱位址、規則檔與網路環境，否則失敗後難以判斷是哪個環節發生變化。若原本已有可用設定，請先保持不變，只匯入訂閱並檢查列表，藉此區分匯入問題與規則問題。
部分訂閱也會顯示用量或有效期限等附加資訊。這些資訊由遠端傳回，用戶端只是呈現資料，不能只憑顯示狀態推斷實際連線情況。反過來說，沒有附加資訊也不代表訂閱無效。判斷時應確認更新是否完成、項目是否可解析，以及選取的伺服器是否能建立符合預期的連線；必要時再核對既有服務的帳戶狀態。
| 項目 | 負責的內容 | 無法據此推斷 |
|---|---|---|
| Subscribe | 取得及更新伺服器列表 | 目前連線一定可用 |
| 伺服器項目 | 協定、位址、連接埠與驗證 | 規則已正確比對 |
| Config | 規則及相關設定 | 訂閱憑證仍然有效 |
建議為首次成功匯入留下簡短紀錄：訂閱用途、新增方式、上次成功驗證時的環境，以及是否另有手動新增的伺服器。紀錄不必抄下憑證，可改註明憑證存放於哪個本機安全位置。日後更新失敗時，先依這份基準逐項檢查，不要直接重設所有設定。連線流程的詳細操作，可返回使用說明對照進行。
02 / ADD SERVER
Add Server 手動填寫欄位與協定核對
先選擇 Type，再填寫通用欄位
手動新增適用於已有完整伺服器參數、需要核對單一項目，或需要保留獨立測試紀錄的情況。進入 Add Server 後先選擇 Type，再填寫其他欄位。不同協定的欄位意義並不相同，不能因為都有位址和連接埠就互換類型。變更 Type 後，也要重新檢查已填內容，避免舊欄位殘留、驗證方式不符或選項恢復預設值。
伺服器位址通常是網域名稱或 IP 位址；位址欄一般不應包含網頁協定前綴、路徑或整段查詢參數。連接埠應填在獨立的連接埠欄位。若既有資料提供的是完整分享連結，請優先使用匯入方式，不要任意拆出一部分填寫。IPv6 位址本身就包含冒號，手動輸入時尤其要分清位址與連接埠，不可依照最後一個看似分隔符的冒號猜測。
名稱或備註主要用於本機辨識，不是驗證憑證。可以依用途與來源命名，但不要把密碼、完整訂閱位址或私鑰放進名稱。儲存後重新開啟項目，核對 Type、位址、連接埠與驗證欄位是否一致。輸入框顯示遮罩不代表內容正確；複製貼上帶入的前後空格也不一定容易察覺，請依原始資料逐項比對。
協定專屬參數必須成套相符
Shadowsocks 需要核對加密方法與密碼，兩者必須與伺服器端一致。VMess、VLESS 等類型則須留意各自的識別欄位與傳輸設定，不可把某種協定的密碼概念套用到其他協定。Trojan 也需要核對驗證資訊與 TLS 相關設定。目標不是找出一組通用參數，而是準確還原既有服務提供的參數。
TLS 的伺服器名稱、連線位址與傳輸層 Host 可能相同，也可能刻意設為不同值。連線位址決定首先連到哪裡；伺服器名稱用於 TLS 身分驗證；Host 或路徑則可能屬於上層傳輸。不要為了讓三者「看起來一致」就全改成伺服器 IP。尤其連線位址使用 IP 時，正確的伺服器名稱仍可能是網域，必須依原始資料保留。
WireGuard 的私鑰、公鑰、介面位址、對端位址等欄位各有用途，不應將整段設定隨意塞進單一輸入框。Hysteria2 的驗證與 TLS 參數也須符合伺服器設定；本機網路能否正常使用 UDP 則是另一個層面的條件。傳輸特性的說明請參閱Hysteria2 與 QUIC 說明，但仍須逐項核對參數。
| 欄位組別 | 核對內容 | 常見錯誤 |
|---|---|---|
| 位址與連接埠 | 連線目標與監聽連接埠 | 將整段網址填入位址欄 |
| 驗證 | 密碼、識別碼或金鑰 | 漏字元、多餘空格、欄位填錯 |
| TLS | 啟用狀態與伺服器名稱 | 用連線 IP 取代驗證網域 |
| 傳輸 | 類型、路徑與 Host | 擅自加上斜線或更改大小寫 |
儲存後逐層驗證，不要同時修改多個參數
首次手動填寫完成後，先確認伺服器網域能否解析，再檢查是否能建立傳輸連線，最後確認目標請求是否經過預期路徑。驗證失敗、TLS 驗證失敗與連線逾時是不同問題。遇到逾時不要立刻更換密碼；出現驗證錯誤也不要先改規則。若介面提供具體錯誤訊息，記下錯誤類型及發生階段，比只記錄「無法使用」更有助於排查。
不建議把停用憑證驗證當成通用修復方法。這可能掩蓋伺服器名稱填錯、裝置時間異常或遠端憑證異常等真正原因。正確順序是先核對原始資料、裝置時間與連線目標，再檢查傳輸設定。只有在了解選項的意義、適用範圍與風險時才調整，並在測試紀錄中註明，避免日後把暫時性的診斷設定誤當成正常設定。
若伺服器由訂閱產生，直接編輯可能在下次更新時被遠端內容覆蓋。需要測試時，可在介面支援的情況下保留獨立副本，註明用途，並避免與訂閱原項目使用相同名稱。每次只修改一個欄位，測試後再決定保留或還原。確認手動紀錄有效後，再將差異納入既有服務參數的核對流程，不要靠長期維護多個來源不明的副本來解決問題。
03 / IMPORT
掃碼與剪貼簿匯入的檢查順序
Scan QR Code 只改變輸入方式
QR Code 只是文字的承載形式，內容可能是單一伺服器連結、訂閱位址，也可能只是一般網頁。使用 Scan QR Code 前，先確認 QR Code 對應的是自己的訂閱或伺服器資料。成功辨識只代表讀取到文字，不代表內容適用於目前入口，更不表示其中的伺服器已通過連線驗證。掃碼後先查看辨識出的資料類型，再決定是否儲存。
使用相機掃碼時，系統可能會要求相機權限。若先前拒絕過，可在系統的 App 權限設定中檢查，不必反覆重新匯入列表。調整拍攝距離、避免反光並確保 QR Code 完整，有助於區分辨識問題與格式問題。若 QR Code 邊緣遭裁切、顯示過小或被其他圖案遮住，辨識器可能無法讀取完整內容；這與伺服器參數是否正確無關。
QR Code 與 App 位於同一部裝置時，可使用實際介面提供的圖片辨識入口；若目前介面沒有此功能，請複製原始連結，改用剪貼簿匯入。不要為了掃碼而把包含憑證的圖片上傳到公開辨識頁面。需要留存的 QR Code 圖片也應視為憑證檔案管理，不能因為它看起來像圖片，就當作一般說明截圖隨意轉傳。
剪貼簿匯入：先檢查原文，再確認結果
複製時盡量只選取完整連結，不要連同介紹文字、編號、項目符號或句末標點一起複製。系統詢問是否允許讀取剪貼內容時，確認這次操作是自己發起後再授權。若 App 沒有讀到預期內容，可回到文字來源重新複製，並檢查剪貼簿是否已被後續複製的驗證碼、搜尋詞或其他內容取代，不要立刻認定匯入功能失效。
批次文字可能包含多個分享連結，但不同來源的分隔方式不盡相同。不要預設所有含換行的內容都能一次匯入。先用其中一個完整連結測試，確認類型與欄位無誤後再處理整批。若匯入結果少於預期，檢查空白行、斷行與說明文字，並保留原文以供比對；重複點擊匯入可能只會新增重複項目，無法修復遭截斷的連結。
訂閱位址匯入後應建立可更新的紀錄；單一伺服器連結匯入後通常只會新增獨立項目。若原本希望日後自動取得列表更新，結果卻只看到一般伺服器，請重新確認複製的是哪一類資料。反之，掃描訂閱 QR Code 後出現一組項目也不必意外，但仍應確認相應的訂閱紀錄是否保留，不能只憑列表數量判斷匯入方式。
依「辨識、解析、連線」分階段排除問題
第一階段是辨識：相機或圖片辨識能否擷取完整文字。第二階段是解析：目前的 App 能否辨識擷取出的協定格式，重要欄位是否齊全。第三階段才是連線：伺服器是否可連線、驗證是否通過、請求是否符合預期規則。若 QR Code 完全沒有反應，先處理第一階段；若項目已經出現但連線失敗，反覆更換掃碼方式通常沒有幫助。
匯入後立即開啟新項目的編輯頁面，特別檢查 Type、位址、連接埠、驗證與 TLS 設定。不同解析方式對連結中擴充參數的支援可能不完全相同，因此「已儲存」不能取代人工核對。若既有資料明確要求的路徑、伺服器名稱或傳輸方式沒有顯示，請先補齊或重新取得正確格式的資料，再進行實際連線測試。
若出現「不支援此格式」之類的結果，先確認複製的是原始連結，而不是通訊 App 包裝後的跳轉頁面。不要改用其他協定前綴強行匯入，也不要刪除看不懂的查詢參數。參數往往會影響 TLS 或傳輸行為，刪除後即使能儲存，也可能變成意義不同的紀錄。格式檢查可接著參閱下一章；連線階段的問題則請參考疑難排解。
匯入完成後，確認新項目的歸屬，刪除意外產生的重複紀錄，並清除不再需要的憑證圖片。可用一般無關文字取代剪貼簿中的敏感文字，但這不代表其他裝置或 App 已儲存的副本也一併清除。如果完整連結曾傳送到不受控的位置，應依既有服務的管理流程更換相關憑證，而不是只刪除本機匯入項目。
05 / UPDATE POLICY
訂閱更新策略與失敗還原
更新會改變列表，不只是重新整理畫面
訂閱更新會重新向原位址請求資料，並依回傳結果更新相關伺服器紀錄。遠端可能新增、移除或修改項目，因此更新不只是「再測一次連線」。更新前要區分列表變化與連線狀態變化：成功取得資料不代表列表中的每台伺服器都可用；舊伺服器仍能連線，也不代表訂閱位址的驗證依然有效，兩條連線可能各自發生變化。
不要假定手動修改過的訂閱項目一定會保留。遠端紀錄與本機紀錄的對應方式，可能受名稱、識別資料及 App 處理方式影響。需要長期保留的手動調整，應透過獨立紀錄或支援的本機管理方式保存，並註明它不是遠端原始內容。否則下次更新後，將難以判斷欄位是遭到覆蓋、項目被重建，還是選到了另一個同名伺服器。
更新前至少確認目前使用哪個訂閱、哪台伺服器，以及是否有可還原的備份。對已穩定運作的環境，不必同時更新所有裝置。可先在一部裝置上更新，查看變化並完成驗證，再處理其他裝置。這樣既能確認新列表的實際影響，也能在意外發生時保留原始狀態作為比對，不會讓所有裝置同時失去基準。
依變化頻率安排更新時機
更新頻率應依既有服務的要求與列表變化頻率決定，不是越頻繁越好。短時間內反覆向同一位址發出請求，可能觸發遠端限制，也會讓排查紀錄失去時間脈絡。若介面提供自動更新選項，先了解實際用途與觸發條件，並確認網路需求。行動系統的背景排程也會受裝置狀態影響；設定更新間隔不代表一定會準時執行。
手動更新適合首次新增訂閱、收到既有服務的變更通知、懷疑列表過期，或需要在維護時段控制變更時使用。更新完成後，請查看項目變化、目前選取狀態與實際連線，不要只確認重新整理動作是否結束。若原項目已移除，請重新選擇列表中仍存在的項目並驗證；不可因名稱相似就假定新項目保留了原有連線參數。
訂閱取得資料時所使用的網路路徑，也可能影響更新結果。若伺服器可連線但訂閱更新失敗，先檢查目前本機網路是否能存取訂閱資源、網域解析是否正常，以及位址是否需要獨立驗證。切換網路可作為對照測試，但每次只改變一項條件並記錄結果。不要為了取回列表而隨意修改整份 Config，以免混淆更新路徑與一般連線。
先分類錯誤，再決定是否還原
連線逾時通常表示請求未能在允許時間內完成，但原因可能是網域解析、網路路徑或遠端回應問題，不能只憑「逾時」兩字判定原因。若出現驗證相關錯誤，先檢查完整位址是否遭到修改、憑證是否仍有效，以及既有服務是否要求重新產生連結。若回傳的是網頁或驗證頁面，即使網路請求成功，用戶端也可能無法將其解析為伺服器列表。
解析錯誤與空列表也應分開處理。解析錯誤可能來自格式變更、內容遭截斷或欄位不受支援；空列表則可能表示遠端確實沒有回傳可用項目。保留原始位址與錯誤資訊，查看既有服務說明；必要時在保護憑證的前提下核對回傳內容類型。不要反覆將空結果匯入其他訂閱群組，也不要在沒有備份時用它覆蓋所有現有紀錄。
更新後若只有部分伺服器失效，先比對這些項目的協定、位址與傳輸方式是否有變化，再測試列表中的其他已知項目。不要因為單一項目失敗就刪除整個訂閱，也不要用大量重試掩蓋問題。若新增項目與目前網路條件不相容，保留可用項目並查明原因，比反覆匯入同一個訂閱更容易得到明確結論。進一步分類請參閱疑難排解。
一次更新應以「完成列表檢查並驗證重要用途」作為結束條件，而不是等重新整理動畫停止就算完成。記錄成功與失敗的階段、保留必要的還原資料，並確認下次自動更新不會立即覆蓋暫時修正。若憑證已更換，也要檢查自己的其他裝置是否仍使用舊位址，逐台更新，以免把不同裝置的舊結果誤認為同一次更新造成的變化。
06 / ORGANIZE
多筆訂閱整理與規則引用
先保留來源資訊，再安排顯示順序
同時管理多筆既有訂閱時，首要任務是知道每個伺服器項目來自哪筆訂閱，而不是把所有項目排成更長的列表。建議為訂閱取穩定、簡短且能區分用途的名稱；來源與用途放在訂閱層，具體差異則寫在伺服器備註中。不要用不斷變動的測試結果作為名稱，否則下次更新或排序後，很難用同一名稱找到同一個項目。
命名可採用「用途—來源代號—補充說明」的結構；來源代號由自己訂定，不必包含完整網域或帳戶資訊。若兩筆訂閱回傳同名項目，先保留各自的來源，再判斷是否確實重複。名稱相同不代表位址、驗證與傳輸參數也相同；名稱不同也不代表底層連線目標不同。去重應以重要欄位為依據，不要只比對顯示名稱。
手動新增的伺服器應與訂閱產生的紀錄清楚區分。可在備註中標明它是獨立紀錄、測試副本或需要長期保留的項目，並註明何時需要重新核對參數。不要把暫時修正的副本長期當成唯一可用紀錄，卻忘了原訂閱仍會持續更新。來源清楚後，才能判斷哪些變化由遠端維護、哪些應由自己負責，避免彼此覆蓋。
伺服器列表與 Global Routing 各有用途
整理列表不會自動改變流量的比對方式。Global Routing 的 Config、Proxy、Direct 是不同的運作模式：Config 依目前設定決定請求去向；Proxy 將一般流量交由所選代理路徑處理；Direct 則直接連線。實際請求仍可能受系統限制或相關設定影響，排查時不可把這些狀態視為完全相同的開關。
若目前處於 Direct，即使選取伺服器並整理好順序，也不能據此判定請求已經經過該伺服器；若處於 Config，還須查看規則是否將測試目標交給 PROXY。切換模式可作為對照，但測試完成後應恢復日常設定。不要為了讓特定目標暫時可用，就忘記目前已離開原本的規則分流方式，導致後續判斷混亂。
以下片段是 Shadowrocket .conf 的規則語法範例，僅說明規則順序與流向，不含任何伺服器憑證。規則通常依序比對，前面已符合的請求不會再由最後一行重新決定。範例網域沒有實際測試用途；將片段加入自己的設定前，先檢查現有規則位置與策略引用，避免重複的最終規則遮蔽後續內容。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY整理時也要控制變更範圍
若 Config 中的策略群組引用特定伺服器名稱或篩選條件，改名、移動或刪除項目都可能改變可選成員。整理前先檢查 Config 是否有這類關聯，再決定是否統一命名。訂閱更新後，某個策略群組變成空的，也可能是遠端改名導致篩選條件不再符合，而非整筆訂閱失效。請依序確認「訂閱是否有項目、條件是否符合、策略目前選取項目」來排查。
| Global Routing | 排查時應留意 | 整理無法取代的工作 |
|---|---|---|
| 配置 Config | 規則順序與策略引用 | 確認請求實際符合的規則 |
| 代理 Proxy | 目前選取的代理路徑 | 確認協定與目標是否可用 |
| 直連 Direct | 本機網路直連結果 | 證明已使用特定伺服器 |
若某些項目只是造成畫面雜亂，先查看介面是否提供篩選或摺疊等顯示方式，再決定是否刪除。刪除遠端仍會回傳的伺服器，下次更新後可能又會出現；反覆手動刪除並非穩定的管理方式。若使用名稱篩選，須確認範圍，避免誤將名稱相似的可用項目一併排除；遠端名稱變更後也要重新檢查結果。
在多部裝置間同步整理結果時，不要把「排列一致」當成「設定完全一致」。不同裝置可能連接不同網路、使用不同 Config，也可能只有其中一部保留手動項目。移轉前先列出真正需要一致的內容，例如訂閱位址、重要規則與預設選擇；本機測試結果與暫時排序則未必需要複製。這樣能減少備份內容，也能避免把過時狀態帶到另一部裝置。
建議每次集中整理完成後，確認三件事：重要用途仍有明確可選的項目、策略引用仍有對應成員、備份說明能解釋新的命名方式。不要一次合併、改名、去重又更換規則，最後才測試；請依訂閱逐組處理，每組驗證完成後再繼續。整理結果只有在清楚可解釋、能夠還原時，才比原本冗長的列表更容易維護，而不只是表面上較整齊。
07 / CONNECTIVITY TEST
延遲測試、排序與實際可用性
先確認測試項目
Connectivity Test 的結果取決於具體測試方式、測試目標與目前網路環境。有些測試主要測量建立連線所需時間；另一些也會測量透過代理存取目標時的回應。閱讀數值前先確認使用的測試方式，不要把不同方法的結果放在同一尺度比較。較低的時間值只能描述該次測試中的某個階段，不能直接代表持續傳輸速度或所有 App 的使用體驗。
延遲、吞吐量與穩定性是不同面向。網頁首次開啟會受解析與建立連線影響；大檔案傳輸更受持續吞吐量影響；通話或互動則可能對抖動與封包遺失較敏感。測試排序適合縮小排查範圍，不能取代實際用途驗證。選好候選項目後，仍應以自己的實際使用情況觀察連線是否穩定，不能只因列表排在最前面就忽略其他異常。
測試逾時也不代表單一原因。可能是伺服器無法連線、測試目標未回應、目前網路限制某類傳輸，或 App 使用的測試方式不適合該路徑。若只有測試失敗但實際請求正常，先核對測試目標與方法；若測試與實際請求都失敗，再檢查協定、驗證與網路路徑。分別記錄兩種結果，能避免把測試端點問題誤判為所有伺服器都失效。
建立可比較的測試條件
比較伺服器時，盡量使用同一部裝置、同一個網路、同一種測試方法與同一個目標，並避免背景同時進行大量傳輸。先選少量候選項目測試一輪，隔一段時間再測一次，觀察結果是否大致一致。單次偶然的低值或逾時，不足以證明長期品質。特別是在行動網路切換或裝置從休眠恢復後，先確認目前網路狀態再解讀結果。
全列表測試可能同時發出大量請求，測試本身也會占用資源。項目很多時，可先依既有用途或協定篩選，再分組測試，不要連續反覆測試全部項目。正在開會、下載或執行其他重要工作時，不宜將大量測試與實際使用混在一起。若測試後出現短暫波動，先停止重複測試，再觀察原有連線，避免把負載增加誤認為遠端持續異常。
若要判斷本機網路的影響，可在 Wi-Fi 與行動網路之間進行受控比對，但不要同時更換伺服器與規則。若某個協定只在其中一種網路下異常，應進一步檢查網路條件，而不是直接刪除該協定的所有項目。Hysteria2 等使用 UDP 的傳輸，尤其要區分本機網路條件與伺服器參數；排查方式可參考速度慢的分層排查。
排序只是顯示方式，不保證連線
依延遲排序後，先確認目前選取的伺服器是否改變。顯示在首位、處於選取狀態，以及實際由策略使用，是不同狀態；不能只看列表位置判斷連線對象。若使用 Config 中的策略群組，也要檢查群組選取的是否為另一筆紀錄。排序後進行一次實際請求測試並查看相關紀錄，才能確認流量走向符合預期。
測試結果會隨環境變化，長期保留的數值也可能失去參考價值。裝置更換網路、訂閱更新位址或伺服器傳輸設定改變後，應重新測試重要候選項目。不要把舊排序視為永久優先順序，也不要把遠端提供的名稱當成效能保證。日常維護紀錄應註明測試條件，不要只截取一個沒有前後文的數值。
若所有項目都同時逾時，先暫停逐一更換伺服器，檢查本機網路是否正常、系統連線是否建立，以及測試目標是否可連線。若只有某筆訂閱的項目失敗，則比對其更新狀態與共同參數；若不同訂閱中的同一協定都失敗，則留意本機網路與該協定設定。依共同特徵分類，通常比逐一重建更快縮小範圍，也能保留原始證據。
最終選擇應以實際用途為準，而不是追求單一的最低數值。保留少量已在目前網路驗證過的候選項目，確認它們各自來自哪筆訂閱，並在連線異常時以相同條件重新檢查。不要只因一次測試結果就大量刪除紀錄；先確認問題能否重現，再決定是否整理或更新。只有可重現的比較結果，才足以支持長期維護決策。
08 / BACKUP & RESTORE
刪除、備份與還原驗證
刪除前先確認項目與影響範圍
刪除單一伺服器、整筆訂閱或 Config，影響的對象各不相同。若刪除的伺服器仍由訂閱提供，下次更新後可能再次出現；刪除訂閱紀錄後，相關列表可能依操作範圍一併移除；刪除 Config 則可能影響規則與其他設定。執行前先閱讀確認提示，檢查目前選擇是否依賴該項目，不要只因名稱相似就批次處理。
清理重複項目時，先確認判定重複的依據。兩筆紀錄即使位址相同，也可能使用不同連接埠、驗證方式或傳輸設定；兩筆訂閱即使回傳相同名稱，也可能有不同用途。暫時無法判斷的項目，先保留並加上清楚備註，比立刻刪除更穩妥。若策略群組有引用該項目，也應先修改引用或確認替代項目，否則列表縮短後，設定中的候選成員可能變成空集合。
在本機刪除紀錄，不代表遠端已撤銷權限。訂閱位址若已外洩，刪除 App 中的紀錄不會讓他人持有的副本失效；伺服器密碼或私鑰也是如此。若需撤銷存取權限，應使用既有服務的憑證管理流程，再更新自己所有裝置上的紀錄。本機清理處理的是儲存範圍，遠端更換憑證處理的是存取權限，兩者不能互相取代。
備份須涵蓋資料，也要註明範圍
備份前先列出需要還原的項目：訂閱位址、獨立手動伺服器、Config 檔案、策略選擇，以及不容易重新記住的本機調整。App 提供的匯出或備份入口可能涵蓋不同範圍，不能假定一個檔案就包含所有內容。查看實際選項與說明，完成後存放在可控管的位置，並記錄這份備份包含哪些項目、哪些內容仍需手動重新設定。
訂閱位址可用於重新取得列表，但不能取代手動伺服器與規則設定的備份。反過來說，舊列表即使包含伺服器參數，也不保證日後仍能取得遠端更新。完整的還原計畫應同時考量可重新取得的資料，以及只能從本機還原的資料。對原本由訂閱產生的項目，不必為了保留顯示順序而建立大量獨立副本，以免日後失去維護來源。
備份檔案、匯出的分享連結與 QR Code 都應視為敏感資料。請選擇自己可控管的儲存位置，限制存取範圍，不要將完整檔案附在公開求助內容中。若匯出入口提供加密或密碼保護，先了解實際保護範圍，並將還原所需密碼保存在另一個可靠位置。不要只把唯一的還原密碼存在即將重設或更換的裝置上。
| 資料 | 還原用途 | 額外核對事項 |
|---|---|---|
| 訂閱紀錄 | 重新取得遠端列表 | 位址與憑證是否有效 |
| 獨立伺服器 | 還原手動填寫的參數 | 協定與驗證欄位是否完整 |
| Config 檔案 | 還原規則與設定 | 策略引用是否仍有對應成員 |
| 維護說明 | 說明命名方式與暫時調整 | 哪些調整應保留或還原 |
以實際驗證結果確認還原完成
換機或重新安裝後，先取得 App，再依備份範圍還原資料。iPhone / iPad 的 App 取得與訂閱還原是兩個不同流程：還原已購 App 不代表伺服器資料也已完整還原。其他平台也請從全平台下載頁進入，再確認備份格式與目標平台實際支援的匯入方式。不要假設某平台的整套備份可不經檢查直接套用到另一平台。
還原時建議先匯入 Config 與既有資料，確認項目齊全後，再依實際依賴順序處理策略引用與目前選擇。若目標裝置已有部分紀錄，先備份現況，避免未經規劃地合併新舊資料。遇到同名項目時不要立刻批次去重，先比對來源與參數。確認一組資料正確後再繼續，可減少還原過程中難以解釋的重複與覆蓋。
首次還原後，不要立刻刪除舊裝置上的所有資料。先確認訂閱能否更新、手動伺服器能否開啟編輯頁、重要規則是否存在，以及 Global Routing 是否處於預期狀態，再進行一輪實際用途驗證。系統可能要求重新授權連線功能，這類授權狀態不應視為一般備份欄位；請依目前裝置的提示完成授權，並在連線後檢查實際狀態。
還原測試也應包含一次失敗情境檢查：若訂閱更新失敗，是否知道原始資料存放位置；若某台伺服器遭移除，是否還有其他已驗證的選項；若設定引用失效，是否找得到相應規則與策略。備份的價值不只在於檔案能否匯入，也在於發生變化時仍知道如何恢復必要功能。只保存檔案卻不清楚其中內容，無法形成可靠的還原方案。
最後清除暫存匯出檔、過期 QR Code 與不再需要的副本，並保留一份內容清楚、可供日後查閱的維護紀錄。若曾更換憑證，請檢查舊備份是否仍含有不宜繼續散布的資訊，並依自己的保存方式處理。日常操作請回到快速入門使用說明；具體錯誤請查閱疑難排解。下次進行大範圍更新、整理或移轉前，再依本章檢查備份範圍與還原流程。