Shadowrocket 節點管理

01Subscribe：匯入既有訂閱

先區分訂閱網址與規則設定

Subscribe 用來從你已有的訂閱網址取得伺服器資料。一筆訂閱可能包含多個伺服器項目，匯入後通常會依來源分組，之後更新仍須透過原網址。訂閱與單一伺服器不同：伺服器項目儲存一次連線所需的位址、連接埠和驗證參數；訂閱則是取得這些項目的入口。先確認手上的資料屬於哪一種，再選擇匯入方式，避免把網頁說明網址誤當成訂閱網址。

Config 管理的設定檔主要包含規則及相關設定，不能因為同樣使用網址，就把它當成伺服器訂閱。某些完整設定也會包含伺服器或遠端資源，應依檔案實際內容判斷用途。若你拿到的是伺服器訂閱，請選擇 Type 為 Subscribe 的新增方式；若拿到的是規則設定，則到 Config 確認檔案用途，不要反覆更換入口碰運氣。

依欄位完成匯入

在 Home 開啟新增入口，進入 Add Server 後將 Type 設為 Subscribe，填入既有訂閱網址，並為此來源設定容易辨識的名稱。介面配置可能因裝置或 App 更新而異，請以 Type 和欄位名稱辨認入口。複製網址時務必選取完整內容，尤其留意查詢參數是否因聊天視窗換行、末尾標點或選取範圍而遭截斷；畫面上分成兩行，不一定代表網址內真的有換行。

儲存後，確認訂閱分組是否出現，以及分組內是否看得到伺服器項目。匯入時會先連線至訂閱網址，再解析回傳內容，因此「網址已儲存」和「伺服器已匯入」是兩種不同結果。若分組存在但內容空白，請檢查更新提示和回傳內容，不要立即判定伺服器無法連線。取得伺服器項目後，還需另外確認其驗證資料與連線狀態。

1. 確認複製的是自己的訂閱網址，而非帳戶頁面或說明頁面。
2. 選擇 Subscribe，填入網址和容易辨識的名稱，再儲存。
3. 確認分組和項目是否建立，並核對其中一台伺服器的參數。
4. 選取伺服器，依照使用教學選擇模式並實際測試連線。

匯入異常時，分別檢查取得、解析與連線

若取得訂閱失敗，先確認目前網路能否連上該網址，以及網址是否仍有效。若回傳的是登入頁面、驗證頁面或錯誤提示，儲存網址本身並不會讓這些內容變成伺服器清單。不要把帳戶密碼填入無關欄位，也不要為了測試把訂閱交給陌生網頁。訂閱網址通常含有存取憑證，應視為機密資料保管；排除問題時只描述錯誤類型，避免直接公開完整網址。

成功取得內容卻沒有可用項目時，請優先檢查格式與完整性。可對照原始說明，確認該網址是否提供 Shadowrocket 支援的訂閱內容，不要只憑副檔名判斷。若只有少數項目缺漏，先比較這些項目的協定與欄位，不要清空整個分組。必要時保留目前可用的內容，再明確手動更新一次，記下更新前後的差異，避免連續操作掩蓋最初問題。

匯入完成後，回到 Home 確認目前選取的伺服器是否屬於剛才的分組。查看某筆訂閱，不代表 App 一定會自動將其中某項設為目前連線。初次使用時建議只測試一筆已知項目，確認位址、模式和授權流程都正確後，再整理整組項目的排序。如此遇到問題時，才能清楚區分匯入失敗、選錯項目與連線失敗。

02Add Server：手動輸入伺服器參數

依協定類型填寫所需欄位

如果你已取得一台伺服器的完整參數，或需要核對自動匯入的欄位，可使用 Add Server。先選擇 Type，再填入該類型實際顯示的欄位。不要先填完某種協定的欄位後，只修改類型名稱：不同協定的驗證方式與傳輸參數並不相同，切換類型後可能出現新欄位，也可能留下需要重新確認的值。填寫前請保留原始資料以便核對。

