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

1. サブスクリプション・ノード・ポリシーグループの違い

サブスクリプションURLはノードの接続情報を取得するためのものです。ノードは、読み込み後に実際の接続先として使うサーバー項目です。1つのサブスクリプションに複数のノードが含まれることがあり、同じノードが複数のサブスクリプションに含まれる場合もあります。一覧に重複して見えても、読み込みエラーとは限りません。異なる提供元から同じ接続設定が返されている可能性もあります。

Homeでサブスクリプションごとに表示されるグループは、主に項目の所属先を管理するためのものです。一方、Configのポリシーグループは、ルールで使用する出力先を選択するために使います。両者は別の設定です。サブスクリプションの名前を変更しても、ポリシーグループは自動作成されず、DOMAIN-SUFFIXやFINALが参照するポリシーも変わりません。

サブスクリプションを整理するときは、現在動作しているConfigとノードの選択を維持してください。ルールの変更、DNSの調整、サブスクリプションの削除を同時に行うと、接続に問題が起きた際に原因を特定しにくくなります。Global RoutingのProxy、Direct、Config、Sceneはサブスクリプションの重複を解消する機能ではありません。ルーティング設定を変えても、提供元の重複は解決しません。

2. 提供元ごとにグループ分けして、1件ずつ登録

グループ名には「提供元と用途」を含めましょう。たとえば「提供元A・通常用」「提供元B・予備用」のようにします。「香港」「日本」など地域名だけでは、複数のサブスクリプションに同じ地域のノードが含まれることがあり、後から更新や削除をするときに対象を特定できません。ここでのA、Bは、利用者自身が管理する提供元を区別するための記号です。

1. まずHomeで、登録済みのサブスクリプションと手動追加したノードを確認し、現在使用中の項目がどの提供元に属するか記録します。同じURLがすでにある場合は、再登録せず既存のサブスクリプションを更新してください。
2. 利用中のサービス提供元から、サブスクリプションURLを取得します。Homeの追加画面から登録し、種類がSubscribeになっていることを確認してください。サブスクリプションURL全体を、個別ノードのサーバーアドレス欄に入力しないでください。
3. サブスクリプションの編集画面で、見分けやすい名前またはメモを入力します。Remarks欄がある場合は、提供元を区別する記号などを記録できます。画面の構成はプラットフォームによって異なるため、実際に表示される項目を確認してください。
4. サブスクリプションは1件ずつ登録し、その提供元のノードが表示されたことを確認してから次を追加します。複数の提供元をまとめて貼り付けてから確認すると、重複項目がどこに属するか追跡しにくくなります。
5. Homeに戻り、2つの提供元についてノード数と名前をそれぞれ確認します。サブスクリプションURLの例はhttps://example.com/sub?token=xxxxです。これは説明用のダミー値で、実際の接続には使用できません。

3. 表示順の整理と接続先の選択を分けて考える

並べ替えで変わるのは項目の表示順であり、ノードが自動的に切り替わるわけではありません。地域や用途が固定されている場合は名前順、現在のネットワーク環境で一時的に比較する場合は遅延順が便利です。測定時刻、ネットワーク環境、接続先によって結果は変わるため、1回の測定で遅延が低かったことを、長期的に速い証拠と考えないでください。

現在のプラットフォームや画面にサブスクリプションの順番を手動で並べ替える機能がない場合、順序を整えるために何度も削除と再登録を繰り返す必要はありません。提供元名を統一して検索範囲を絞り、画面に用意されている並べ替え機能を使いましょう。ノードが多い場合は、すべてを1つの長い一覧にまとめるより、使わない提供元を折りたたむほうが管理しやすくなります。

4. 重複の判断はノード名だけでなく接続パラメータで

重複かどうかを判断するには、少なくともプロトコル、サーバーアドレス、ポート、認証情報を比較し、さらにプロトコル固有の項目も確認します。たとえばTrojanではSNIとTLSの設定も比較が必要です。サーバーアドレスとポートが同じでも、パスワードやSNIが異なる場合、互いに置き換えられるとは限りません。逆に、接続パラメータが同じで表示名だけが違う場合は、重複している可能性があります。

