Shadowrocket
訂閱與伺服器管理

先分清訂閱、伺服器與 Config

訂閱網址用於取得一組伺服器記錄，用戶端之後可再次向該網址送出請求，取得新增、移除或參數變更的內容。單筆伺服器記錄描述一個連線端點，通常包含協定、位址、連接埠與驗證資訊。Config 則負責設定與規則等內容。三者可能來自同一份服務說明，但用途不同；將 Config 網址填入伺服器訂閱欄位，不一定能取得可用清單。

開始操作前，先確認手上的內容是完整的訂閱連結，而不是帳戶頁面網址、介紹頁面或單一伺服器的分享連結。訂閱連結請向你的服務商取得，並依照對方提供的 Shadowrocket 使用說明選擇對應格式。不要只看網址是否以常見副檔名結尾來判斷類型；有些訂閱會由動態網址回傳內容，實際解析結果取決於回應內容。

在 Add Server 中選擇 Subscribe

前往 Home，開啟 Add Server，在 Type 中選擇 Subscribe，再將完整網址填入 URL。替這筆記錄設定容易辨識的名稱，建議使用用途或來源標記，避免在備註中寫入帳戶資訊。介面配置可能因裝置與應用程式的顯示狀態而異，操作時請以目前畫面上的欄位為準；重點是確認 Type 已切換為 Subscribe，而非仍停留在某種單一伺服器協定。

貼上後，先從頭到尾檢查一次。網址開頭的協定部分、網域、路徑及問號後的參數都要保留，結尾不可混入中文句號、引號或換行。部分通訊工具會將長連結折行顯示，畫面折行不一定會改變原文，但手動分段複製容易漏掉中間內容。請盡量使用原始複製功能，不要看著截圖逐字輸入網址。

1. 確認 Type 為 Subscribe，URL 為完整訂閱網址。
2. 儲存後返回 Home，確認出現對應的訂閱記錄或伺服器群組。
3. 等待讀取完成，確認伺服器已歸入預期的訂閱，不要只看名稱是否出現。
4. 選取一筆記錄查看欄位，再繼續連線與測試。

如何確認匯入是否完成

儲存入口、請求訂閱、解析內容與產生伺服器清單是不同階段。入口儲存成功，只能表示本機已建立記錄，無法證明已讀取遠端內容。若只看到訂閱名稱，卻沒有伺服器，先確認更新是否完成，再檢查回傳內容是否為空或無法解析。不要連續重複新增相同網址，否則會留下多筆入口，後續排查時難以確認正在更新哪一筆。

清單首次出現後，抽查一筆記錄的 Type、Address、Port 與驗證欄位是否符合現有資料。名稱通常只是說明文字，不能取代參數核對。匯入後的伺服器數量與原始說明不同，也不應立刻判定是用戶端遺失資料；遠端訂閱可能依帳戶狀態或使用範圍回傳不同內容。確認網址與帳戶狀態後，再向你的服務商確認該網址應回傳哪些記錄。

如果訂閱本身可以讀取，但某筆伺服器連線失敗，請前往參數與測試章節，不必重新建立整份訂閱。若完全沒有產生記錄，則依序檢查連結完整性、請求結果與內容格式。這兩類問題發生在不同階段，分開記錄可避免反覆切換連線開關，測試尚未匯入完成的清單。

本章說明如何將遠端清單加入本機。關於何時更新、更新是否會覆蓋本機編輯，以及清單為空時應保留哪些資訊，請見更新方式；若要依完整連線流程操作，可返回快速入門教學繼續。

區分連線端點與顯示名稱

已有一組明確參數、需要新增單筆伺服器記錄時，適合手動新增。在 Home 開啟 Add Server，先選擇 Type。不同協定顯示的欄位會有所不同，因此不要先填完所有內容才切換類型。切換後務必重新檢查驗證與傳輸選項，避免欄位被清空，或舊輸入在新協定下被解讀成其他內容。

