Shadowrocket 訂閱與伺服器管理

先辨識資料，再選擇入口

如果手邊的是會傳回伺服器清單的訂閱網址，優先尋找 Subscribe；如果只有單台伺服器的 Address、Port 和驗證資訊，請前往下一章使用 Add Server。兩者的差別不在連線能力，而在資料的維護方式：訂閱通常透過一個網址提供多筆伺服器記錄，之後可以重新取得清單；手動填寫的記錄則由你逐項儲存，修改時也要逐項核對。若把單台伺服器的分享連結填成訂閱網址，或把訂閱網頁網址當成伺服器 Address，後續排查就容易失去方向。

開啟 Shadowrocket 後，請在 Config 及伺服器管理相關入口尋找 Subscribe。螢幕尺寸和 App 內的排列方式可能影響入口位置，請以目前畫面為準。操作前先確認複製的是完整網址，尤其不要漏掉路徑、查詢參數或結尾字元。以下假網址僅用於說明格式，不會傳回可用資料。真實網址屬於敏感資訊，不應貼在公開討論區、截圖或問題回報中。

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

儲存後分別檢查三項結果

在 Subscribe 輸入已有的網址，依目前畫面提示儲存或更新。第一步檢查訂閱記錄是否出現在清單中；第二步確認更新後是否產生伺服器項目；第三步才是選取某筆記錄後能否成功連線。這三項結果不能互相取代：看到訂閱名稱不代表已成功解析，看到伺服器名稱也不代表參數可用。初次匯入時，先確認項目數量和名稱是否符合手邊資料的預期，再展開一筆記錄核對其 Type、Address 和 Port，最後才測試連線。

如果清單是空的，先回到原始文字，確認是否複製了換行、前後空格，或只截取部分網址。若 App 顯示取得失敗，請檢查目前裝置是否能連上該網址，並確認網址仍由你已有資料的維護方管理；不要立刻反覆刪除和新增，以免留下難以辨認的同名記錄。若已取得內容但無法解析，請分別記錄「取得失敗」和「解析失敗」，兩者代表不同線索：前者較可能與網址和網路連線有關，後者則較可能與傳回內容及格式有關。更完整的排查順序請參閱訂閱更新失敗自我檢查清單。

訂閱記錄與伺服器記錄的關係

訂閱是後續更新的入口，伺服器項目則是可供選取的結果。更新後，某個項目的名稱、順序或數量有所變化，不能單憑此事判定 App 內手動設定被修改；請先確認變化是否來自同一筆訂閱，再檢查目前選取的伺服器是否仍在清單中。訂閱提供的內容取決於你已有的資料，Shadowrocket 會依收到的內容顯示並管理項目。若要長期保留手動調整，請先確認下次更新是否會覆蓋這些調整，不要把更新取得的項目當成永遠固定的本機草稿。

第一次匯入建議只處理一筆你能辨認的訂閱：記下它的顯示名稱、更新前後項目的變化，並記錄一次測試結果。這麼做不是限制訂閱數量，而是建立可追溯的起點。若同時新增多筆訂閱後才發現清單為空，往往很難判斷是哪個網址或哪次更新造成變化。已有多筆記錄時，可前往整理多筆訂閱，先建立清楚的命名方式與檢查順序。

依據現有資料選擇 Type

Add Server 適用於已取得單台伺服器完整參數的情況。先選擇與資料相符的 Type，再填寫該 Type 顯示的欄位；不要憑印象選擇協定，再把不同協定的參數硬填進同一份表單。Shadowsocks、VMess、VLESS、Trojan 等名稱代表協定類型，實際欄位會隨所選 Type 和 App 內的選項而異。最穩妥的核對方式，是將手邊資料與目前表單並排比對，逐項確認欄位名稱、格式和開關狀態；缺少的資料不要猜測補上。

了解基本欄位與附加欄位

Address 指向遠端伺服器，Port 是該伺服器提供的連線埠，Remark 則用來協助你在清單中辨認項目。Password、UUID、加密方式、TLS、SNI 等參數是否出現及如何搭配，應以所選 Type 的表單和你已有的資料為準。例如，Trojan 資料通常需要核對 Password 及 TLS 相關欄位；VMess 與 VLESS 資料通常也會涉及 UUID 和傳輸設定。欄位名稱相似，不代表可以直接在不同 Type 之間複製整份設定。相關差異可參閱Trojan 欄位說明和VMess 與 VLESS 欄位差異。