1. まず、同じサブスクリプションを重複して登録していないか確認します。URLが同じでノード一覧も一致する2つの登録は、通常、片方を残せば十分です。削除する前に、残すほうの登録が正常に更新できることを確認してください。
2. 異なるサブスクリプションに一部同じノードが含まれている場合は、まず提供元ごとの所属を維持します。日常の検索時に邪魔であれば、予備の提供元を折りたたみ、同じ名前の項目をすぐに削除する必要はありません。
3. 重複している可能性がある項目は、接続パラメータを1つずつ比較します。ドメインが同じIPアドレスに解決されることだけを、重複の根拠にしないでください。共通の接続先や異なるTLS設定がある場合、その判断は成り立たないことがあります。
4. Configでノード名を参照するポリシーがないか確認します。参照されている項目を削除する前に、関連ポリシーの選択先を残す項目に変更し、接続を確認してください。

サブスクリプションを更新すると、提供元から返された内容が再取得されます。サブスクリプション内のノードだけを個別に削除しても、次回の更新で再び表示されることがあります。ローカルで変更した名前も、更新によって元に戻る場合があります。重複を継続的に整理するには、重複した登録元を処理するか、利用中のサービス提供元に返却内容を確認してください。ノードを1件ずつ削除しても、永久に除外できるとは限りません。

5. サブスクリプションの更新・削除を安全に行う手順

1回更新に失敗しただけで、サブスクリプションが無効になったとは限りません。現在のネットワークからURLにアクセスできない、リンクのtokenが変更された、サービス提供元から異常な内容が返されたなど、さまざまな原因が考えられます。サブスクリプションの取得とノードへの接続は別の処理です。以前のノードに接続できてもURLが有効とは限らず、更新が成功しても、すべてのノードに接続できるとは限りません。

1. Homeで対象のサブスクリプションだけを更新し、エラーメッセージを記録します。他の提供元でも失敗していないか確認してください。先にすべてのサブスクリプションを削除しないでください。
2. 元のURLが完全な状態か確認し、特にクエリパラメータがメッセージアプリで途中までしかコピーされていない場合に注意します。tokenを含むURLは、利用中のサービス提供元との確認に限って使用してください。
3. サブスクリプションURLへのアクセスにプロキシが必要だと確認できた場合に限り、Settings → SubscribeのUpdate via Proxyを確認します。有効にする前に利用可能なプロキシ接続が必要です。更新に失敗している提供元に依存して接続する状態を作らないでください。
4. 更新に成功してもノードが空の場合は、まずサービス提供元側の返却内容、アカウントの状態、サブスクリプションの種類を確認します。原因がわからないうちに、引き続き利用できる古い項目を削除して何度も登録し直さないでください。
5. 提供元のサービスが停止した、または新しいURLに置き換わったことを確認してから、代替のサブスクリプションを検証し、古いものを削除します。削除後は、Homeで現在のノードを、Configでポリシーの参照先を確認してください。

削除する前に、確認ダイアログで対象範囲を確認してください。ノード1件の削除、サブスクリプション登録の削除、その提供元に属するノードも同時に削除する操作は、それぞれ異なる場合があります。現在の画面に表示される説明に従い、登録を削除すれば関連項目がすべて同じ方法で処理されると思い込まないでください。

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

整理が終わったら、tokenやパスワード全体を含まない管理メモを残しておくと便利です。提供元の識別名、用途、利用中かどうか、その提供元に依存するポリシーを記録します。以後は「提供元を1つずつ更新し、接続を確認してから削除する」順に進めると、サブスクリプションの内容、表示順、ルーティング設定の問題を切り分けやすくなります。ルールとポリシーの項目は設定項目の説明、ルーティング方式の違いはプロキシモードの説明をご覧ください。