01 · Subscribe 入口與首次匯入
先分清訂閱與單一伺服器
Subscribe 儲存的是可再次請求資料的入口；Add Server 儲存的是手動填寫的伺服器紀錄。兩者最後都可能以伺服器項目的形式出現在 Home 清單中，但維護方式不同：訂閱中的項目通常由訂閱資料決定，手動填寫的項目則需要逐項修改。開始前，先確認手邊的資料類型。如果是供用戶端讀取並定期更新的連結，請使用 Subscribe；如果只有位址、連接埠、驗證資訊和協定參數，請使用下一章的 Add Server。別因為兩者最後都顯示為清單項目，就把伺服器分享連結當成訂閱網址填入。
在 Shadowrocket 的 Home 開啟新增入口，選擇用來新增訂閱的 Subscribe 類型，再將完整的既有連結填入對應的 URL 欄位。不同介面狀態下，新增入口的位置和欄位排列可能略有差異；請確認選取的類型確實是 Subscribe，而不是只看到可貼上文字的輸入框。儲存後回到清單，等待用戶端讀取並解析。首次新增前，可以先將原始連結複製到系統備忘錄暫時核對，確認開頭與結尾沒有漏字，也確認複製時沒有連同前後空格或換行一起帶入。
儲存成功不代表解析成功
一次匯入至少包含三個環節：儲存 URL、透過網路取得回應，以及將回應轉換為 Shadowrocket 可辨識的伺服器項目。清單中出現訂閱名稱，只能表示第一個環節已完成；若有名稱但沒有伺服器，請繼續核對後兩個環節。先在相同網路環境下確認原始連結是否仍有效，再確認連結回傳的確實是適用於用戶端的訂閱內容，而不是登入頁面、錯誤頁面或單一分享文字。不要自行改動連結中的查詢參數：參數可能是資料的一部分，刪掉一個字元就可能取得不同的回應。
如果新增後有項目，但名稱不易辨認，請先為訂閱入口設定一個方便自己區分的名稱，再考慮清單排序。名稱只是本機的管理標記，不會修正伺服器位址，也不能取代伺服器端資料檢查。初次使用時，建議先匯入一筆已掌握的訂閱，確認看得到項目、辨識得出來源，也能依需求更新，再新增下一筆。遇到解析失敗時，這樣比較容易鎖定問題，不必在多個來源與重複項目之間反覆猜測。
訂閱內容是會變動的遠端資料，不應把目前顯示的伺服器數量視為固定狀態。下次更新後，項目可能增加、消失或更名；如果某個位址適合單獨長期維護，請先確認它原本是否由訂閱管理，再決定是否另建手動紀錄。也不要將購買 App 與匯入資料混為同一個步驟：在 App Store 購買的是用戶端，Subscribe 讀取的是你已有的資料。若要先確認 App 身分，可依照正版核對三要點檢查開發者、圖示與 App ID。
02 · Add Server 手動填寫欄位
依照資料原樣選擇協定
只有單一伺服器資料時，請在 Home 的新增入口選擇 Add Server，再依照既有資料指定的協定類型填寫。選擇協定不是替同一組數字換個標籤：Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 和 Hysteria2 的欄位結構、驗證方式與傳輸需求各不相同。如果資料未註明協定，請先向資料提供者確認；只憑連接埠或位址無法可靠推斷。填寫時保留資料原有的大小寫、標點和特殊字元，尤其是密碼、識別碼、主機名稱及路徑，不要為了看起來整齊而自行改寫。
Address 是伺服器的網域名稱或 IP，Port 則是該服務使用的連接埠；兩者要一起核對。Address 欄通常不需要附上網頁路徑，Port 欄也不應填入協定前綴。如果資料提供的是包含完整結構的分享連結，請優先確認能否依照後文的連結方式匯入，避免從編碼文字中自行猜測欄位。手動填寫後先儲存，再回到紀錄確認是否出現在預期的清單中；儲存只表示輸入內容可以記錄，不代表伺服器一定會接受連線。
驗證、TLS 與傳輸參數
驗證欄位會依協定而異。Shadowsocks 需要相應的加密方式與密碼；VMess、VLESS 常見識別碼和傳輸選項；Trojan 著重密碼及 TLS 相關設定；WireGuard 則依 Interface 與 Peer 的資料成組填寫。在 TLS 情境中，SNI 所指的伺服器名稱可能與 Address 不同，不能任意互換。遇到 Allow Insecure 時，請留意它與憑證驗證有關；先核對憑證名稱、有效期限及輸入資料，不要把變更驗證行為當成排查連線失敗的第一步。
| 資料類型 | 填寫重點 | 常見核對項目 |
|---|---|---|
| 位址與連接埠 | Address、Port 與協定類型 | 網域拼寫、連接埠數字、資料是否仍有效 |
| 驗證資訊 | 密碼、識別碼或金鑰 | 大小寫、複製時混入的空白字元 |
| TLS 資訊 | SNI、憑證相關選項 | 名稱與憑證是否相符 |
| 傳輸資訊 | 路徑、Host 等協定指定欄位 | 開頭斜線及約定的原始寫法 |
欄位較多時，建議分兩輪核對。第一輪只檢查協定、位址、連接埠和驗證資訊是否與原始資料完全一致；第二輪再檢查 TLS、傳輸及其他選項。這樣可以區分基本欄位錯誤與進階設定不相符。不要一次修改多個欄位後立即測試，否則即使結果有變化，也難以判斷是哪個項目造成的。設定中若包含金鑰，請勿將完整資料貼到公開討論區；排查時只需說明欄位類型、錯誤位置及操作現象。
如果清單中同時有訂閱產生的紀錄和手動紀錄，請優先註明手動紀錄的用途。之後更新訂閱不會自動修正這筆手動資料；伺服器參數變動時，應回到該紀錄重新編輯。反過來，也不要直接將手動填寫的經驗套用到訂閱產生的項目上：後者的欄位可能在下次更新時由訂閱內容重新寫入。Trojan 各項參數及 WireGuard 的成組資料，請分別參閱Trojan 欄位說明和WireGuard 參數指南。
03 · Scan QR Code 與剪貼簿匯入
掃描前先確認 QR Code 內容
掃描 QR Code 可以省去逐欄輸入，但 QR Code 只是承載文字的另一種方式。先確認其中包含的是單一伺服器分享連結、訂閱 URL，還是其他文字，再判斷匯入後應該出現什麼。如果資料明確以 QR Code 提供，請在新增入口選擇 Scan QR Code，允許相機權限後，將完整碼面放入取景範圍，等識別結果出現再核對協定與主要欄位。若碼面模糊、遭遮擋或與背景對比不足，可請資料提供者重新顯示清晰的原始碼；不要根據 QR Code 旁的說明自行拼湊位址。
掃描後不要立刻將新項目設為目前使用的連線。先檢查匯入結果的類型、名稱、Address 和 Port 是否符合預期；如果匯入的是 Subscribe，請確認它是否成為可更新的訂閱入口，而不是靜態伺服器。如果 App 提示文字無法識別，問題也可能出在 QR Code 內的內容，而不只是相機權限。若圖片已儲存在本機，可先確認圖片內容清晰可讀，再使用介面實際提供的識別入口；不要把瀏覽器中看到的縮圖當成完整原圖處理。
從剪貼簿匯入時檢查首尾字元
剪貼簿匯入適用於你已持有完整分享文字的情況。複製時應從協定前綴開始，一直到文字最後一個字元，不要連同聊天訊息中的引號、編號或說明一起複製。回到 Shadowrocket 後，使用新增選單中對應剪貼簿的匯入操作，並檢查預覽內容。若系統出現讀取剪貼簿的權限提示，這是讀取剛才複製內容所需的系統操作；請先確認確實是你發起匯入，再決定是否允許。貼上後若出現空白紀錄，請先回到原始資料，確認剪貼簿中存放的是否為連結。
QR Code 和剪貼簿只是輸入方式，不會替你驗證資料是否真實或仍有效。重複掃描同一個 QR Code，或重複貼上同一段文字，可能讓清單中出現難以辨認的重複紀錄；匯入前先搜尋現有名稱，匯入後再比較協定、位址、連接埠等欄位。若文字包含驗證資料，請避免在共用裝置的其他輸入框中反覆貼上。操作完成後，可依個人隱私習慣以一般文字覆寫剪貼簿；但不要因此刪除唯一保存原始資料的位置。
遇到「掃描可辨識、連線卻無法使用」時，請將兩個階段分開處理。辨識成功只表示用戶端讀取到了文字，不代表連接埠已開啟、驗證正確或伺服器可連線；先檢查匯入後的欄位，再使用後文的 Connectivity Test 協助定位。如果另一台裝置也需要這份資料，請優先使用自己保存的原始資料，不要從清單截圖重新手動輸入被隱藏的欄位。跨裝置移轉時尤其要確認訂閱 URL 完整無缺；部分介面可能只顯示方便閱讀的截斷文字，不能把截斷內容當成備份。
05 · Subscribe 更新方式與異常排查
分清手動更新與自動更新
訂閱不是匯入一次後就永遠不變的本機清單。手動更新是在需要確認最新資料時主動讀取；自動更新則依設定在適當時機嘗試讀取。選擇哪種方式，應根據自己的使用頻率和資料變動情況，而不是把更新間隔設得越短越好。頻繁請求不會讓原本錯誤的連結變正確，也不保證遠端資料每次都會變動。排查問題時，先手動更新一次並記錄清單前後的差異，比反覆等待自動更新更容易判斷問題所在。
建議將每次檢查分為「入口狀態」與「項目狀態」。入口狀態包括 URL 是否完整、請求是否成功、內容是否能解析；項目狀態則包括更新後的名稱、數量與所需欄位是否符合已有資料。若更新提示失敗，但舊項目仍留在 Home，不要因此認為已取得新資料：某些情況下，畫面仍顯示先前儲存的內容。先查看失敗提示，再核對目前網路和原始 URL；不要因為舊項目仍看得到，就忽略更新結果。
清單變空、變少或出現重複項目
清單變空時，先停止連續重複點選更新。確認選取的是正確的 Subscribe 紀錄，再核對連結開頭、查詢部分和結尾；也要確認回傳內容是可解析的資料，而不是說明文字。清單變少未必是用戶端誤刪，也可能是遠端資料變動。可將目前結果與自己保存的上一筆紀錄比較，找出具體缺少的名稱，再核對其原始資料。更新後若出現重複項目，先確認是否重複匯入相同 URL，或同時保留了手動紀錄與訂閱紀錄。
需要修改訂閱 URL 時，請先確認是要編輯現有的 Subscribe，還是新增另一筆紀錄。編輯可保留原有的管理位置，但修改前應先保存完整的舊連結，以便貼錯時還原；新增則方便並排驗證兩個不同的 URL，卻可能造成清單重複。選擇方式取決於是否需要對照，不宜一邊排查一邊刪除唯一可用的舊入口。更新失敗也未必與協定欄位有關：取得資料前，DNS、網路狀態及 URL 回應都可能影響讀取。
若只有某筆訂閱反覆發生異常，而同一裝置上的其他訂閱都能更新，可優先檢查該筆 URL 和回應內容；若多筆同時異常，先檢查目前網路狀態，再分別手動更新一次，避免將共同的網路問題誤判為多個連結都有問題。關於連結格式、編碼和更新時機的逐項排查，請參閱訂閱匯入失敗或伺服器清單為空。完成排查後再決定自動更新安排，並定期檢查結果；自動更新設定不能取代對實際清單內容的核對。
06 · 多筆訂閱與手動紀錄整理
讓名稱清楚標示管理用途
當 Home 同時列出多筆 Subscribe 和手動紀錄時，首先要釐清「這筆紀錄從哪裡新增、應由誰更新」。為訂閱入口設定容易區分的本機名稱，例如依照自己的用途或資料類型命名，不要只靠伺服器名稱推斷來源。伺服器名稱可能隨更新變更；訂閱入口名稱則適合用來追蹤管理。手動項目也可以設定容易辨認的備註，但不要將密碼或完整訂閱 URL 放進顯示名稱，以免截圖或分享螢幕時洩露。
整理時應以入口為單位，而不是清單中每個看起來相似的名稱。同一筆訂閱可能包含多台伺服器；不同訂閱也可能提供相似名稱。判斷是否重複時，至少比較協定、Address、Port 及重要傳輸參數，再確認各自所屬的入口。只因顯示名稱相同就刪除，可能會誤刪仍需使用的獨立紀錄。若兩筆看起來完全相同，可先保留其中一筆進行測試，同時記下另一筆的來源，確認重複原因後再處理。
建立可追溯的變更順序
每新增一筆訂閱後，先確認新入口可以讀取，再整理舊入口；每次大範圍清理前，先保存自己合法持有的原始連結與手動參數。這個順序能降低誤刪後重建的成本。對於不再需要的項目，應區分「暫時不從清單選用」與「刪除入口」：前者方便日後繼續核對，後者會失去在目前裝置上透過該入口直接更新的方式。是否保留應依據實際資料狀態，而不是只看一次 Connectivity Test 的結果。
同時使用訂閱和手動紀錄時，特別要留意修改對象的來源。訂閱產生的欄位應優先回到訂閱資料核對，因為下次更新可能再次變更；手動紀錄則直接透過 Add Server 的編輯流程維護。如果要暫時修改訂閱中的某台伺服器以供對照，可先記下原始欄位與修改目的，避免更新後分不清是本機調整還是訂閱資料變動。紀錄不必複雜：寫下入口名稱、操作前狀況、修改項目及操作後結果即可。
多筆訂閱也會影響你對清單數量的判斷。數量增加可能來自新增入口、某筆訂閱內容變動或重複匯入；數量減少可能來自刪除入口、更新結果變動或顯示範圍改變。排查時逐一查看各入口，不要單憑總數推斷原因。如果目前只需使用其中一筆紀錄，可先選取來源明確的伺服器，再確認 Global Routing 目前是 Config、Proxy 還是 Direct，避免混淆路由模式與伺服器選擇。
在不同裝置間使用資料時，保持命名習慣一致有助於比對，但不代表兩台裝置的本機清單會自動同步。每台裝置都要分別檢查 Subscribe 入口、手動項目及 Config 選取狀態，尤其是在某台裝置新增或刪除資料後。裝置相容性與系統需求以 App Store 頁面標示為準；本章說明的是 iPhone、iPad 上的資料管理方式，清單排序不等同於跨裝置備份。下一章將說明如何利用測試結果輔助選擇，而不是以排序取代來源管理。
07 · Connectivity Test、延遲與排序
測試結果能回答哪些問題
Connectivity Test 可用來觀察目前網路環境下，用戶端是否完成對伺服器項目的連線測試。測試結果不是長期服務品質的保證，也無法證明所有 App 的請求都依預期規則處理。測試前先確認項目來自哪個 Subscribe 或手動紀錄，並確認裝置目前的網路狀態；更換網路環境後，測試結果可能不同。單次成功或失敗只反映當時的測試條件，不應直接用來判斷訂閱 URL 是否仍可更新；後者須回到 Subscribe 檢查。
延遲數值有助於比較，但比較前要盡量確保測試條件一致。不要將不同時段、不同網路下取得的結果混成固定排名；也不要只看數值較低，就忽略連線是否穩定。某筆紀錄顯示測試異常時，可先對同一筆再測一次，再選另一筆已知紀錄作為對照。如果所有紀錄同時異常，先排查裝置網路和目前設定；如果只有某一筆持續異常，再核對該筆的 Address、Port、驗證資訊及傳輸參數。
排序方便查找，不能取代驗證
依延遲排序適合在大量項目中快速找到目前測試結果較佳的紀錄，但排序後仍須確認項目來源。伺服器名稱可能相近，測試結果也會隨網路變動，只看排序位置很容易選錯。建議先依訂閱入口名稱或手動備註縮小範圍，再查看測試狀態與延遲。常用的紀錄應定期重新測試，比保存一次排序截圖更有參考價值；離開測試時間與網路環境後，截圖中的數值便很難解讀。
若伺服器測試成功，但實際請求仍不如預期，可將連線與路由分開排查。先確認 Home 中實際選取的伺服器及連線狀態，再查看 Global Routing：Config 依目前 Config 規則處理，Proxy 和 Direct 則可用來對照不同路由模式。在 Config 模式下，某個目標可能符合 DIRECT 規則，此時伺服器測試成功並不代表該目標正透過所選伺服器連線。若要進一步檢查規則，可查看 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等關鍵字與策略，確認請求符合哪一條規則。
| 觀察到的現象 | 先核對 | 再檢查 |
|---|---|---|
| 所有項目測試都異常 | 裝置網路與目前連線狀態 | 分別檢查訂閱更新與設定 |
| 單一項目持續異常 | 該項目的資料來源與欄位 | 驗證、TLS 及傳輸參數 |
| 測試正常，但請求結果不同 | 實際選取項目與 Global Routing | Config 規則的比對結果 |
排查時盡量一次只改變一個條件：先固定伺服器，比較路由模式；再固定路由模式，比較伺服器；最後檢查具體的 Config。這樣較容易判斷問題出在資料、連線還是規則。若連續切換多個項目，即使問題消失，也無法確認是哪個步驟造成差異。其他問題請參閱疑難排解；若涉及 DNS 解析路徑，可查看DNS 設定說明。測試與排序只是診斷工具，最終仍須結合實際請求和目前規則解讀結果。
08 · 刪除、移轉與資料備份
刪除前確認對象與影響範圍
整理清單時，先辨認準備刪除的是單一手動伺服器、訂閱產生的項目，還是整個 Subscribe 入口。刪除單一紀錄與刪除入口的後果不同：移除入口後，你可能會失去在目前裝置上透過該 URL 更新整組項目的方式。即使只想清理暫時無法使用的伺服器，也應先確認它是否屬於某筆訂閱；若屬於訂閱，下次更新可能再次加入，逐項刪除未必能達到整理目的。先確認資料來源，再決定是否刪除。
建議將整理分為檢查、保存、執行和複核四個步驟。檢查時確認名稱及重要欄位，避免認錯相似項目；保存時留存自己已有的原始訂閱 URL、手動參數及必要的 Config 文字；執行時一次只刪除一類對象；複核時回到 Home，確認保留的入口仍能正常更新、選取的伺服器仍然存在。如果無法判斷某筆紀錄是否仍有用途，先不要刪除唯一的原始資料。保持清單整潔是管理目標，但不應以失去可重建資訊為代價。
備份可供重建的資料
備份不只是保存一張清單截圖。截圖可能隱藏完整 URL、密碼、金鑰、路徑及其他欄位，也可能無法顯示某筆紀錄是手動填寫還是由 Subscribe 產生。較可靠的整理方式，是分別保存自己合法持有的訂閱原始連結、手動伺服器的完整參數，以及需要繼續使用的 Config 內容，並註明各自用途。敏感資料應存放在你能控制存取權限的位置；分享排查截圖前，請檢查畫面是否顯示驗證資訊或含參數的 URL。
要在另一台 iPhone 或 iPad 上重建資料，先從 App Store 取得 Shadowrocket 並核對 App 身分，再依資料類型分別還原：訂閱 URL 回到 Subscribe；單一伺服器參數回到 Add Server；Config 內容則依設定檔流程檢查。還原後不要只看項目數量，還要確認訂閱可更新、手動參數完整無缺、Global Routing 與所需 Config 都已選妥。還原 App 購買項目屬於 App Store 購買紀錄問題，與伺服器資料能否重建是兩回事；前者請參閱已購項目還原說明。
如果不再使用某筆資料，刪除前還要檢查其他位置是否仍有相關設定引用。例如 Config 規則可能仍指向某個策略名稱；刪除對應資料不會讓規則文字自動變得正確。先確認引用關係，再清理不需要的項目。反之，如果只是暫時切換伺服器，不必靠刪除舊紀錄來達成；保持來源清楚並保存原始資料，通常更方便日後比對連線結果和訂閱變動。
本指南至此涵蓋從匯入到整理的完整管理流程。首次設定只需依照入門指南的主要步驟操作；遇到清單為空、參數不符或難以理解規則結果時，再回到相應章節逐項檢查。Shadowrocket 的取得方式為 App Store，開發者為 Shadow Launch Technology Limited，App ID 為 932747118；裝置相容性與系統需求以 App Store 頁面標示為準。一次買斷用戶端 ≠ 購買線路方案，伺服器資料應由你自行管理與核對。