手動填寫時，建議先核對不會暴露驗證資訊的項目：先看 Type，再確認 Address 的字元和 Port 的數字，接著核對協定專屬欄位，最後填寫 Remark。完成後先儲存，再重新開啟該項目，確認內容沒有因鍵盤自動替換、複製時帶入空白字元或切換表單而改變。範例中的 example.com、443、your-password 都是假值，只用來示範欄位格式，不能取代你自己的資料。密碼、UUID 和私鑰等內容不適合出現在公開截圖中。

儲存不等於完成驗證

成功儲存一筆 Add Server 記錄，只代表表單接受目前輸入的內容。接著還要在清單中選取該項目，並視需要查看連線狀態與測試結果。如果測試未通過，先確認 Type 與欄位是否相符，再檢查資料是否另有傳輸或驗證要求；不要一次修改五、六個參數。每次只修改一個明確可疑的欄位，儲存後再測試，才能知道是哪項設定造成影響。若仍無法從現有資料確認，請保存原記錄的截圖或不含敏感資訊的欄位筆記，再向資料維護方詢問，避免把猜測當成長期設定。

手動填寫的項目適合獨立維護，也可以拿來比對訂閱中某筆伺服器的參數，但不要預設兩者是同一筆記錄。訂閱更新可能替換其下的伺服器項目；手動填寫的項目通常需要自行修改。若清單中同時有名稱相近的訂閱項目和手動項目，請先依來源和備註區分，再決定要保留哪一筆。下一章會說明掃描和剪貼簿匯入；這些方式主要改變輸入途徑，仍須依本章核對欄位。

掃描前先確認 QR Code 包含什麼內容

掃描是讓 App 讀取已有資料的入口，不是獨立的伺服器協定。QR Code 可能包含單台伺服器的分享連結，也可能包含訂閱網址；掃描後產生的結果，應分別依 Add Server 或 Subscribe 的方式檢查。在 Shadowrocket 中尋找 Scan QR Code 等掃描入口時，請以 App 目前顯示的名稱和位置為準。使用相機掃描前，先確認 QR Code 確實是你要匯入的資料，不要只憑旁邊印的伺服器名稱判斷內容。掃描後先查看 App 辨識出的 Type、網址或訂閱記錄，再決定是否儲存。

在同一台 iPhone 上查看的 QR Code，不一定方便用該裝置的相機再次掃描。此時請確認目前 App 是否提供從圖片辨識或從剪貼簿讀取的入口；可用選項依畫面而異，不要把特定按鈕位置當成固定路徑。如果 QR Code 顯示在另一台裝置上，可以直接用相機辨識；如果是本機圖片，先確認圖片清晰且完整，再使用 App 目前提供的辨識方式。辨識失敗時，不要把圖片裁到 QR Code 邊緣；也要確認 QR Code 包含的是 App 能處理的文字格式，而不只是網頁入口。

使用剪貼簿輸入時留意多餘字元

若已複製完整的分享連結或訂閱網址，可以從剪貼簿匯入。複製時盡量只選取目標文字，不要連同說明文字、引號或項目符號一起複製。如果 App 提供剪貼簿辨識入口，可以先查看預覽；若沒有合適的入口，就依內容類型手動貼到 Subscribe 或相應的 Add Server 欄位。不要假設複製後就會自動建立記錄，也不要貼上後未經檢查便連線。有些訊息畫面會縮短顯示的連結，但剪貼簿中是否包含完整內容仍須另外確認。

辨識成功後，請優先確認「取得的是什麼」。若出現一筆伺服器，請核對 Type、Address、Port、驗證欄位和 Remark；若出現訂閱網址，則確認它是否已儲存為 Subscribe 記錄，並在更新後查看伺服器清單。QR Code 和剪貼簿都只是輸入媒介，無法替你判斷資料是否完整。特別是 QR Code 包含多行文字時，App 可能只辨識其中能處理的部分；若結果與預期不同，請回頭檢查原始文字，不要繼續猜測並補上辨識結果中缺少的參數。

匯入失敗時的替代檢查方式

掃描沒有結果時，先檢查畫面、亮度和相機權限，再確認 QR Code 內容確實是你已有的訂閱網址或伺服器分享文字。剪貼簿沒有結果時，先把複製的內容貼到裝置上的一般文字輸入欄，查看前後字元，確認沒有空格、換行或說明段落，再回到 App 重試。若文字本身不完整，換個入口也無法補回缺少的欄位；若內容完整但無法辨識，可依下一章的格式判斷方式分辨它是訂閱 URL、單台伺服器連結，還是僅供手動填寫的參數清單。