Address 通常填寫伺服器網域名稱或 IP 位址，Port 則填寫伺服器實際監聽的連接埠。網域名稱不應自行加上網頁路徑；即使使用 TLS，連接埠也不能一概填入某個常見值。伺服器位址、TLS 的 Server Name 與傳輸層的 Host 可能相同，也可能各有用途；若原始資料分別列出，請各自填入對應欄位，不要為了「保持一致」擅自改成同一個名稱。

驗證、TLS 與傳輸屬於不同層次

Shadowsocks 的加密方式和密碼必須與伺服器端一致；VMess、VLESS 通常需要核對 UUID 及該設定要求的附加參數；Trojan 則需核對密碼與 TLS 相關資料。這些欄位不能互換。介面允許儲存，只表示欄位通過基本輸入檢查，不代表伺服器會接受驗證。若連線建立後很快中斷，應先重新比對原始參數，而非隨意更改加密或傳輸選項。

TLS 的用途與代理協定驗證不同。Server Name 通常用於憑證名稱驗證和伺服器名稱指示，不應當成備註填寫。遇到憑證錯誤時，請檢查名稱、裝置時間和原始設定是否一致，再確認伺服器憑證狀態。關閉憑證驗證會改變連線的信任界線，不應當作一般排錯步驟。原始資料未要求的選項，請保留 App 預設值或先確認用途，以免引入其他問題。

使用 WebSocket 等傳輸方式時，Host 和 Path 都屬於傳輸設定。Path 中的斜線、大小寫和查詢內容都可能影響伺服器路由，不可當成一般備註任意修改。若原始資料同時列出 TLS、傳輸方式和路徑，請逐項對應。Hysteria2、WireGuard 等類型也有各自的金鑰或連線參數，不適用其他協定的填寫方式；只填寫該 Type 實際需要，且原始資料明確提供的值。

儲存後先核對，再逐項測試

建議為手動新增的項目設定容易辨識用途的備註，例如「手動測試」，不要在名稱中放入密碼或完整金鑰。儲存後重新開啟編輯頁，確認類型、位址和連接埠都選對，尤其檢查複製內容前後是否含有空格。需要修正時，一次只修改一類參數，並記下修改原因。若同時更改連接埠、TLS 和傳輸方式，即使最後成功連線，也很難判斷是哪一項解決了問題。

自動匯入的伺服器也能透過編輯頁查看參數，但訂閱項目的本機修改可能在後續更新時被覆蓋。若要長期保留本機調整，請先確認 App 是否支援複製為獨立項目，並在名稱中區分原項目和測試副本。未經驗證前，不要直接修改唯一可用的伺服器。其他既有資料的匯入方式，請參閱新增節點的四種匯入方式。

03掃描 QR Code 與剪貼簿匯入

QR Code 只是資訊載體，並非另一套參數

Scan QR Code 讀取的是 QR Code 中編碼的文字，可能是伺服器分享連結、訂閱網址，甚至只是一般網頁。掃描後請確認辨識結果和匯入項目；成功讀取 QR Code，不代表伺服器參數一定正確。QR Code 中的協定、位址和驗證資料，與手動輸入 Add Server 後儲存的內容一一對應；兩種方式的差異主要在輸入流程，而非連線原理。

掃描前請先確認 QR Code 來自你已有的伺服器或訂閱資料，並避免將含有憑證的畫面投放到公共螢幕。使用相機掃描時，依系統提示授予所需權限；若尚未授權，請到系統設定確認，不要反覆點選掃描入口。若 App 提供從照片圖庫辨識的選項，可選取已儲存的 QR Code 圖片，但請保留完整邊界和清晰度，不要裁掉定位圖案，也避免使用過度壓縮的縮圖。

無法辨識 QR Code 時，先改善讀取條件：確保圖面完整、亮度適中，沒有反光或明顯模糊，再嘗試調整距離。若同一個 QR Code 一直無法辨識，但原始文字仍在，可改用文字匯入或手動填寫參數，避免反覆截圖造成更多資訊遺失。一張圖片中若有多個 QR Code，請一次只辨識一個；匯入後核對名稱和來源，避免重複新增卻誤以為內容已更新。