Address 是伺服器位址，通常填入網域或 IP 位址；Port 是連線連接埠，必須使用資料中提供的數值。不要將含路徑的網頁網址直接填入 Address，也不要從位址結尾猜測連接埠。顯示名稱只用於辨識清單，可依用途命名，但名稱中的協定文字不會改變實際的 Type。名稱正確但類型錯誤，仍無法建立預期的連線。

逐項核對驗證、TLS 與傳輸層

Shadowsocks 需依資料核對加密方式與 Password；VMess、VLESS 常見 UUID 欄位，但兩種協定不能只更換 Type 就沿用所有設定；Trojan 則要特別核對 Password 與 TLS 相關參數。HTTP、SOCKS5 的驗證要求也各不相同。欄位是否顯示、是否必填，應依所選協定與目前介面判斷，沒有一份通用表格適用於所有類型。

TLS、SNI、Host 與 Path 屬於不同層次。Address 決定連線目標；SNI 用於 TLS 連線中的伺服器名稱；Host 與 Path 則可能參與所選傳輸方式的請求。它們有時會使用相同的網域，但不一定相同。原始資料未提供的欄位，不要一律複製 Address 填入，也不要照著其他伺服器的設定自行補上。

遇到憑證相關錯誤時，先核對系統時間、SNI 與伺服器端憑證設定。Allow Insecure 會影響憑證驗證，不應當作一般修復方式任意啟用。憑證檢查失敗時，應查明失敗原因，而不是只讓錯誤提示消失。WireGuard、Hysteria2 等類型應完整使用各自對應的參數組，不要簡化成 Password 或 UUID 的對應關係。

儲存後以最少變更進行排查

填寫完成後，先返回編輯頁面再次檢查，尤其留意密碼前後空格、UUID 是否缺少字元，以及連接埠輸入是否正確。輸入法可能將半形標點替換成全形字元，手動抄錄時尤其容易出錯。如果資料可以複製，請優先複製原始值。發現錯誤時，一次只修正一個欄位，並記錄修改前後的狀況，避免同時調整多項設定而失去判斷依據。

如果相同伺服器透過分享連結可以正常匯入，但手動輸入的記錄失敗，可將兩筆記錄並排核對 Type、驗證、TLS 與傳輸層，不要先懷疑位址失效。比較時保留一筆原始匯入記錄作為參照，不要直接覆寫。反過來，若手動輸入成功、訂閱產生的記錄失敗，則可能需要確認訂閱內容是否仍含有舊參數。

儲存成功只代表欄位已接受，不表示驗證與遠端服務已通過測試。接著選取記錄執行 Connectivity Test，再檢查 Global Routing 與實際存取結果。Trojan 欄位關係可參閱Address、Port、Password 與 SNI 參數說明；不要將某種協定的範例當成其他協定的預設設定。

掃描前先確認 QR Code 的內容

QR Code 可以編碼單筆伺服器分享連結，也可以編碼訂閱網址，外觀無法判斷內容類型。掃描成功只表示已辨識圖像中的文字，不代表網址可存取或參數有效。若已有 QR Code，請先依原始說明確認它指向訂閱還是單筆記錄，再使用 Shadowrocket 畫面上可見的 Scan QR Code 功能。

首次啟用相機時，系統可能會要求相機權限。確認用途後再授權；若先前已拒絕，可在系統設定中檢查 Shadowrocket 的相機權限。掃描時讓 QR Code 完整進入取景範圍，避免邊緣遭到裁切、螢幕反光或圖片過度壓縮。QR Code 內容較長時，方塊會更密集，放大原圖通常比反覆將相機靠近更有效。

QR Code 顯示在目前裝置上時，可使用應用程式目前提供的圖片辨識功能處理；若介面沒有相應功能，請使用現有的原始文字連結匯入。不要為了繞過辨識問題而將 QR Code 上傳至不明網站解析，也不要重新製作含有真實憑證的公開圖片。保留原始 QR Code 是為了日後還原操作，不應將它當成可公開傳播的說明素材。