匯入後不要立刻重複大量掃描。重複項目可能顯示相同的 Remark，實際上卻是在不同時間匯入，之後連線時很難判斷選到哪一筆。先開啟新項目確認來源，並檢查是否已有相同的網址和參數；若只是要更新現有訂閱，請使用該筆訂閱的更新功能，不要反覆掃描同一張 QR Code。需要清除重複記錄時，先依本頁最後一章完成保存與刪除前檢查。四種入口的整體選擇方式，也可參閱新增伺服器的四種方式。

先判斷連結指向清單還是單筆記錄

訂閱網址通常是可供存取的網頁形式 URL，App 連線至該網址後會取得可解析的伺服器清單；伺服器分享連結通常會將單台伺服器的參數編碼在文字中，供 App 讀取並建立記錄。兩者即使都能複製、都能放進 QR Code，也不應填入同一個欄位。判斷時不要只看開頭是否有 https://：它可能是訂閱網址，也可能只是說明頁面。更可靠的線索是手邊資料對用途的說明，以及 Shadowrocket 匯入後的預覽結果——顯示一筆 Subscribe 記錄，還是顯示單台伺服器的 Type 和參數。

分享連結通常包含協定識別資訊和編碼後的驗證資料。你可能會看到 Shadowsocks、VMess、VLESS 或 Trojan 的連結格式，但畫面上未必能直接讀出所有欄位。連結結尾也可能附有顯示名稱用的備註，不應把備註當成驗證欄位。不要為了「看懂」而任意修改編碼文字中的大小寫、標點或百分比符號，這些變動可能會影響解析。匯入後若能查看欄位，請優先在 App 內核對結果；需要修改參數時，請使用現有資料中的明確值，不要從截斷的分享文字推測。

透過易讀範例了解訂閱 URL

以下網址只用來展示 URL 的結構：主機名稱、路徑和查詢參數都是示意內容。路徑是網址的一部分，查詢參數也可能影響傳回內容，因此複製時應保留完整字串。真實訂閱網址可能含有敏感識別資訊；向他人描述問題時，只需說明「網址可以開啟，但解析結果是空的」等現象，不要貼出完整網址。用來檢查格式的假值無法證明實際網址可供存取，更不能用來測試連線。

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

如果現有資料列出 Address、Port、Password 和其他參數，但沒有分享連結或訂閱 URL，就使用 Add Server 手動填寫。相反地，若拿到的是完整訂閱 URL，就不必把網址拆成 Address 和 Port：訂閱頁面所在的主機並不是清單中每台伺服器的 Address。區分這兩種位址尤其重要；把訂閱主機填進伺服器欄位，常會建立看似完整、實際卻無法正常運作的記錄。

格式相容性與解析範圍

不同資料可能採用不同的編碼和欄位組合，實際能辨識的格式以目前 Shadowrocket 的匯入結果為準。App 辨識出 Type 後，也要檢查附加欄位是否完整，尤其是傳輸、TLS 和驗證相關設定。即使兩個分享連結顯示相同協定，也不代表它們使用相同的傳輸參數。匯入後若欄位缺漏，先確認原文是否完整，再確認資料本身是否提供該欄位；不要複製另一台伺服器的欄位來補齊。連結解析失敗時，保留錯誤提示與已去除敏感資訊的格式資料，再逐項排除「文字不完整、選錯入口、目前格式不支援欄位」等可能原因。

分享或轉傳自己的資料時請留意，連結往往包含足以重建伺服器記錄的資訊。公開展示 QR Code、剪貼簿記錄或含完整網址的截圖，可能同時暴露驗證資料。若要比對兩筆項目是否相同，可以在本機檢查 Type、備註和不含憑證的欄位；向他人說明問題時，改用 example.com 和 your-password 等明顯是假值的內容。這樣仍能說清楚問題發生在 Subscribe、分享連結解析，還是 Add Server 手動填寫，而不會洩露原始文字。

更新代表重新讀取訂閱內容