從剪貼簿匯入前，先確認複製範圍

從剪貼簿匯入適合已取得完整伺服器分享文字的情況。先只複製需要的連結，再回到 Shadowrocket，使用目前介面提供的剪貼簿匯入入口；若系統詢問是否允許貼上，請依實際操作確認。一般說明文字、聊天中的引號和連結末尾的句號都不是協定內容，混入後可能影響辨識。不要為求方便複製整段聊天紀錄，也不要預期 App 能自動判斷所有附帶說明。

批次文字應盡量維持一行一筆連結，並保留原始字元。請分辨畫面換行與實際換行：長連結在螢幕上自動折行通常沒有影響，但手動插入換行可能會把一筆內容拆成兩段。若只能匯入第一筆，先檢查其他項目是否使用相同且受支援的格式，以及項目之間是否有多餘分隔符號。若匯入失敗，先單獨測試一筆，確認方式正確後再處理整批內容。

匯入後的核對不可省略

無論透過 QR Code 或剪貼簿匯入，都應開啟其中一筆的編輯頁，核對 Type、Address、Port 和必要的驗證欄位。名稱只是備註，不能證明內容正確；同名伺服器可能使用不同位址，不同名稱也可能指向相同位址。若辨識結果是訂閱，請確認是否建立了可更新的來源分組，而不只是取得一次性的伺服器清單。需要長期更新的內容，必須保留正確的訂閱關係。

匯入完成後，可用不含敏感資訊的一般文字取代剪貼簿內容，減少日後誤貼的機會。不過，這無法確保其他裝置或歷史記錄中沒有副本；使用跨裝置剪貼簿時，也應留意同步範圍。儲存在照片圖庫中的 QR Code 同樣需要妥善管理，尤其不要放進公開共享相簿。刪除截圖只能減少後續散布，已外洩的憑證仍須透過原有管理管道處理。

若這次只是要將既有資料移轉到自己的另一台裝置，請先在接收端核對參數並測試連線，再清除中間文字和圖片。尚未確認新裝置可用前，不要提前刪除舊裝置上的唯一紀錄。完整移轉還涉及 Config、目前選取項目和按需連線設定，不能只憑「QR Code 匯入成功」就認定全部完成；詳細檢查順序請參閱刪除與備份。

04分享連結格式與設定界線

先看前綴，再判斷後續處理方式

伺服器分享連結通常使用與協定相關的前綴，訂閱網址則常見 HTTPS 網址。前綴有助於判斷內容類型，但不能單獨證明整筆內容有效。例如，使用正確前綴的連結仍可能缺少驗證欄位、連接埠或必要的傳輸參數。反過來說，HTTPS 網址也不一定是訂閱，可能指向帳戶頁面或一般檔案。匯入前應參照既有資料說明，確認內容代表伺服器、伺服器集合或設定檔。

這些前綴僅供辨識常見內容，不是完整的相容性清單。某些協定的分享格式有不同慣例，同一協定也可能使用不同編碼方式。App 是否能匯入，取決於完整內容及目前支援的參數組合，不能只看協定名稱。遇到不熟悉的格式，請優先保留原文，查看既有資料中的欄位說明，再於 Add Server 逐項核對，避免任意改寫後失去比對依據。

編碼、查詢參數與備註各有用途

分享連結中的驗證資料可能以編碼形式儲存。編碼不等於加密，也不表示可以公開傳送；任何能讀取連結的人都可能還原其中的伺服器憑證。遇到難以辨識的字串，不要任意加入空格、調整大小寫或刪除末尾符號。部分格式對這些字元很敏感，文字編輯軟體的自動取代也可能更動內容。若需比對，請使用原始純文字，避免依照截圖重新抄寫。