剪貼簿內容應保持單一且完整

使用剪貼簿匯入時，先從原始資料複製一筆完整內容，再返回 Shadowrocket，使用目前畫面上可見的剪貼簿匯入功能。若系統顯示貼上確認，請確認內容是剛才複製的資料。不要依賴剪貼簿中很久以前的內容；跨應用程式複製可能已覆寫內容，跨裝置剪貼簿也可能帶來與預期不同的文字。

複製範圍盡量只包含連結本身，不要附帶標題、編號、程式碼區塊或聊天訊息的引述符號。多筆連結混在一起時，應用程式能否一次辨識取決於實際格式；為方便核對，首次操作建議逐筆匯入。每次完成後檢查清單新增了哪些內容，再繼續下一筆，避免重複或錯誤記錄混在一起而難以追查。

1. 返回現有資料，複製原始連結或開啟原始 QR Code。
2. 選擇 Scan QR Code，或使用應用程式目前提供的剪貼簿匯入功能。
3. 在確認或編輯畫面辨識 Type，並檢查 Address、Port 等重要欄位。
4. 儲存後確認記錄歸屬，再執行測試；不要只看匯入提示。

若應用程式無法辨識剪貼簿內容，先確認它究竟是訂閱 URL、協定分享連結，還是一般說明文字。完整訂閱網址可返回 Add Server，選擇 Subscribe 後手動貼上 URL。單一伺服器連結則應依對應協定處理，不可為了讓介面接受輸入而一律改選 Subscribe。載體不同，不代表可以省略對內容類型的判斷。

分別處理辨識失敗與連線失敗

掃描沒有反應時，優先檢查圖像品質與權限；辨識後顯示格式不符時，優先檢查文字結構；伺服器已建立但無法連線時，才進一步排查欄位與網路。分開描述這三種情況，可以大幅縮短排查流程。例如「相機看得到圖案但沒有建立記錄」與「已建立 Trojan 記錄但驗證失敗」，需要檢查的內容完全不同。

匯入後若出現同名記錄，不要立刻刪除其中一筆。先確認它們是否來自不同訂閱，以及連接埠或傳輸方式是否不同。QR Code 標題通常只是方便辨識的備註，同名不代表參數相同。確認為重複記錄後，保留來源明確且可以還原的一筆，再依本頁刪除章節處理；尚未驗證前不要批次清理。

若要向他人描述問題，只需說明匯入方式、辨識出的 Type、錯誤發生階段及已完成的檢查，不要附上完整內容。匯入完成後，盡快複製其他不敏感文字，取代剪貼簿中的憑證；若懷疑內容已外洩，應向你的服務商取得替換後的資料，而非只在本機記錄中更改名稱。

協定前綴可提示解析方式

單一伺服器分享連結通常會帶有協定前綴，例如 ss://、vmess://、vless:// 或 trojan://。前綴可提示解析方式，後續內容可能是編碼欄位，也可能是含查詢參數的網址結構。看到前綴只能大致判斷類型，無法單靠目視確認驗證值、TLS 與傳輸層資訊完整無缺。

以常見結構來看，分享連結可能同時包含使用者資訊、主機、連接埠、查詢參數與備註。不同協定及產生方式的組織格式不盡相同，不能用一種協定的拆解方式處理所有連結。最穩妥的做法是保留原文，由 Shadowrocket 解析，再到編輯頁核對可見欄位，而不是先在文字編輯器中自行改寫。

https://example.com/sub?token=xxxx
trojan://[email protected]:443?security=tls&sni=example.com#Example

以上僅呈現訂閱 URL 與單一伺服器連結的外觀差異，內容皆為教學用假資料，並非可用的連線資訊。問號後方通常是查詢參數，井字號後方常用作備註，但仍應以實際協定格式為準。連結中的百分比編碼也有其作用；將編碼字元換成看似較易閱讀的文字，可能改變密碼、路徑或備註的實際內容。