在 Subscribe 執行更新，會讓 App 重新取得該網址目前傳回的資料；這不是替所有伺服器「加速」，也不會自動修正錯誤參數。更新完成後，清單中的名稱、數量或欄位可能隨傳回內容改變；若原訂閱暫時無法存取，先查看 App 提示和目前清單狀態，不要逕自判定原有伺服器已永久失效。開始前先記下目前選取的項目和訂閱名稱；更新後將預期變化與實際結果比對，再測試連線，才能分辨「內容確實改變」和「只是本機選取狀態改變」。

對於已穩定使用的記錄，不必把重複重新整理當成遇到連線問題時的第一個處理方式。如果只有一台伺服器連線失敗，先確認該筆記錄的測試結果與實際連線狀態；若同一筆訂閱下多筆記錄同時異常，再檢查訂閱網址和這次傳回的內容。若你明確收到現有資料的變更通知，可以更新相應的 Subscribe，不必順手更新所有訂閱。這樣清單出現變化時，才有辦法追溯是哪筆記錄、哪次操作造成的。

將錯誤提示分為取得與解析兩類

取得失敗時，請優先檢查訂閱 URL 是否完整、裝置目前的網路是否能連上該 URL，以及原網址是否仍有效。解析失敗或更新後清單為空時，請優先確認傳回內容是否為 App 可辨識的伺服器資料、是否把說明網頁網址當成訂閱網址，以及原始文字是否多了換行或遭到截斷。即使更新顯示成功，若沒有看到預期項目，也要確認目前檢視的是哪個訂閱群組、是否存在同名記錄，以及清單排序或篩選是否改變了項目位置。一次只處理一種可能原因，在找出原因前不要刪除原記錄。

如果目前 App 畫面提供自動更新相關選項，請依實際使用需求設定，不要假設所有訂閱都需要相同的更新頻率。更新太頻繁會讓清單變化更難追蹤；長時間不查看更新結果，則可能繼續使用與現有資料不一致的舊項目。較容易掌握的做法是記錄哪些訂閱由你定期檢查、哪些只在資料明確變更時手動更新，並在更新後查看項目數量、名稱和重要欄位，而不只看完成提示。更新需要裝置連上網路；裝置離線時，不能用舊的測試結果判斷這次是否取得成功。

更新後如何確認連線狀態沒有誤判

先找出更新前使用的項目：若它仍在清單中，核對 Type、Address、Port 和必要的附加欄位是否改變；若名稱已變更，請依訂閱歸屬和欄位尋找，不要只靠 Remark 判斷。接著執行可用的連線或測試操作，必要時在 Home 查看目前選取的伺服器及 Global Routing 狀態。Global Routing 中的 Config、Proxy、Direct 分別代表依設定檔、代理和直連的模式；路由狀態不同，測試和日常存取的表現也可能不同。測試時應確認要驗證的是伺服器參數、規則路徑，還是目標服務的連線能力，不要把三者混為一次「更新失敗」。

若更新後的結果明顯不如預期，先保存足以描述變化、但不含敏感資訊的內容，例如訂閱顯示名稱、更新提示、項目數量變化和某筆記錄的 Type。不要反覆覆蓋目前狀態，也不要公開原始網址尋求協助。可依照五步自我檢查清單進一步縮小問題範圍；若涉及特定網址或驗證資訊，只向該份現有資料的維護方確認。計畫重新新增訂閱前，先依刪除與備份章節確認是否已另行保存現有資料。

用名稱記錄用途，不要用名稱取代欄位

當 Subscribe、手動填寫的伺服器和掃描匯入的項目同時存在時，最容易遇到的問題不是記錄太多，而是無法辨認彼此的關係。建議先為每筆訂閱設定容易辨認的顯示名稱，再讓手動項目的 Remark 與訂閱名稱有所區別。名稱可以提示用途或來源類別，但不要包含 Password、UUID 或完整訂閱網址等敏感資訊。也不要把「速度快」「一直可用」寫成永久備註：測試結果會變動，而 Remark 往往長期留在清單中，容易造成過時判斷。

整理時先找到訂閱記錄，再查看其下的伺服器項目，最後核對獨立手動填寫的記錄。如果兩筆項目的 Remark 相同，不要立刻刪除其中一筆；請分別開啟，查看 Type、Address、Port，以及是否來自訂閱。同一台伺服器可能因不同匯入方式而出現兩筆記錄，也可能只是名稱相同、參數不同。尤其訂閱更新後，清單順序可能改變；若習慣認定「第一筆就是上次那筆」，更容易選錯。若經常使用特定排序或篩選方式，請先確認目前顯示順序的依據。