問號之後的查詢參數可能決定傳輸方式、TLS 或其他連線行為；井字號之後通常用作備註，但實際意義仍取決於該格式的約定。百分比編碼用於表示特定特殊字元，不要當成亂碼刪除。若中文名稱顯示異常，請先判斷問題是否只影響備註；若位址和驗證資料都正確，不要為了修正名稱而重新編輯整段編碼內容，可在匯入後單獨修改顯示名稱。

伺服器資料不會自動完成規則設定

匯入伺服器主要是解決「連線到哪裡、如何驗證」；規則設定則決定「哪些要求採用哪種策略」。兩者需要搭配，但不能互相取代。Config 中的規則通常由上而下比對，符合條件後採用對應策略；FINAL 用於前面規則都未符合的情況。以下規則語法範例僅供理解結構，不含伺服器憑證，也不是可直接取代現有設定的完整設定檔。

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

範例中的 PROXY、DIRECT、REJECT 是策略關鍵字。DOMAIN-SUFFIX 和 DOMAIN 的比對範圍不同，不能只按字面互換；GEOIP 涉及 IP 歸屬判斷，也不等同於依網頁語言分流。規則必須放在正確的設定檔章節，並搭配目前 Global Routing 的選擇一併檢查。若使用 Proxy 或 Direct 模式，不應只靠 Config 中某一條規則解釋所有連線結果。

若要深入調整規則，請繼續閱讀比對順序、FINAL 與策略說明。本章維護重點是分層保存資料：原始分享文字用於核對伺服器，訂閱網址供後續更新，Config 檔案則管理規則與相關設定。為三類資料分別命名，比合併成一段「通用連結」更容易排除問題，也能減少移轉時漏掉重要項目的情況。

05訂閱更新方式與結果核對

更新的是遠端內容，不只是時間標記

更新訂閱時，App 會重新連線至已儲存的網址，並依回傳內容更新相關伺服器項目。更新可能變更位址、連接埠、驗證資料或名稱，也可能新增或移除項目，因此不只是重新整理畫面。更新前先確認目前使用的分組和伺服器，必要時記下容易辨認的資訊。若正在排查連線問題，記錄更新前後的差異，比只記下「已按更新」更有幫助。

若已得知資料有變動、原有項目異常，或需要確認匯入結果，可手動更新。自動更新則適合日常維護；是否啟用及可選的更新間隔，請以目前 Subscribe 設定介面為準。不要假設每台裝置都會在固定時間完成背景請求；系統排程、網路狀況與 App 狀態都可能影響執行時間。需要確認最新結果時，仍應查看這次更新的實際回饋。

透過請求、解析、取代三個步驟理解結果

請求失敗時，先確認網址是否完整、存取憑證是否仍有效，以及目前網路能否連上該網址。伺服器連線失敗與訂閱網址無法存取是不同問題，兩者不一定使用相同的網路路徑。若原本可用的伺服器仍在，請先保留，不要因一次請求失敗就刪除分組重建。重建通常無法修復失效網址，反而可能讓你失去原有的可用紀錄和排錯線索。

請求成功後，仍須確認回傳內容能否正確解析。有些錯誤頁面也會正常回傳網頁內容，但並非伺服器清單，因此「網址可以開啟」不代表訂閱有效。若更新後分組突然變空，或內容與預期差異很大，請停止連續重新整理，回頭檢查原網址及其用途。排查時不必公開完整回傳文字，只要說明是伺服器資料、網頁提示或空白回應即可，避免洩露存取憑證。

取代完成後，重新確認目前選取的項目。項目更名或移除時，不要假設原本的選擇仍指向同一台伺服器；同名項目的內部參數也可能已改變。建議先檢查常用項目的位址與協定，再執行測試及實際連線。若只有某一項變更異常，請將問題限定在該項；只有整組都異常時，才進一步檢查訂閱取得、帳戶狀態或共用參數。

本機修改與訂閱維護應分開處理

