Shadowrocket 訂閱與伺服器管理

01 / 匯入可更新的清單

Subscribe 入口與管理對象

先分清訂閱、伺服器與設定檔

訂閱是一份可重複取得的伺服器清單；伺服器是一筆具體的連線紀錄；設定檔則決定要求如何比對規則，以及交由哪個策略處理。三者彼此相關，但並不相同。訂閱更新成功，只代表清單已成功取得並解析，不代表選取的伺服器可以連線；伺服器可以連線，也不表示目前設定檔已依預期分流。排查前先確認正在處理哪個對象，才能避免把規則問題誤認為訂閱問題。

在 Home 查看目前的伺服器及其所屬訂閱，在 Config 管理設定相關對象。依照本手冊的操作流程，進入 Config 尋找 Subscribe 入口；如果目前平台將新增訂閱整合在 Home 的加號入口，請在 Add Server 中選擇 Subscribe 類型。不同平台的入口層級可能不同，請以表單類型和 URL 欄位為判斷依據，不要只照著另一台裝置的按鈕位置操作。

新增前先確認連結用途

訂閱網址請向你的服務供應商取得。先閱讀連結附帶的說明，確認它是供 Shadowrocket 使用的伺服器訂閱，而非帳號管理頁面、說明頁面或完整規則設定檔。瀏覽器能開啟某個網址，不代表用戶端就能將回傳內容解析為伺服器清單。若連結包含身分參數，請完整複製，不要刪除問號後的內容，也不要一併複製聊天軟體附帶的標點符號。

https://example.com/sub?token=xxxx

在 Subscribe 表單中填入方便辨識的名稱和完整 URL，儲存後執行更新。首次匯入時請維持網路穩定，等待結果後返回 Home，確認是否出現伺服器紀錄、紀錄數量是否符合你現有資料的範圍，以及名稱是否可讀。成功與否不以固定數量判定；服務端調整清單後，結果也可能改變，請以你獲授權的內容及服務端說明為準。

依結果判斷失敗階段

儲存後沒有伺服器，先確認用戶端是否真的向該網址送出要求。若名稱已出現但清單為空，可能是取得失敗、回傳內容為空，或格式無法解析。若出現驗證問題，請檢查連結是否已更換、到期或複製不完整；若回傳的是網頁內容，請確認取得的是訂閱介面，而非登入頁面。不要把同一個失敗網址重複新增為多個訂閱，只會多出需要清理的空白群組，不會改變要求結果。

若只出現部分紀錄，請檢查缺少的紀錄所用協定與參數是否受目前平台支援，以及訂閱是否本來就只回傳部分內容。此時先保留可正常讀取的結果，記下失敗情況，再對照現有伺服器資料。不要為了讓清單看起來完整而自行填入未知的密碼、連接埠或傳輸參數；這些欄位必須與服務端相符。猜測填入的紀錄即使能儲存，也不一定能建立連線。

已有伺服器紀錄但連線異常時，不必立刻刪除訂閱重建。先選取其中一筆，完成後文的單筆測試，再檢查 Global Routing。如此可分開驗證「取得清單」與「使用流量」。需要循序完成首次操作時，請參閱使用教學；本頁後續章節則分別說明欄位、更新與整理，適合帶著具體問題查閱。

02 / 核對單筆紀錄

Add Server 手動填寫欄位與協定參數

先選擇 Type，再依原始資料填寫

手動填寫適用於你已掌握完整伺服器資料，且需要單獨檢查某筆紀錄的情況。在 Home 開啟 Add Server，先選擇 Type，再填寫該類型顯示的欄位。選擇協定後，後續表單欄位也會跟著改變，因此不要先把所有資料填入預設表單，最後才切換類型。儲存前請逐項對照原始資料，尤其要留意複製內容是否帶入空格、換行、全形冒號，以及連接埠是否誤填到位址欄位。