區分清單中的項目與目前使用的項目

清單中儲存了某台伺服器，不代表 Home 目前選取的就是它。準備排查連線時，先確認目前選取的項目，再確認它屬於哪筆訂閱或是否為手動填寫，最後查看 Global Routing。在 Config 模式下，流量依設定規則處理；在 Proxy 模式下，依代理模式處理；在 Direct 模式下則直接連線。以下對照僅用來整理排查思路，實際流量仍以目前設定和 App 畫面為準。記錄路由模式，有助於避免把 Direct 模式下的表現誤算到某台伺服器。

若某筆訂閱更新後新增許多相似項目，先依訂閱歸屬檢查，再考慮調整排序。延遲數值和名稱都不是唯一識別方式：同名記錄可能指向不同的 Address，延遲也會隨測試時的網路狀況改變。建議建立固定的人工檢查順序，例如「訂閱顯示名稱 → 伺服器 Type 與不含敏感資訊的位址資料 → 目前選取狀態 → 測試結果」。如此一來，即使清單順序變了，也能重新找到要檢查的項目。對於不再使用的項目，先確認目前設定是否仍選用它，再進行清理。

勿混淆設定檔與訂閱清單

Config 中也可能儲存規則設定；規則設定和 Subscribe 的伺服器清單是兩種不同資料。規則中的 PROXY、DIRECT 等是策略關鍵字，不是訂閱名稱。以下片段展示規則如何比對網域、地理位置與最終流量，僅供理解語法；其中不含可用伺服器，也不應貼到 Subscribe 網址欄位。若規則指向的策略與目前可用伺服器不一致，應分別檢查設定檔和伺服器選取狀態，不要只是不斷更新訂閱。

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

管理多筆訂閱的目標，是讓每次更新和測試都能找到明確的對象，而不是盡可能縮短清單。先保留足以辨認的名稱和來源關係，再依實際使用情況清理。若要進一步了解 DOMAIN-SUFFIX、GEOIP 和 FINAL，可參閱術語表；第一次選擇 Global Routing 的操作流程，請見快速入門。

先確認測試的對象

延遲測試通常用來觀察某台伺服器在目前網路下的回應狀況；Connectivity Test 等診斷入口的測試目標，則應依其畫面說明判斷。測試顯示數值，不代表所有網站或所有規則路徑的回應都相同，也不等於已完成日常連線驗證。測試前請確認裝置目前可以連上網路、伺服器項目已正確匯入，並記下目前的網路環境。否則，同一筆記錄在不同時間得到不同結果，可能只是測試條件改變，未必表示訂閱內容遭到修改。

建議先測試少數已核對欄位的項目，觀察 App 顯示的是數值、錯誤提示還是等待狀態。數值適合在同一次、相同條件下作為參考；錯誤提示則應搭配 Type、Address、Port、驗證資訊及網路連線能力一起判斷。不要只因延遲數值低就略過後續驗證，也不要只因一次逾時就刪除記錄。測試請求可能使用不同於實際存取的目標和路徑；尤其使用 Config 規則時，請確認測試的是伺服器連線能力，還是透過某條規則連線至目標。

排序是檢視方式，不會修改資料

依延遲或其他條件排序可以縮短尋找時間，但通常只是改變清單的顯示順序，不代表資料永久依此排列。更新訂閱、切換排序條件或重新測試後，項目都可能換位置。排查時請依訂閱歸屬和欄位辨認項目，不要只記下「第三台伺服器」。若測試失敗的項目排在最後，也不代表它已從訂閱中消失；先檢查目前的篩選和排序狀態，再判斷記錄是否真的不見了。

比較兩台伺服器時，盡量在同一個網路環境、相近時間測試，並核對兩筆記錄的 Type 和來源。一次測試可以協助選擇下一步檢查對象，但不能取代欄位核對。若某筆記錄顯示測試可連線，但實際存取仍不如預期，請回到 Home 確認目前選取的確實是它，再檢查 Global Routing 是 Config、Proxy 還是 Direct；若為 Config，接著檢查規則比對到的策略。反之，若實際使用正常，但單項測試沒有顯示數值，也應先了解該測試的目標和提示，不要立刻修改目前可正常運作的設定。

從伺服器診斷進一步檢查規則