手動修改訂閱項目的名稱或連線參數，可能被遠端內容覆蓋；實際保留方式請以更新結果為準。若需長期保留某項本機修改，不要只靠記憶，請記下修改欄位和原因，並標明這是本機例外。若 App 支援，可保留獨立副本供測試，但須與訂閱內原項目分別命名，避免下次更新後誤選測試副本，並把舊參數當成目前設定。

更新頻率應符合實際變動需求。短時間內連續請求，通常不會讓錯誤內容自行變正確，還可能讓回應結果更難比較。更新失敗後，先閱讀提示並檢查網路和網址，再決定是否重試。若暫時關閉自動更新以觀察問題，請在紀錄中註明，確認原因後再恢復原設定，避免排錯用設定長期保留，讓你誤以為內容一直正常更新。

更新後的伺服器清單不代表規則設定也已更新。若 Config 引用獨立的遠端規則或其他資源，請從各自的入口維護；更新 Subscribe 不會一併同步這些資源。最後應檢查三項：伺服器內容是否符合預期、目前選取項目是否有效，以及 Global Routing 和設定是否仍符合使用目的。三項都核對後，才能明確區分「訂閱維護完成」與「目前連線可用」。

06多筆訂閱分組與命名整理

依來源分組，依用途命名

同時管理多筆既有訂閱時，首先要清楚區分各自來源。每筆訂閱都應有容易辨認的名稱，以便識別更新來源，不要把所有伺服器混成一份無法追溯來源的清單。名稱可包含裝置用途或自訂分類，但不應含有密碼、存取權杖或完整訂閱網址。好的來源名稱應讓你幾天後仍能辨認其維護入口，而不只是在剛匯入時看得懂。

伺服器備註與訂閱名稱用途不同：訂閱名稱用來識別一組內容的更新來源，伺服器備註則用於辨認個別項目。建議採用簡單、固定的命名順序，例如先寫自訂用途，再保留原本容易辨認的標籤。不要把暫時測試結果寫進長期名稱，因為網路表現會變動，名稱卻容易被當成事實。遠端產生的備註也可能在下次更新時恢復原名，不宜只靠本機改名識別項目。

比對項目內容，不要只看名稱

兩筆同名伺服器不一定重複，不同名稱也不代表連線必定不同。整理項目時，應比較協定、位址、連接埠和關鍵傳輸參數，同時妥善保護驗證資料。同一組參數若分別來自訂閱和手動新增，維護方式仍不同：前者可能持續更新，後者則保留本機儲存值。刪除前先確認要保留哪種關係，而不只是留下哪個名稱。

若某個分組長期未使用，先確認目前選取項目是否仍在其中，或 Config 中的策略組是否依名稱引用。依名稱比對的設定可能受到更名或刪除影響。介面清單排序只會改變查找順序，不應拿來調整規則優先順序。規則由上而下的執行順序屬於 Config 內容，與 Home 中伺服器顯示在前或在後是不同層次。

多裝置整理以便於理解為主，不必追求表面一致

在 iPhone 和 iPad 上管理相同資料時，可使用一致的來源名稱，方便跨裝置核對；但不要假設一台裝置上的伺服器、選取狀態和 Config 會自動完整出現在另一台。是否同步及同步範圍，請以 App 實際設定為準。即使兩台裝置顯示相同名稱，也應分別確認匯入內容和目前設定；相同備註不代表參數或連線狀態一致。

整理訂閱時宜分批處理。先完成一個來源的命名、重複項目檢查、測試與備份，再處理下一個。若同時刪除多個分組、修改備註並切換設定，之後遇到連線異常便難以找出明確的起點。準備停用某筆資料時，可先記錄來源和用途，確認目前連線不依賴它，再執行刪除；暫時不用與永久停用，應在維護紀錄中清楚區分。

維護紀錄不必保存所有機密欄位。通常記下分組名稱、匯入方式、設定用途、修改原因和驗證結果，就足以協助排錯。伺服器憑證和完整訂閱網址應存放在受保護的位置，不要與公開筆記混放。向他人描述問題時，可說明「某筆訂閱更新後出現重複名稱」或「手動新增的副本仍可連線」，不必直接傳送整組匯出內容。

