Shadowrocketの複数サブスクリプション管理｜グループ分け・並べ替え・重複ノードの整理

1. サブスクリプション、サーバー項目、Configを区別する

サブスクリプションURLはサーバー設定を取得するための入口で、1つのURLから複数のサーバー項目が返されることがあります。Homeに表示されるサーバー名は一意の識別子ではありません。同じ名前でも接続先が異なる場合があり、同じ接続先でもポートやプロトコルが異なることがあります。重複を判断する前に、各項目がどのサブスクリプションに属しているか確認しましょう。

Configでは、設定ファイルとルール、ポリシーなどを管理します。2つのサブスクリプションの備考を別々の名前に変えても、ルーティングルールが2組できるわけではありません。Homeでリストの順番を変えても、Config内のルールの評価順には影響しません。Settingsはアプリの動作を調整する画面です。それぞれ分けて管理しましょう。

たとえば提供元Aに12件、提供元Bに8件、手動追加した項目が2件ある場合、整理の前に3つのグループの件数をそれぞれ記録します。合計22件は照合の基準であり、特定の件数まで減らす必要があるという意味ではありません。整理後に件数が変わった場合は、どの提供元による変化か追跡できるようにしましょう。

2. 提供元ごとにグループ分けし、重複登録を防ぐ

有効なサブスクリプションの入口ごとに、「提供元A｜普段使い」「提供元B｜予備」のように、分かりやすい備考を付けましょう。備考は識別用に使い、サブスクリプションのtoken、アカウント情報、URL全体は記載しません。同じ地域名が付いているという理由だけで別々の提供元を同一グループとみなさず、提供元ごとの区分を維持してください。

1. 登録済みの入口を確認する

   Homeを開き、登録済みのサブスクリプショングループと備考を確認します。サブスクリプションの編集画面でURLを照合し、同じ入口がすでに登録されていないか確認してください。既存の入口を更新する場合、右上の「+」から再登録する必要はありません。

2. 不足している提供元を追加する

   入口が本当に登録されていない場合は、Home → 右上の「+」→ Type → Subscribeの順に進みます。URL欄に手元にあるサブスクリプションURLを貼り付け、Remarksに提供元を識別できる備考を入力して保存します。

3. 1件ずつ更新して確認する

   Homeに戻り、下に引いて更新します。最初に整理するときは、1回につき1つの提供元だけを処理しましょう。取得された項目、エラーメッセージ、件数の変化を確認すれば、複数のグループを同時に操作して変化の原因が分からなくなるのを防げます。

4. 元の記録を残す

   安全な自分用の記録に、提供元と備考の対応関係を保存します。確認結果を記録する場合は「提供元A：12 → 10」のような変化だけを記載し、サブスクリプションURL全体をスクリーンショットや公開記録に載せないでください。

サブスクリプションの更新は、既存の入口から内容を再取得する操作であり、同じ入口を新たに作成する操作ではありません。サービス提供元がURLを変更した場合は、既存の編集画面にあるURLを確認してから、URLを置き換えるか、別の提供元として追加するか判断します。tokenだけが異なる2つのURLも、見た目だけで同じものとは判断できません。

3. 並べ替えで変わるのは探しやすさ。実際のルーティングとは別

整理するときは、まず提供元ごと、次に用途ごとに分け、テスト結果による並べ替えは最後に行います。サブスクリプションやサーバーの並びを変更する場合は、Homeで対象のリストに対して、画面に表示される編集または並べ替え操作を使います。リストによって並べ替えられる項目は異なる場合があるため、ある場所で使えるドラッグや並べ替え機能が、すべてのグループで使えるとは限りません。操作後はHomeに戻り、提供元の区分が混ざっていないことを確認してください。

現在のリストで名前順や遅延順に並べ替えられる場合、名前順は特定の項目を探すときに、遅延順は一時的な確認に便利です。遅延順にする前に、同じ対象を同じ条件でテストしてください。昨日のWi-Fiでの結果と、今日のモバイル通信での結果をそのまま比較することはできません。ある時点でテスト結果が良くても、継続的な通信速度が速いとは限りません。