確認伺服器參數與連線狀態後，再檢查規則層。以下幾行展示常見比對類型在設定檔中的位置：DOMAIN 用來比對指定網域，DOMAIN-SUFFIX 涵蓋網域後綴，IP-CIDR 用於位址區段，FINAL 則處理未符合前述規則的流量。規則範例中的 example.com 和位址區段僅供閱讀語法；其中的 PROXY 能否如預期運作，仍取決於目前設定和伺服器選取狀態。不要把規則片段當成延遲測試的目標清單。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

如果問題只發生在特定目標，先確認該目標符合哪條規則，再檢查對應策略和目前選取的伺服器；若多個目標都無法連線，則回頭檢查伺服器連線、訂閱更新和裝置網路狀態。由局部到整體逐層檢查，比同時切換伺服器、更新訂閱和重寫規則更容易找出原因。測試和排序是管理工具，不是修復方式；它們只能指出接下來該檢查哪一層，不能取代原始參數或規則本身。更多狀況可在疑難排解依類別查找。

先確認要刪除的是哪一層資料

清理清單前，先分辨訂閱記錄、由訂閱產生的伺服器項目、手動填寫的伺服器，以及 Config 規則設定。刪除其中一項可能影響後續更新或目前的選取狀態，因此不要只憑名稱相似就批次清理。準備刪除訂閱時，確認它是否仍是某些伺服器項目的更新入口；準備刪除單台伺服器時，確認目前是否選取了它，以及下次更新訂閱時它是否可能再次出現；準備刪除 Config 時，先檢查是否有需要保留的自訂規則。請逐字閱讀畫面顯示的刪除對象和確認提示。

較穩妥的做法是先查看目標記錄的來源和不含敏感資訊的欄位，再確認目前連線是否依賴該項目，接著確認原始資料仍由你自行保存。訂閱 URL、伺服器驗證欄位和規則檔各有不同用途，只保存清單截圖未必足以重建設定；反過來說，公開含有完整敏感網址的截圖也不合適。備份應放在自己可控的位置；記錄名稱和用途時可以使用已去除敏感資訊的文字，真正用於還原的完整資料則須依敏感程度妥善保管。

分別備份訂閱、手動項目與規則

若要重建訂閱記錄，至少要保留自己已有的完整訂閱網址及對應的辨識名稱；若要重建手動項目，則須依 Type 保存必要欄位和附加選項；自訂規則設定也應另外保存其內容。不要以為保留訂閱 URL 就等於保存所有手動填寫的伺服器，也不要以為保留一條分享連結就能還原先前的規則檔。若目前 App 提供匯出、分享或 Import from Cloud JSON 等相關入口，請先閱讀畫面說明，確認匯出或匯入的是哪類資料，再決定是否使用。不能只憑入口名稱推斷其涵蓋範圍。

完成備份後，做一次不修改現有記錄的檢查：確認保存的內容能辨認訂閱和手動項目、文字沒有遭到截斷，並確認規則片段仍保留原有換行和順序。含有驗證資訊的檔案或文字，不要透過公開留言或截圖來測試是否「備份成功」。如果只是想替自己留下排查筆記，可以另外撰寫已去除敏感資訊的清單，記下訂閱顯示名稱、伺服器 Type、不含敏感資訊的備註和操作日期。這份筆記方便定位，但不能取代完整的還原資料。

刪除後如何判斷是否需要重新匯入

刪除後回到清單，確認目標記錄是否確實消失、目前選取項目是否改變，以及其他訂閱能否繼續依原方式更新。如果刪除的是訂閱產生的單台伺服器項目，但訂閱記錄仍在，下次更新時該項目可能再次出現；如果刪除的是訂閱本身，也要重新確認原本依賴的更新方式。需要重建時，先依Subscribe或Add Server章節選擇正確入口，不要同時透過掃描、剪貼簿和手動填寫重複建立同一筆記錄。

更換裝置或重新取得 App 時，先依已購項目還原說明確認 App Store 中的購買記錄，再處理自己的訂閱和設定資料。Shadowrocket 在 iPhone、iPad 上的取得方式與系統需求，均以 App Store 頁面標示為準；App 的購買狀態與伺服器資料保存是兩回事。用戶端一次買斷 ≠ 線路方案；還原已購 App 也不代表所有手動保存的伺服器欄位都會自動重建。若有疑問，先確認缺少的是 App、訂閱記錄、伺服器項目還是規則設定，再依類別還原。