整理完成後，應回到實際使用情境檢查，而不只看清單是否整齊：選取預期伺服器、確認 Global Routing、開啟所需網頁，必要時查看連線記錄。若整理清單後發生異常，先還原最近一次修改，不要立刻變更 DNS 或整套規則。讓每次整理都可追蹤、可驗證，才能避免日常維護演變成範圍不斷擴大的連線排查。

07Connectivity Test、延遲與排序

測試結果只能回答實際測量的問題

Connectivity Test 可協助判斷伺服器相關連線狀況，但須依目前選擇的測試方式解讀結果。不同方式可能檢查不同層次：能否建立連線、能否透過代理完成要求，或能否連上指定測試目標。測試項目和選項請以 App 介面為準。顯示一個耗時數值，只能代表該次測試完成了相應流程，不能據此推論所有網站、所有協定和持續傳輸都正常。

測試結果會受目前網路、目標位址、伺服器狀態和測試時間影響。比較伺服器時，應盡量維持測試方式及網路條件一致，不要把不同裝置、不同時間或不同目標的結果混在一起排序。單次異常不一定代表持續故障，可間隔一段時間再測，並與實際使用結果比對。反過來說，偶爾成功一次也不能抹去頻繁中斷的狀況，請記錄問題能否重現。

依序檢查連線、驗證、解析與規則

若連基本連線都無法建立，先核對位址、連接埠，以及目前網路能否連到伺服器。若傳輸連線已建立但代理要求失敗，再檢查驗證、TLS 和傳輸參數。若代理要求正常但部分網域無法開啟，則繼續檢查 DNS 與規則，不要立刻更換整份訂閱。依這個順序逐層檢查，可避免把伺服器、網域解析和路由選擇問題混為一談。

測試正常但網頁無法開啟時，請確認實際要求採用的策略。Global Routing 設為 Config 時，規則會由上而下決定要求採用哪種策略；Proxy 和 Direct 則代表不同的整體路由模式，不能只憑伺服器測試結果判斷網頁的連線路徑。檢查時先確認目前模式，再確認要求是否使用預期伺服器。若有連線記錄，請一併查看網域、策略和錯誤資訊，不要只看延遲數值。

排序方便查找，不代表長期品質評價

依測試結果排序，可將這次回應較快的項目移至方便選取的位置，但不應把排序視為穩定的品質排名。回應時間、持續傳輸速度和連線穩定度是不同指標，適用的連線目標也可能不同。測試失敗的項目應先確認是否缺少參數或暫時無法連線，不必立刻刪除；若該項來自訂閱，下次更新也可能改變其連線資料。

需要驗證某個項目時，建議選取後完成一次完整的實際連線測試：確認系統連線狀態、開啟目標網頁，再檢查結果是否符合預期。若只有部分頁面異常，請分別比較可開啟與無法開啟的網域，並維持伺服器和模式不變。一次只改變一個條件，才能判斷是更換伺服器有效，還是規則、解析或目標本身的差異造成結果變化。

記錄測試結果時，請保留必要背景資訊：使用的網路、測試方式、目前伺服器、Global Routing，以及可重現的現象。錯誤提示中的網域和參數可能含有機密資訊，對外說明前應先遮蔽。若只有特定目標異常，不要以批次測試結果取代對該目標的檢查；若整個網路都無法使用，先確認裝置基本網路正常，再檢查 Shadowrocket 的伺服器與設定。

排序後也要確認目前選取項目，因為清單位置改變不代表 App 一定切換到第一筆。維護完成時，請確認目前狀態：使用哪個來源的項目、採用何種模式，以及是否已還原臨時修改。下次遇到問題時，才能從已知條件開始排查，不必猜測上次測試留下了哪些變更。首次驗證的完整步驟仍以使用教學為主線。

08刪除、備份與換裝置還原

先確認要刪除的項目層級