Address 通常填寫伺服器網域或位址，Port 則單獨填入連接埠；不要在 Address 前加上網頁協定前綴。網域與瀏覽網頁時使用的路徑是不同概念，路徑應填入相應的傳輸設定。使用 IPv6 時，請區分分享連結中的方括號格式與表單實際要求；如果表單已將位址和連接埠分開，就不要再貼上整段「位址加連接埠」。名稱僅供辨識，無法修正連線參數。

欄位相似，不代表可以互換

Shadowsocks 的加密方式與密碼必須同時相符，不能只因密碼相同就認定設定正確。VMess、VLESS 常使用 UUID，但相同 UUID 不代表兩種協定可以互換；傳輸方式及其附加欄位也必須一一對應。Trojan 的驗證資料應填入相應的密碼欄位；HTTP 與 SOCKS5 則要確認是否啟用了帳號驗證。若未提供選填項目，請先保留預設值，不要從其他紀錄複製一組看似完整的設定。

TLS 開關、SNI、Host 和 Path 各有不同用途。Address 決定要連線到哪裡；SNI 是加密交握時使用的服務端名稱；Host 可能是應用層要求資訊；Path 則用於相應的傳輸路徑。這些欄位有時看起來相同，但不代表這是通用規則。若原始資料提供不同值，請分別保留；不要為了讓表單整齊而強行統一，也不要把網頁顯示的重新導向網域直接填成 SNI。

Hysteria2、WireGuard 等類型也可能需要特定驗證或金鑰資料。只有在訂閱已正確提供這些參數，或你持有完整服務端設定時，才適合新增。遇到無法確認的欄位，請先回到原始資料確認其含義。為了順利儲存而填入任意字元，只會建立一筆外觀完整的紀錄，無法證明協定已正確設定。各協定的基本差異可參閱協定概覽。

透過最少變更找出欄位錯誤

儲存後先選取這筆伺服器進行測試，暫時不要同時調整 DNS、規則和連線模式。若測試失敗，依序排查位址解析、連接埠連線、驗證和傳輸參數。位址錯誤常會造成無法解析；連接埠或網路問題可能造成連線逾時；驗證或交握失敗則需進一步查看具體提示。錯誤提示只能縮小排查範圍，不能取代逐欄核對；例如連線遭拒，可能是連接埠填錯，也可能是服務端未在該連接埠監聽。

需要修正參數時，每次只修改一個有明確原因的項目，並記錄修改前後的值與結果。手動新增的紀錄最好使用「手動」等明確名稱，與訂閱產生的項目區分。若只是要驗證某個參數，請先複製紀錄再修改副本；確認有效後，再決定是否保留。若不清楚更新方式，不要直接修改訂閱項目，否則下次更新可能還原原值，讓已完成的排查失去比較依據。

03 / 從現有資料建立紀錄

Scan QR Code 與剪貼簿匯入

先確認 QR Code 實際包含的內容

QR Code 是承載文字的方式，不是獨立協定。內容可能是單筆伺服器分享連結、訂閱網址或一般網頁。開啟 Scan QR Code 後，請先查看辨識結果和待儲存對象，確認內容與你的資料相符。掃描成功只代表讀取了圖片中的文字，不能證明目標網址可用，更不能證明其中的驗證資料仍有效。不要把出現掃描提示當成伺服器已連線。

從另一個螢幕掃描時，盡量讓完整 QR Code 顯示在取景範圍內，避免反光、遮擋或過度縮放。若需要相機權限，只要在使用掃描功能時依系統提示授權即可；若拒絕了權限，可到系統的應用程式權限設定中檢查。已有 QR Code 圖片時，優先使用目前介面提供的圖片辨識功能；若平台沒有此功能，匯入原始文字通常比反覆調整圖片更直接。

若辨識結果是訂閱網址，請將它儲存為 Subscribe 來源，而非填入伺服器的 Address。若辨識出的是單筆伺服器，儲存後請檢查 Type、Address、Port 和驗證欄位。QR Code 通常只包含其中編碼的內容；畫面上還有其他文字，不代表用戶端也讀取了旁邊的所有說明。特別留意 QR Code 下方另列的密碼、備註或傳輸要求，這些內容可能沒有編碼在其中。

剪貼簿匯入時保留內容邊界與編碼