編碼不等於加密，訂閱也不是規則檔案

部分連結或訂閱回應會使用 Base64 等編碼來表示內容。編碼的用途是表示資料，並不代表憑證受到保密保護。即使一長串字元無法直接閱讀，也應視為完整密碼資料。排查時不要將整段內容貼到公開解碼工具，只需先確認複製內容是否完整、回應是否符合預期類型，以及應用程式能否正常解析。

訂閱回應可能包含多筆伺服器連結或其他支援的結構。以瀏覽器開啟時，部分內容看起來像文字，部分會觸發檔案儲存，另一些則會顯示登入頁面；這些狀況都無法單獨證明內容適用於目前的入口。如果實際回傳的是登入提示、錯誤說明或網頁內容，用戶端便可能無法建立伺服器，即使請求已送達遠端網址也是如此。

Config 中的規則片段則屬於另一種內容。以下展示常見的 Shadowrocket 設定結構，說明規則如何列在 [Rule] 下方。這不包含伺服器驗證參數，也不能取代 Subscribe 網址。只有在了解現有設定結構並確認修改範圍後，才將規則套用至自己的 Config。

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

匯入內容與實際路由仍須搭配

伺服器記錄決定「使用哪個連線端點」，Global Routing 則決定「流量如何選擇連線方式」。Config 模式依目前設定處理；Proxy 模式使用代理路徑；Direct 模式則直接連線。若剛匯入伺服器後仍使用 Direct，實際存取沒有經過該伺服器，並不代表匯入失敗。解讀測試結果時應一併考量目前模式，不要只看伺服器清單是否有選取標記。

在 Config 模式下，規則順序與目前啟用的設定同樣重要。範例中的 DOMAIN-SUFFIX 用於比對網域後綴，GEOIP 依 IP 位址的地理歸屬資訊判斷，FINAL 則是前面規則都未符合時的預設項目。不要只複製一行 FINAL 就認為已建立完整的分流策略，也不要把範例直接套用至所有網路環境。

若同一份資料同時提供訂閱與 Config，請分別確認兩者用途、更新方式與管理入口。更新伺服器清單不一定會更新規則檔案，切換 Config 也不一定會替換伺服器參數。請在備份說明中分別記錄兩者，日後遇到「清單正常但部分存取路徑不符」時，才能從正確層次開始檢查。

何時需要更新

伺服器端調整伺服器位址、驗證資訊或可用範圍後，本機清單可能仍保留舊內容，此時需要更新對應訂閱。更新主要用來同步遠端清單，不會提高目前連線速度。若只是某次存取逾時，先測試現有記錄與網路狀況，不要立刻同時更新所有訂閱、切換 Config 並重新連線，否則很難判斷是哪個步驟改變了結果。

使用應用程式提供的訂閱管理功能，更新目標訂閱並查看該群組的結果。若目前介面提供更新週期或自動更新選項，可依實際需要設定；不要假設應用程式會一直在背景執行，也不要因為沒看到更新提示，就認定系統已完成同步。需要確認重要變更時，手動更新一次並核對結果，比只根據時間推測更可靠。

更新前可記錄目前可用伺服器的名稱與重要參數，必要時另存備份。訂閱清單由遠端內容維護，更新後部分伺服器可能更名、移除或變更參數，這些都屬於同步結果。保留舊記錄有助於比對，但舊記錄能否繼續使用仍取決於遠端服務狀態；備份不代表延長其有效期限。

依請求、解析、使用三個階段定位

請求階段失敗時，先檢查目前網路是否正常，再確認 URL 是否含多餘空格或遭到截斷。若訂閱網址中的網域無法解析，問題發生在取得內容之前，反覆修改伺服器 Password 無法解決。也不要先刪除原有清單；保留記錄有助於判斷是遠端入口暫時無法存取，還是本機已儲存的伺服器也失效。

