本文適合已將多個自有訂閱匯入 Shadowrocket（小火箭）的使用者。重點是先在 Settings → Subscribe 管理訂閱來源，再回到 Home 測試並整理伺服器項目；清理時以來源分組為界線，重複項目則逐一核對協定、主機、連接埠與驗證參數。
先區分訂閱來源、伺服器項目與目前連線
多個訂閱管理容易混亂，通常是因為把三個層級當成同一件事。訂閱來源是由使用者既有服務商提供的 URL；伺服器項目是訂閱更新後寫入 Home 清單的具體記錄；目前連線則是 Home 中選取後交由系統 VPN 設定使用的項目。刪除其中一個層級，不一定會自動改變另外兩個層級。
例如，一個訂閱可以產生十多筆伺服器記錄，其中只有一筆處於選取狀態。單獨刪除某筆伺服器記錄，不等於刪除訂閱來源；只要來源仍存在，下次更新時該記錄可能再次出現。反過來，移除訂閱來源後，也應檢查與該來源相關的本機項目是否仍被保留。
依來源建立分組，先把訂閱名稱寫清楚
進入 Settings → Subscribe 後，先逐一核對已儲存的訂閱。名稱應能說明來源與用途，不宜只留下「訂閱 1」「備用」等難以追溯的文字。不同來源出現同名伺服器時，來源名稱是判斷重複項目歸屬的第一條線索。
新增來源時，只使用使用者自己已取得的訂閱網址。用來說明格式的範例值可以寫成 https://example.com/sub?token=xxxx。URL 中的查詢參數通常承擔身分或授權作用，複製時要保留完整字串，不要手動刪除 ?token=xxxx。
主要訂閱
- 入口
- Settings → Subscribe
- 名稱
- 來源 A · 日常
- URL
- https://example.com/sub?token=xxxx
- 更新檢查
- 確認時間與項目數量變化
名稱用來標示來源，不要以伺服器顯示名稱取代訂閱名稱。
備用訂閱
- 入口
- Settings → Subscribe
- 名稱
- 來源 B · 備用
- 更新方式
- 視需要手動更新
- 異常記錄
- 逾時、空白結果或驗證失敗
先確認備用來源可以正常更新，再清理舊來源產生的項目。
- 開啟 Settings，進入 Subscribe，記下目前存在的每個來源及其名稱。
- 依序觸發更新，每次只處理一個來源，觀察 Home 中對應分組或項目數量是否變化。
- 發現來源名稱不清楚時，先重新命名，再進行刪除或去重，避免把兩個不同來源混在一起。
- 更新完成後回到 Home，檢查選取的伺服器是否仍屬於準備保留的來源。
結論：先整理來源，再整理伺服器
如果直接從 Home 刪除同名項目，卻不檢查 Settings → Subscribe，下次更新可能會重新寫入這些記錄。先為來源命名並確認更新結果，可以減少重複清理。
按延遲排序前，先完成同一輪 Connectivity Test
只有在測試條件一致時，延遲排序才具備參考價值。先維持相同的網路連線方式，在 Home 對準備比較的伺服器執行延遲測試或 Connectivity Test，再依本輪結果排序。不要直接混合比較昨天在 Wi-Fi 下取得的數值與今天在行動網路下取得的數值。
測試結果可分為三類：顯示具體毫秒數，表示探測目標在本輪有回應；顯示 timeout，表示在測試時限內沒有取得有效回應；沒有結果或持續處於測試狀態，則應檢查目前網路、訂閱參數與應用程式權限。一次 timeout 不足以判定伺服器永久失效，可間隔一段時間再測兩次。
- 低延遲且可連線：保留在常用分組，實際開啟目標服務確認連線結果。
- 延遲較高但穩定回應：可移至備用範圍，不要只憑毫秒數直接刪除。
- 連續 timeout：核對協定、主機、連接埠、TLS 與驗證欄位，再判斷是否清理。
- 名稱相同但延遲不同：檢查主機與連接埠；顯示名稱相同不代表伺服器參數相同。
可連線記錄範例
- 協定
- Trojan
- 主機
- edge-a.example.com
- 連接埠
- 443
- 測試結果
- 186 ms
數值僅為記錄格式範例，請以裝置當次測試顯示為準。
待複核記錄範例
- 協定
- Hysteria2
- 主機
- edge-b.example.com
- 連接埠
- 443
- 測試結果
- timeout × 3
連續三輪逾時後，仍應先檢查 UDP 可達性，以及伺服器端參數是否已變更。
測試期間還要確認 Global Routing。Proxy 會讓流量統一經過目前代理伺服器，Direct 直接連線，Config 依目前設定檔中的規則處理，Scene 則依場景設定運作。如果停在 Direct，即使網頁能開啟，也不能證明選取的伺服器已生效；如果使用 Config，則應檢查 DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 的比對順序。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY刪除失效訂閱時，以來源作為批次清理界線
需要批次處理失效項目時，最清楚的界線是訂閱來源，而不是伺服器顯示名稱。先在 Settings → Subscribe 確認某個來源確實已停止更新、回傳空內容或不再使用，再移除該來源。執行刪除前，記下其中仍需保留的手動伺服器，避免把來源項目與手動新增的項目混在一起。
具體按鈕文字可能會隨 App Store 目前頁面對應的應用程式介面調整，但判斷順序不變：開啟訂閱記錄、核對 URL 與名稱、確認準備刪除的來源、閱讀刪除確認框，再回到 Home 檢查相關項目。如果確認框詢問是否同時處理本機伺服器，應依是否仍需要這些項目來選擇，不要連續快速確認。
- 在 Home 記下目前選取伺服器的協定、主機與連接埠，必要時先切換到準備保留的伺服器。
- 進入 Settings → Subscribe，開啟目標來源並執行一次更新，確認失敗不是暫時性的網路波動。
- 核對訂閱名稱與完整 URL，確保刪除對象與記錄中的失效來源一致。
- 刪除來源，並依確認框說明決定是否同步處理該來源產生的本機項目。
- 回到 Home，重新執行 Connectivity Test，檢查清單中是否仍有原來源的殘留記錄。
結論：批次刪除應從訂閱記錄開始
依來源移除比依顯示名稱逐一刪除更容易複核，也能避免下一輪訂閱更新把同一批伺服器重新加入 Home。
移除重複節點，要比較連線參數而不是名稱
重複節點最常見的情況是兩個訂閱產生相同的顯示名稱，但顯示名稱本身不能作為唯一判斷依據。一個名稱可能指向不同主機，也可能是同一主機的不同連接埠。真正的重複項目至少應比較協定類型、伺服器主機、連接埠與驗證參數；啟用 TLS 的協定還要比較 SNI、ALPN 等欄位，使用傳輸層設定時也要檢查 path、host 或其他對應值。
Shadowsocks 應重點比較主機、連接埠、加密方式與密碼；VMess 與 VLESS 還需要核對 UUID、傳輸方式與 TLS 設定；Trojan 要比較密碼與 SNI；Hysteria2 需要核對主機、連接埠、驗證資訊及相關 TLS 欄位；WireGuard 則應比較公鑰、Endpoint、Allowed IPs 與本機位址。參數不同的記錄，即使名稱相同，也不應直接當作重複項目刪除。
可判定為重複
- 協定
- Trojan
- 主機
- edge.example.com
- 連接埠
- 443
- SNI
- edge.example.com
- 驗證
- 完全一致
主要連線參數一致時，再依來源更新可靠性保留其中一筆。
不能只按名稱合併
- 顯示名稱
- Tokyo 01
- 記錄 A
- edge-a.example.com:443
- 記錄 B
- edge-b.example.com:8443
- 協定
- 均為 VLESS
- 結論
- 主機與連接埠不同
顯示名稱相同只是標籤重複，不代表底層連線目標重複。
去重鍵範例：
協定 | 主機 | 連接埠 | 驗證參數 | 傳輸方式 | TLS/SNI
Trojan | edge.example.com | 443 | password-A | TCP | edge.example.com
VLESS | edge.example.com | 443 | uuid-B | WS | cdn.example.com如果兩個來源確實包含同一部伺服器，應優先保留更新成功、來源標示清楚且參數完整的記錄。刪除另一筆後立即更新其原訂閱進行驗證：如果重複項目再次出現，表示它仍由該來源維護。此時可以保留來源並接受重複顯示，或在服務商提供的訂閱管理範圍內調整內容；不要透過任意修改密碼、連接埠或 UUID 來製造表面差異。
更新訂閱後，檢查 On Demand 與規則狀態
完成訂閱整理後，應進行一次閉環驗證。先在 Home 選取要保留的伺服器，再執行 Connectivity Test，接著確認 Global Routing 所處狀態。如果平時使用 Config，還要開啟目前設定並確認規則依由上而下的順序比對，最後由 FINAL 處理未命中的請求。
如果啟用了 On Demand，入口位於 Settings → On Demand。這項設定可以依網路條件觸發連線或中斷，測試多個訂閱時可能使連線狀態自動變化。排查期間應記錄目前的 On Demand 條件，包括 Wi-Fi 與行動網路下分別採取的動作，避免把自動切換誤判為伺服器失效。
訂閱更新後，剛刪除的伺服器又出現了？
進入 Settings → Subscribe 找到它所屬的來源。只刪除 Home 中的項目不會改變訂閱內容；需要整批移除時，應處理對應來源並再次檢查本機清單。
兩個節點名稱完全相同，應該刪除哪一個？
分別開啟記錄，比較協定、主機、連接埠、驗證參數、傳輸方式與 TLS/SNI。參數完全一致時，保留更新穩定且來源名稱清楚的一筆；參數不同則不要依名稱合併。
延遲最低的伺服器為什麼無法開啟目標頁面？
先檢查 Global Routing 是否處於 Direct，再執行 Connectivity Test。使用 Config 時，繼續核對規則順序與 FINAL 動作；延遲探測成功不等於所有應用程式請求都會依預期分流。
訂閱更新一直顯示 timeout，該如何排查？
先確認裝置網路與系統時間正常，再檢查訂閱 URL 是否完整。目前連線可用時，可在 Settings → Subscribe 核對 Update via Proxy 的設定，然後重新更新一次並觀察是否回傳項目。
整理清單後，連線狀態自行發生變化？
進入 Settings → On Demand，檢查 Wi-Fi 與行動網路條件下設定的動作。排查時也要記錄 Home 的目前伺服器、Global Routing 狀態與系統 VPN 狀態。
- 確認 Settings → Subscribe 中只保留仍需使用且能辨識來源的記錄。
- 確認 Home 目前選取的伺服器屬於保留來源，並完成一次實際連線測試。
- 確認重複項目已依完整參數核對，不以顯示名稱作為唯一刪除依據。
- 確認 Global Routing、Config 規則與 On Demand 條件仍符合原本的使用方式。
- 之後每次新增訂閱，都先命名來源，再更新、測試與去重，避免清單再次失去界線。