剪貼簿匯入適用於你已複製完整分享連結的情況。請先從原始訊息複製連結本身，再使用 Home 或新增選單中顯示的剪貼簿匯入功能。系統詢問是否允許貼上時，確認內容是剛才複製的資料後再允許。若未出現預期紀錄，先確認剪貼簿內容是否已被其他複製動作取代；不要直接把匯入失敗歸因於協定不受支援，實際複製到的內容可能只剩標題或說明文字。

聊天軟體可能會將長連結折行顯示，但畫面上的換行不一定是實際換行。複製後要分辨兩者：若文字中真的插入換行或空格，協定解析可能會在中途截斷。也請檢查開頭是否缺少協定前綴、結尾是否多了中文句號，以及連結是否被富文字格式轉成顯示名稱。無法確認複製結果時，請重新從原始文字取得連結，不要靠猜測逐字補齊遭截斷的內容。

批次匯入文字時，先確認目前入口支援多筆紀錄，再使用結構清楚的內容。若一次複製整篇包含標題、說明和多個連結的訊息，可能造成誤判，或只處理第一筆。首次可先匯入一筆並核對欄位，再處理其餘內容。若曾匯入同一批資料，再次操作前請先查看現有清單，避免把重複紀錄誤認為訂閱更新後增加的伺服器，也讓後續測試與排序更容易辨識。

匯入後核對三個項目

第一，核對紀錄類型，確認 Subscribe 沒有被存成單筆伺服器，單筆伺服器也沒有被誤存為一般 URL。第二，核對重要欄位，尤其是密碼、UUID、SNI 和傳輸路徑。第三，確認紀錄的歸屬，確定它位於預期群組，而非混入其他訂閱。完成這三項後再測試連線，就能將文字辨識與實際通訊分開檢查，更容易判斷問題出在匯入流程還是伺服器本身。

掃描後若出現陌生網域或與原始資料不符的參數，請停止儲存並重新核對來源內容。現有訂閱連結可能包含存取憑證，不適合轉傳到公開群組或提交至公開辨識網站。排查時可以描述「QR Code 可辨識但儲存後是空白」等情況，不必將完整內容交給他人。需要展示圖片時，請遮住 QR Code 本身；只遮住旁邊的文字，無法隱藏圖案中編碼的連結。

四種匯入方式與適用入口，可搭配訂閱匯入方式說明查閱。匯入後若紀錄數量不符，請回到本頁第一章檢查訂閱對象；若只有其中一筆失敗，請進入第二章逐項檢查參數，避免反覆掃描同一張圖片而新增重複項目。

04 / 辨識文字結構

分享連結格式與 Config 的界線

協定前綴只代表起始類型

分享連結通常以協定前綴開頭，後續內容則包含位址、驗證資料、傳輸參數與備註。不同協定的編碼方式各異，即使前綴相同，參數的表示方式也可能不同。辨識前綴有助於選擇匯入入口，但不能只看開頭就判斷整條連結正確。匯入後請檢查欄位，確認用戶端解析出的內容符合你的原始資料；若參數遭到忽略，畫面上仍可能出現紀錄，但無法依預期連線。

連結中的查詢參數通常用來表示傳輸方式、加密連線或其他設定；井號後的部分則常用作備註。備註中的中文、空格和特殊符號可能經過百分比編碼，驗證資料也可能使用 Base64。不要為了讓文字更容易閱讀，就先手動解碼再貼回；也不要重複編碼已經編碼的部分。某些字元在不同位置具有不同意義，不必要的替換就可能改變整條連結的結構。

不要混用訂閱、分享連結與規則

訂閱 URL 指向可更新的內容；單筆分享連結通常描述一台伺服器；Config 則描述連線以外的行為。收到以 HTTPS 開頭的網址時，應配合原始說明判斷它回傳什麼，不要一律當成 Subscribe 新增。收到包含區段名稱和規則行的文字時，也不要當成多筆伺服器連結匯入。這些內容可以搭配使用，但儲存位置和更新方式各不相同；選錯入口不會自動將內容轉換成另一種對象。