刪除單一伺服器、刪除一個 Subscribe 分組和刪除一個 Config 檔案，影響範圍各不相同。單一伺服器涉及特定連線項目；訂閱分組涉及一組內容及其更新入口；設定檔則關乎規則與相關設定。操作前請先看清確認提示，再判斷目前連線是否依賴該項目。不要因為介面上的操作都叫刪除，就認為後果相同；尤其在排錯時，避免連規則設定也一併清除。

訂閱中的項目刪除後，可能在下次更新時重新出現，因為遠端清單仍包含該項目；獨立儲存於本機的項目則沒有相同的恢復來源。若要長期排除某個項目，應先了解 App 現有的篩選或管理選項，而非一再重複刪除。刪除分組後若要還原，通常需要原訂閱網址和有效的存取條件；只記得伺服器名稱，無法重建完整訂閱關係。

依來源、參數與設定分別檢查備份

備份應涵蓋真正需要還原的項目。訂閱網址用於重新取得伺服器；獨立伺服器需保留完整參數；Config 則需保存檔案及其相關相依資料。也應依實際需求記錄目前選取項目、Global Routing 和 On Demand 等設定。App 提供的匯出、分享或備份功能涵蓋範圍，請以目前介面說明和匯出內容為準，不要假設任何一種方式都包含所有狀態。

1. 列出既有訂閱來源，確認可從受保護的紀錄中找回原網址。
2. 確認手動新增的伺服器是否另有完整參數，並與訂閱副本區分。
3. 儲存要移轉的 Config，並確認其遠端資源仍可取得。
4. 記錄目前模式、選取項目及必要的按需連線設定。
5. 先在還原裝置上完成驗證，再決定是否清理舊裝置和暫存匯出資料。

匯出內容可能含有密碼、UUID、私鑰或訂閱存取憑證，請選擇受保護的儲存位置，並限制存取權限。公開雲端硬碟連結、群組聊天檔案和公開筆記都不適合保存完整連線資料。若使用系統檔案儲存或裝置備份，也應確認帳戶和裝置的存取保護。備份的目的在於可供還原，而不是多複製幾份；散落各處、無法辨別新舊的檔案，反而會增加誤用與外洩風險。

還原 App 與還原連線資料是兩回事

更換裝置或重新安裝後，先透過 App Store 重新取得已購的 Shadowrocket，再處理訂閱和設定。App 購買紀錄與伺服器資料是不同項目，重新取得 App 不表示所有連線資訊都已還原。購買與重新下載步驟請參閱已購項目還原說明；裝置系統需求、購買適用性和相容性皆以 App Store 頁面標示為準，不應直接根據另一台裝置的狀況推論。

在新裝置上還原時，先匯入一個來源或一台伺服器，完成參數核對和連線測試，再繼續還原其他內容。還原 Config 後，請確認它是否成為目前選用的設定，並檢查規則引用的名稱、資源與伺服器關係是否仍有效。若舊裝置曾有本機例外修改，請依維護紀錄逐項還原，不要把所有舊測試副本都匯入後再猜哪一份才是最終版本。分批還原更容易找出遺漏。

刪除前先完成驗證流程

移轉完成的標準應是實際可用，而不是匯入數量看起來相同。至少確認目前伺服器能連線、常用目標可正常使用、Global Routing 符合預期，並檢查 On Demand 是否符合你的使用需求。新裝置可能需要重新確認連線授權，請閱讀系統提示後再操作。驗證尚未完成前，不要清除舊裝置中唯一可用的獨立參數，也不要把截圖中的名稱當成備份。

若完整訂閱網址或伺服器憑證不慎外流，只刪除訊息或本機檔案無法讓已散布的副本失效。請透過原有帳戶或伺服器管理管道處理相關憑證，再更新裝置中儲存的資料並重新測試連線。處理期間保留必要的變更紀錄，但不要在排錯筆記中繼續記載舊憑證。後續也應重新整理備份，避免還原時再次匯入已失效或外洩的內容。