解析階段失敗時，應確認實際收到的內容。帳戶到期提示、存取限制提示或一般網頁，都可能取代原本應回傳的伺服器清單。用戶端無法從這些內容建立伺服器，不代表需要隨意更換協定類型。請先確認帳戶狀態與網址適用範圍，再向你的服務商取得確認後的訂閱資料。

清單已建立但無法連線時，應轉而檢查單筆伺服器參數與 Connectivity Test。訂閱更新成功不等於伺服器可用：清單中的端點可能正在維護，驗證資訊也可能與遠端狀態不一致。完整記錄「更新成功、記錄存在、測試失敗」比籠統描述「訂閱壞了」更有助於定位問題。

避免重複更新與覆蓋手動修正

短時間內頻繁更新通常無法改變錯誤的回應內容，反而可能觸發遠端存取限制。更新失敗一次後，先等待目前請求結束，確認失敗階段，再進行有目的的重試。切換網路進行比較時，一次只變更網路條件，不要同時修改 URL；只有變因明確，才能判斷問題與本機網路或遠端入口是否有關。

訂閱內的手動重新命名或參數修改，可能在下次同步時被覆蓋。臨時驗證時，可複製為獨立記錄並標明用途；若錯誤需要長期修正，應確認遠端訂閱內容，而不是每次更新後都重做本機修改。自動維護的前提是上游資料正確，手動修正無法取代這一點。

確認更新完成後，檢查目前選取的記錄是否仍存在，並重新執行測試。伺服器更名或移除後，不應只憑舊名稱判斷是否仍選取原本的端點。更完整的逐項自我檢查，請閱讀訂閱更新失敗或清單為空的檢查清單；其他連線問題請見疑難排解。

依維護範圍安排訂閱

管理多筆現有訂閱時，首先要保留清楚的來源區分。每個訂閱入口都應使用獨立名稱，方便判斷要更新或刪除哪一組，以及某筆伺服器是由哪份遠端清單產生。不要將不同入口都命名為「預設」或「常用」，也不必把完整訂閱 URL 寫入備註；這會增加截圖或日常展示時洩漏憑證的風險。

建議使用穩定的用途說明，例如「日常連線」、「備用連線」或「測試記錄」，再於個人私密的管理說明中記下入口與用途的對應關係。若已有命名習慣，應優先維持一致，不必為了排序而反覆改名。名稱中標示某個地區或用途，也無法證明伺服器的實際行為；仍須依現有資料與測試結果核對。

同一訂閱重複匯入後，可能出現名稱相近的多組記錄。處理前先比較入口、伺服器欄位與更新狀態，不要只看群組名稱。兩個不同 URL 也可能回傳重疊清單，而同一入口在不同帳戶狀態下也可能回傳不同結果。整理的目標是減少不必要的副本，不是強行合併所有看起來相似的記錄。

分開管理訂閱產生的記錄與手動記錄

訂閱產生的記錄適合隨遠端內容更新；手動記錄則適合保存獨立提供的參數或進行臨時核對。兩類內容可以並存，但名稱或群組應能區分。若為了排查而將訂閱記錄複製成獨立記錄，建議在備註中說明它是本機副本，並記下複製原因；如此一來，原訂閱更新時才不會誤以為副本也已同步。

臨時副本最容易逐漸變成難以說明的舊記錄。每次排查結束後，都應明確決定要繼續保留、更新說明，還是刪除。若選擇保留，應說明它與原記錄的差異，例如修正了 SNI 或改用資料指定的連接埠。不要只標註「可用」，因為這沒有記錄當時的網路與參數，換個時間便難以重現。

若目前應用程式提供依訂閱檢視、篩選或摺疊清單的功能，可先縮小維護範圍再修改。執行批次操作前，確認篩選條件與實際選取範圍，尤其注意篩選後隱藏的記錄是否也包含在選取範圍內。若無法確定，先挑一筆非重要記錄確認操作效果，再處理其他內容，避免一次變更整份清單。

選取、排序與規則引用並非同一件事