[General]
bypass-system = true

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

這段內容是用來說明語法的規則片段，不包含伺服器驗證資料。DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對位址範圍，FINAL 則處理前面未符合的要求。規則通常由上而下判斷，由最先符合的規則決定處理方式，因此較具體的比對條件應放在較寬泛的預設備援規則之前。範例中的 PROXY 必須搭配可用的代理選項；只寫上這個策略名稱，不代表伺服器已自動新增。

Global Routing 中的設定、代理與直連，分別對應 Config、Proxy、Direct。使用 Config 時，排查重點是目前設定檔中的規則；使用 Proxy 時，應先確認所選伺服器能否正常運作；使用 Direct 時，即使清單中有伺服器，要求也不會自動交由它處理。測試訂閱是否可用時，請一併記錄目前的連線模式，否則同一份清單在不同模式下可能得到完全不同的存取結果。

分享前先確認憑證的揭露範圍

伺服器分享連結可能包含完整密碼或 UUID；訂閱網址也可能具有持續取得清單的權限。將內容轉成 QR Code、縮短顯示名稱或重新編碼，都不會降低其敏感性。需要在自己的裝置間移轉時，請使用可控的傳遞方式，並確認接收裝置可信。需要求助時，優先提供協定類型、錯誤提示與已遮蔽的欄位，不要在公開截圖中直接放入完整可連線紀錄。

同一連結從不同入口匯入後若欄位不一致，請保留原始文字和兩份解析結果以便對照。先檢查是否發生截斷、跳脫或編碼變更，再確認目前平台是否能辨識相關參數。不要把缺少欄位一概歸因於連結失效，也不要隨意刪除不認識的查詢參數。逐項說明每個修改的原因，比湊出一條能儲存的長連結更重要；無法確認時，請回到原始資料核對格式。

05 / 管理清單變更

訂閱更新方式與失敗復原

將更新視為一次範圍明確的替換

訂閱更新是用戶端重新向來源送出要求、解析回傳內容並更新相關紀錄的過程，不是重新測試所有項目的延遲，也不是更新 Shadowrocket 應用程式。服務端可能新增、刪除或重新命名伺服器，用戶端則依自身的比對方式處理現有紀錄。開始前請先確認哪些資料來自訂閱、哪些是你自行修改的，尤其是備註、目前選取項目，以及供規則引用的名稱，以免更新後無法判斷變化是否正常。

第一次使用時，先手動更新並確認能穩定取得內容，再考慮使用目前平台提供的自動更新設定。自動更新間隔不必一味設得越短越好；頻繁送出要求無法修復錯誤網址，還可能觸發來源端的限制。若沒有自動更新選項，依需要手動重新整理即可。不論採用哪種方式，都應在重要使用情境前預留檢查時間，不要在必須維持連線時，同時更換來源並大量更新。

更新前後的四個檢查重點

更新前記錄來源名稱、目前選取的伺服器、是否有手動修改，以及目前的網路狀態。更新後先查看是否顯示成功，再確認清單是否有明顯變化，接著確認原先選取的項目仍存在，最後進行單筆連線測試。紀錄數量變化不必立刻視為錯誤，但清單突然變空或大量名稱異常時，應暫停後續操作。保留原始來源和既有備份，比立即刪除重建更有助於判斷變化來自服務端還是本機。

若你曾直接修改訂閱項目中的參數，更新時可能會覆蓋這些修改。需要長期保留的修正，適合另存為獨立手動紀錄並註明用途，同時保留原訂閱作為對照。不要因為某次更新恰好沒有覆蓋備註，就認定所有欄位都會永久保留。不同欄位和平台的處理方式可能各異，請透過一次可控的更新確認實際結果，不要同時在大量項目上測試。

依取得、驗證與解析階段逐一排查

更新逾時時，先確認裝置目前的網路是否正常，再判斷訂閱要求是否依賴某條已失效的代理路徑。取得訂閱所用的路徑未必與一般網頁瀏覽相同，請查看目前平台提供的相關設定。可在可控的環境下切換網路後重試，但不要同時更換網路、規則和來源網址；否則即使更新成功，也無法確認是哪個因素改變了結果，下次失敗時仍難以重現。