• 普段の並び順：よく使う提供元を先に、予備の提供元を後に配置します。備考を一定に保つと、更新後も見つけやすくなります。
• トラブル対処：対象の提供元だけを開き、そのグループだけをテストします。利用中のネットワーク、時刻、テスト結果を記録してください。
• 更新後の確認：選択中の項目が残っていることを確認します。提供元名を変更した場合は、以前の名前を参照しているポリシーも確認してください。
• 手動で並べ替えられない場合：提供元ごとのグループを維持し、統一した備考で項目を識別します。順番を整えるためだけに、サブスクリプション全体を重複登録しないでください。

実際のルーティングを確認するにはGlobal Routingを使います。リストを整理するついでにルーティングモードを変更しないでください。比較テストが必要な場合は、現在のモードとConfigを記録し、テスト後に元の状態へ戻します。

4. 重複ノードはパラメータで判断し、名前だけでまとめて削除しない

重複が発生する主な原因は、同じサブスクリプションを2回登録した場合と、異なるサブスクリプションから一部共通のサーバーが返される場合の2つです。前者では、通常、余分なサブスクリプションの入口を整理します。後者では、まず提供元ごとの区分を保ち、個々の項目を削除する必要があるか判断します。同じ名前のサーバーをそのまま削除すると、予備の接続まで誤って削除するおそれがあります。

確認する際は、サーバー項目の編集画面を開き、設定をむやみに変更せず内容を確認します。基本の比較項目はType、サーバーアドレス、ポート、認証情報です。TLS、SNI、通信方式および関連パラメータも比較してください。認証情報は端末上でのみ確認し、公開するトラブル記録にはコピーしないでください。

たとえば、2つのTrojan項目が同じアドレスの443番ポートに接続していても、SNIが異なれば別の設定である可能性があります。VLESSとVMessの項目は、名前が同じでもそのまま統合できる対象ではありません。プロトコル名とポート番号だけでは重複を判断できません。

5. 無効なサブスクリプションを削除する前に、更新経路を確認する

更新がタイムアウトしても、サブスクリプションが永久に無効とは限りません。URLへのアクセス失敗、認証の無効化、取得した内容の解析エラー、サーバーへの接続失敗を切り分けてください。最初の2つはサブスクリプションの取得時に、最後の問題はサーバーの利用時に発生します。リストを正常に更新できても、すべてのサーバーに接続できるとは限りません。

1. 元のURLと提供元の備考を残したまま、Homeで対象のサブスクリプションをもう一度更新し、具体的なメッセージを記録します。続けて何度も登録し直さないでください。
2. 自分のサービス提供元のアカウントで、URLがリセットされていないか、認証が有効かを確認します。URL内のtokenは機密情報です。他人に渡して動作確認を依頼しないでください。
3. 利用中のネットワークからサブスクリプションの入口にアクセスできず、他に利用可能なプロキシ接続がある場合は、Settings → Subscribe → Update via Proxyを確認します。プロキシが実際に利用できることを確かめてから、更新を再試行してください。
4. 更新に成功しても対象サーバーに接続できない場合は、その項目のパラメータとテスト結果を確認します。サブスクリプション全体をすぐに削除しないでください。
5. 提供元のサービスが終了した、URLが置き換えられた、または入口の重複が確認できた場合に、Homeで対象のサブスクリプションを削除します。操作対象がグループ全体か、個別の項目かも確認してください。

Update via Proxyを有効にしても、すべての更新エラーが解決するわけではありません。現在のプロキシ自体が使えない場合、それを使った更新では問題が繰り返されることもあります。設定を変更したら記録を残して1回だけ再試行します。改善しなければ元の設定に戻し、URL、認証、ネットワークからのアクセス可否を引き続き確認してください。

グループ全体を削除する前に、Configでそのグループ内の項目名が参照されていないかも確認してください。カスタムポリシーや特定のサーバー名を固定しているConfigでは、提供元を削除したり名前を変更したりすると、参照先の修正が必要になる場合があります。Homeを整理するために、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALをまとめて変更しないでください。これらのキーワードは通信の照合に使うもので、サブスクリプションの整理には使いません。

6. 複数サブスクリプションの管理でよくある質問

整理が終わったら、3つのことを説明できる状態にしておきましょう。各サブスクリプションの提供元、更新のたびに変わった内容、現在の接続先を決めているポリシーです。「提供元を確認 → 更新 → 変化を確認 → 接続をテスト」の順に管理すると、定期的にすべて削除して再登録するより、記録を明確に保てます。