清單中的位置只會改變顯示順序，通常不代表目前的連線選擇。將某台伺服器移至最上方後，仍須確認 Home 中實際選取的記錄。若 Config 涉及策略或群組，也應檢查規則最後使用的目標。畫面上的「第一筆」與路由中的「目前目標」是不同概念，整理時不要混為一談。

若設定依賴特定名稱，重新命名或刪除相關記錄可能影響後續選擇與維護。修改前先查看 Config 的關聯內容，保留舊名稱與新名稱的對應關係。對不熟悉的設定，不要同時批次改名與修改規則；先完成伺服器清單整理並驗證，再另外檢查設定，如此發生錯誤時才能縮小復原範圍。

在 iPhone 與 iPad 上維護同一批資料時，可沿用相同的群組說明，但不要假設兩部裝置的排序、選取項目與同步狀態完全一致。每部裝置都應分別核對入口與目前選取項目。整理完成後保留一份簡短清單，註明哪些內容會隨訂閱更新、哪些需要手動維護，比只存一張伺服器清單截圖更有助於還原。

先了解測量內容

Connectivity Test 用於觀察伺服器在目前測試條件下的連線狀況。實際測量內容取決於應用程式目前使用的測試方式與目標；不要將所有以毫秒顯示的結果都視為同一種指標。網路路徑、網域解析、遠端端點與測試目標都可能影響結果，因此不同時間、不同網路下的數字不應直接當成相同條件比較。

延遲主要反映某個測試階段所花費的時間，不會直接表示持續傳輸速度，也無法保證所有網站都能正常存取。某筆記錄測試較快，實際請求仍可能遇到驗證、TLS、規則或目標網站問題。測試逾時也不一定表示整台伺服器永久無法使用；請先確認測試方式是否適合目前環境，再搭配實際存取情況判斷。

開始比較前，記錄目前使用的是 Wi-Fi 或行動網路，確認沒有大量傳輸正在進行，並保持測試目標與方式一致。若只想比較伺服器差異，就不要同時切換網路與 Global Routing。測試結果要能比較，仰賴穩定的測試條件，而不是一次看似理想的數字。

少量重複測試以辨識穩定性

先測試目前選取的一筆記錄，確認操作可以完成，再依需要測試同一組中的其他記錄。連續結果有波動時，觀察變化是只出現在單筆，還是整組同時發生。整組同時變慢，應優先檢查本機網路或共同路徑；只有單筆持續失敗，則優先檢查該端點的參數與遠端狀態。不要只憑一次結果就刪除記錄。

測試完成後，應依實際用途進行一次存取驗證，並確認流量路徑符合預期。Global Routing 設為 Direct 時，存取成功不能證明伺服器正常運作；在 Config 模式下，部分請求也可能依規則直連。必要時檢查應用程式中可見的相關記錄，避免將直連成功誤認為代理連線已通過驗證。

實際存取失敗時，盡量描述發生階段，例如網域無法解析、連線等待、TLS 錯誤或收到遠端回應。不同階段需要不同檢查：解析問題先檢查 DNS 與路徑，驗證問題先檢查憑證，規則問題先檢查 Config。反覆按下測試按鈕只會重複相同觀察，無法取代對錯誤階段的分析。

排序有助於選擇，但不能取代判斷

若目前介面提供依延遲排序，可在完成一輪測試後使用，避免新舊結果混在一起。尚未測量、測試失敗與有效結果的排序方式可能不同，排序後仍應查看個別狀態。清單第一筆只代表目前排序條件下的位置，並非長期固定的最佳選擇；網路狀況改變後，原有排序結果可能不再具有參考價值。

日常使用可保留少量已驗證記錄作為候選，其他內容依歸屬摺疊或整理。這樣既保留替換空間，也可減少每次測試整份清單的負擔。候選記錄的選擇依據應包含連線穩定度、參數來源明確性與實際存取表現，而不只是延遲。測試是輔助選擇的工具，不用於評價任何服務商。