若出現驗證失敗或存取遭拒，請檢查網址是否完整、身分參數是否遭重設，以及來源是否仍允許你的帳號存取。若提示要求過於頻繁，請停止重複重新整理，稍候再依來源說明操作。若回傳登入頁、提示頁或空白內容，用戶端可能會顯示解析失敗；這與伺服器清單中的單筆節點逾時不同，應從訂閱要求本身排查，修改單筆伺服器的連接埠無法解決問題。

如果同一來源以前可以更新，現在卻無法解析，請確認回傳格式是否變更，以及新複製的網址是否指向不同用途的介面。不要把網頁另存為本機檔案後，就當成有效清單；也不要從其他格式任意拼湊欄位。保留錯誤原文、發生時的網路環境，以及是否所有來源都失敗等資訊，通常比反覆重新安裝更有幫助。若只有一個來源失敗，請優先檢查該來源，不必清空所有訂閱。

更新完成後檢查設定檔引用

伺服器名稱變更可能影響你原本辨識或選取項目的習慣；若使用自訂策略，也應檢查引用關係。更新後雖然看得到紀錄，存取卻突然改走其他線路時，應同時核對目前選取項目與 Config，而不只是查看清單頂端的名稱。長期使用的規則應清楚記錄其依賴關係，並保留可還原的設定檔副本。將訂閱維護與規則維護分開處理，可降低一次更新造成多處變更的風險。

06 / 保持歸屬清楚

多個訂閱的整理方式與本機修改界線

名稱應標示歸屬，不只是位置

管理多個現有訂閱時，先為各個來源設定穩定且容易區分的名稱。可依個人用途或資料歸屬命名，不必把完整 URL 放進標題，更不要在備註中記錄密碼或身分參數。伺服器備註則用於辨識單筆紀錄，可保留原始名稱並加上簡短說明。來源名稱與伺服器名稱負責不同層級的識別；分清楚後，才能更準確地查找失敗範圍、處理重複項目或刪除整組內容。

第一次整理時不要立刻合併所有來源。先逐一確認能否更新、清單大致範圍，以及是否有獨立手動新增的項目，再決定顯示順序。多個來源出現相同名稱，不代表它們是同一台伺服器；名稱不同，也不代表位址與驗證資料一定不同。判斷是否重複時，應一併考量來源歸屬、協定、位址、連接埠和重要參數，不能只看清單中的一行文字就批次刪除，更不應為了統一名稱而修改驗證資料。

區分遠端維護與本機維護的內容

訂閱產生的紀錄適合交由來源更新維護；手動建立的紀錄則適合保存你明確掌握的獨立資料。若需暫時調整某筆訂閱項目進行測試，請先複製或建立標示清楚的副本，並記錄修改原因。如此既能保留原始紀錄作為參照，也能避免下次更新覆蓋測試參數。測試結束後請及時清除無效副本，否則容易與實際可用的紀錄混在一起，讓清單看似豐富卻難以管理。

群組、收藏與排序等功能，請以目前平台實際提供的選項為準。若沒有獨立收藏功能，可透過清楚的備註與來源歸屬進行基本整理，不必自行假設有額外的管理層。也不要把清單的顯示順序當成策略優先順序：將某台伺服器拖到最上方，通常不代表 Config 會自動選取它。真正決定要求去向的是目前的選取項目、Global Routing 與設定檔中的策略關係，需分別檢查。

清理重複項目前先比對差異

相同位址與連接埠可能對應不同協定、驗證資料或傳輸參數，不能只因這兩項相同就認定完全重複。反過來，同一分享連結重複匯入，也可能因備註不同而出現多筆紀錄。清理時先比對重要欄位，再確認是否來自同一來源。確認重複後，優先保留可正常更新且歸屬清楚的一筆；若涉及手動修正，先在自己的維護紀錄中記下修正原因，再決定刪除哪一份。

若某個來源暫時無法更新，但既有伺服器仍可使用，可以先保留並註明目前狀態，不必立刻移除。若來源已停止使用，請檢查設定檔是否仍引用其中的名稱，以及目前連線是否依賴這組內容。整理時應保留還原方式，避免將「暫時失敗」、「重複」與「確定不再需要」混為一談。逐組處理雖然稍慢，卻能留下清楚可追溯的變更紀錄。

跨裝置保持規則一致，不必追求清單外觀相同

同一個訂閱在不同裝置上，可能因平台功能、顯示方式或本機手動項目而呈現不同清單。管理目標應是來源正確、重要參數一致、選取邏輯清楚，而不是要求每台裝置的列數和順序完全相同。移轉後先檢查原始來源，再檢查單筆紀錄，最後檢查 Config。若某種協定在目標平台上的欄位不同，請對照目前介面和原始資料處理，不要將另一台裝置的截圖視為唯一表單標準。

07 / 解讀測試結果

Connectivity Test、延遲與排序

先了解測試涵蓋到哪個階段

延遲結果來自某次具體測試，不是對伺服器整體品質的永久評價。不同測試可能只檢查連接埠是否可連線，也可能透過代理存取指定目標；測試協定、目標網址、目前網路和並行數量都會影響結果。使用 Connectivity Test 或清單測試功能前，請先查看目前平台提供的測試方式與設定。只有測量條件相近時，結果才適合比較；否則將不同測試的數值放在一起排序，容易得出錯誤結論。

連接埠可連線，不代表驗證一定成功，也不保證目標網站能透過代理開啟。反過來說，某個測試目標沒有回應，也不一定代表所有存取都不可用。若出現「測試有結果但網頁無法開啟」，應繼續檢查驗證、TLS、傳輸設定、DNS 和規則；若「測試失敗但實際存取正常」，則先檢查測試目標及其存取路徑。不要只憑一個符號就刪除紀錄，先確認測試涵蓋了哪個環節。

建立可重複的比較條件

先選一筆已知可正常運作的紀錄作為對照，在相同網路、相近時間內測試其他候選項目。測試期間盡量暫停大量傳輸工作，避免裝置正在下載或同步而影響結果。批次測試可縮小範圍，但大量並行會增加本機網路與服務端負載；若結果明顯異常，再針對少數候選項目單獨重測。某次測得的低延遲，只代表當時對該目標的回應較快，不能直接推論持續傳輸速度也較高。

切換 Wi-Fi 與行動網路後，原有排序可能不再適用，因為連線路徑和解析環境都已改變。與其每天保存一份固定的「最快」清單，不如保留少數用途明確的候選項目，並在實際環境改變後重新檢查。記錄測試條件時，可註明網路類型、測試方式和大致情況，不必在公開紀錄中附上完整位址與驗證資料。可重現的現象比單次孤立結果更有助於排查。

排序與實際選取是兩回事

依延遲排序只會改變顯示順序，不應預設它已切換目前伺服器。排序後請返回 Home，明確確認目前選取的紀錄，再開始測試存取。如果設定檔使用策略群組或其他選取邏輯，還要檢查該策略最後指向哪個項目。清單第一列、目前選取項目，以及某條規則使用的策略可能是三個不同對象；忽略這項差異，就容易誤以為「明明選了較快的，卻沒有變化」。

測試規則分流時，可先用 Proxy 驗證所選伺服器能否正常連線，再返回 Config 檢查規則比對結果；Direct 可用來區分直連與代理環境，但直連成功不能證明伺服器可用。每次切換後都要確認目前模式，避免測試結束後忘記還原原本設定。Global Routing 與診斷項目的詳細說明，請參閱功能說明；首次連線失敗也可查看教學中的排查步驟。

保留足夠的診斷線索

需要進一步排查時，請記錄是所有紀錄還是個別紀錄失敗、問題發生在更新還是連線，以及是否只在特定網路出現，並保留已遮蔽敏感資料的錯誤原文。不要只寫「無法連線」，也不要為了證明問題而公開完整分享連結。若同一筆紀錄在另一台裝置上正常，請比對兩端實際儲存的參數和目前模式，不要立刻重設所有設定。先比較差異，再逐項修改，通常更容易找出可解釋的原因。