若已確認某筆伺服器與模式組合可用，可先維持這個基準，再逐項檢查異常記錄。不要在保留基準前批次更新、刪除或重新命名，否則失去比較依據後，難以判斷問題是來自新變更，還是原有網路。模式選擇詳情請見Global Routing 功能說明，常見連線問題請見疑難排解。

刪除前先確認操作範圍

刪除單筆伺服器、刪除整個訂閱入口與移除 Config 是不同操作。若刪除單筆記錄，而它是由訂閱產生，下次更新時可能再次出現；刪除訂閱入口則可能連帶影響該群組的伺服器。操作前請閱讀目前的確認提示，弄清楚影響的是單筆記錄還是整組內容，不要憑長按位置或清單外觀推測範圍。

若只是暫時不使用某筆記錄，可以先改選其他已驗證的記錄，不必立即刪除。確定要清理時，先確認它不是唯一可用的連線，也沒有被現有設定引用。對來源不明的本機副本，先確認是否已保存原始參數；沒有還原資料時，刪除會讓排查從可供比對的狀態，變成只能重新蒐集資料。

從清單移除內容，不會撤銷已洩漏的憑證，也不代表遠端帳戶狀態已變更。若因懷疑訂閱網址或密碼外洩而進行清理，應向你的服務商取得替換後的資料，並依照對方流程處理舊憑證。本機刪除只會移除目前裝置上的記錄，無法取代遠端憑證更新。

備份應涵蓋三個層面

第一層是訂閱入口與來源說明，第二層是獨立新增的伺服器參數，第三層是 Config 與需要保留的規則設定。只保存訂閱網址，可以重新取得遠端清單，但不一定能還原手動記錄與規則；只匯出 Config，也不能假設其中包含所有訂閱憑證與應用程式設定。請依實際匯出內容確認涵蓋範圍。

若應用程式提供 iCloud 同步或匯出功能，先查看目前可用選項及完成狀態，再判斷是否足以滿足換機需求。啟用同步不代表所有內容已傳送至另一部裝置，也不代表誤刪後一定可以復原。同步著重多裝置狀態一致，備份則著重保留可還原的副本；重要變更前仍應另外保存一份資料。

備份檔案、QR Code 與分享連結都可能包含驗證資訊，應存放在只有必要人員能存取的位置。不要為了方便查找而放進公開文件或公開相簿。為資料註明用途與內容即可，不必將密碼抄在檔名中。儲存後實際檢查檔案能否開啟、內容是否完整，避免換機時才發現存下來的是空檔或一般網頁。

依序還原購買、匯入、選取與驗證

在新 iPhone 或 iPad 上，先透過 App Store 確認並還原已購買的應用程式；購買適用範圍與系統需求請以 App Store 頁面標示為準。應用程式的購買記錄只用於取得應用程式，不保證伺服器、訂閱與 Config 會自動還原。購買相關步驟請見已購項目還原說明，不要把重新購買當成資料遺失的處理方式。

1. 確認應用程式來自正確的 App Store 產品頁，並完成首次開啟。
2. 還原同步資料或匯入備份，檢查訂閱、獨立記錄與 Config 是否齊全。
3. 視需要更新訂閱，並確認目前選取的伺服器與 Global Routing。
4. 完成 Connectivity Test 與實際存取後，再考慮清理舊裝置資料。

還原後若出現同名記錄，先判斷各自來自同步、匯出還是重新匯入，不要立刻批次去重。可先保留一組已驗證的資料作為基準，再清理多餘副本。若新裝置與舊裝置的使用狀況不同，應逐項比較目前網路、Config、伺服器欄位與系統授權狀態；不能只因清單名稱相同，就認定兩邊設定完全一致。

更詳細的移轉順序請閱讀設定備份、iCloud 同步與換機還原步驟。日常維護時，將更新與刪除分成兩個獨立步驟：先確認新資料有效，再清理舊內容。如此可保留明確的回復路徑，也讓下次排查有完整且可說明的起點。