08 / 建立可還原的維護流程

刪除、備份與跨裝置還原

刪除前確認對象與影響範圍

刪除單筆伺服器、刪除訂閱來源與刪除 Config，造成的影響各不相同。刪除伺服器紀錄後，若該紀錄仍由訂閱維護，下次更新時可能再次出現；刪除來源後，相關紀錄是否一併移除，請以確認提示為準；刪除設定檔則可能改變規則行為，即使伺服器清單仍然存在。操作前先看清對象名稱和確認內容，不要把所有清理按鈕都當成同一種「移除」，尤其不要在目前連線依賴該對象時直接刪除。

若只是暫時不使用某個來源，先確認目前平台是否提供合適的停用或顯示管理選項；若沒有，可保留來源並清楚標示用途，不必為了縮短清單而立刻移除。確定要刪除時，先確認仍持有有效的原始資料和還原方式。刪除不會撤銷驗證權限；已外洩的連結即使從本機移除，其他裝置仍可能使用。這種情況需要透過原服務的管理管道重設相關憑證。

備份至少涵蓋三個層次

第一層是可重新取得的訂閱來源；第二層是獨立手動建立的紀錄及其完整參數；第三層是 Config、規則與必要的選取關係。只儲存訂閱 URL，無法保證還原手動紀錄和規則；只匯出規則，也無法補回伺服器密碼。使用目前平台提供的匯出或備份功能時，請閱讀說明並確認涵蓋哪些對象。匯出完成後，檢查檔案是否確實存在、名稱是否容易辨識，以及目標平台能否透過相應入口讀取。

備份檔案可能包含密碼、UUID、金鑰或訂閱身分參數，請存放在自己可控且有適當存取保護的位置。不要因為副檔名看起來一般，就把它當成可公開傳送的說明文件。備份也不適合與公開截圖、工作資料或臨時傳輸檔案混放。需要在自己的裝置間傳送時，請確認接收端，傳送後檢查內容是否完整，並清除不再需要的暫存副本，避免憑證長期散落在各處。

依序還原來源、紀錄與設定檔

移轉到另一台裝置時，先完成應用程式的取得與首次開啟，再匯入備份。iPhone / iPad 版在 App Store 一次性付費 $2.99；Mac / Windows / Android / Linux 版免費。平台選擇與安裝步驟請統一參閱下載指南。不必為了還原訂閱而直接覆蓋所有設定；先確認目標裝置上的既有資料是否需要保留，以免覆蓋新裝置上的獨立手動紀錄，造成另一種資料遺失。

還原後先查看來源名稱，再逐一手動更新，確認網址仍有效；接著核對獨立伺服器的重要參數，最後檢查 Config 與策略選取。舊備份可以還原過去的本機狀態，但無法保證遠端服務仍接受舊憑證，也無法保證已調整的伺服器仍然存在。因此，還原成功的標準不是「清單看起來和以前一樣」，而是來源可以更新、所需紀錄可以連線，且規則行為符合目前需求。

透過小範圍還原驗證備份

進行重要調整前，先儲存一份用途標示清楚的備份，再只修改一組內容。條件允許時，請用不影響現有工作的方式驗證匯入結果，不要等到裝置遺失後才第一次嘗試還原。若目前平台不方便進行獨立驗證，至少確認匯出範圍、檔案可讀性及原始資料是否齊全，並保留自己看得懂的還原順序。備份的價值在於能還原所需對象，不是檔案越多越好。

長期維護可固定採用「備份、修改、更新、測試、記錄」的順序。每次只處理一個目的明確的問題，成功後留下簡短說明；失敗時則還原上一個已知正常的狀態。用戶端一次性買斷 ≠ 線路方案；應用程式的取得紀錄也不能取代伺服器資料備份。返回本頁目錄時，可依目前對象選擇章節：來源問題查閱 Subscribe 與更新，單筆連線問題檢查欄位與測試，移轉和清理則依本章逐項核對。

返回手冊開頭 ↑ 查看快速入門教學 →