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

複数のサブスクリプションをHomeで整理する方法を解説。グループ分けや並べ替え、古い登録の削除、重複ノードの確認手順を紹介します。

この記事の概要

利用中のサービスとサブスクリプションがある方を対象に、Homeでのグループ分けから、登録名・リストの順序・更新方法の整理、個別サーバーとサブスクリプション全体を削除する場合の違いまで解説します。最後に、接続情報の照合と接続テストで重複項目を確認し、並べ替え、選択中のサーバー、ルーティング設定を混同しないためのポイントをまとめます。

1. HomeのグループとConfigのポリシーグループの違い

ShadowrocketのHomeでは、まずサーバーリストのサブスクリプショングループを確認し、各サーバーの編集画面で登録元を照合します。グループはサブスクリプションから取得したサーバーを整理するためのものです。一方、Configで設定するポリシーグループはルールに応じた接続先の選択に使います。サブスクリプションをリストの上に移動しても、その登録元がルールで優先されるわけではありません。

サブスクリプションURLは利用中のサービス提供元から取得してください。複数のサブスクリプションは登録元ごとに個別に保存すると、名前の変更や更新、削除の対象が明確になります。リストを見やすくするために、すべてのサーバーを手動項目として何度も複製するのは避けましょう。元のサブスクリプション更新時に設定をまとめて置き換える利便性が失われます。

Home
サブスクリプショングループ、サーバーリスト、選択中の項目を確認
Config
現在のConfigとルール内のポリシー参照を確認
Settings
Subscribeを開き、サブスクリプションの更新設定を確認

まずは「登録元の名前・用途・現在使用中か」の3点を記録しておきましょう。ここでは整理例として「登録元A/日常用」と「登録元B/予備」を使います。すでに利用している2つのサブスクリプションを表す例であり、特定のサービスを推奨するものではありません。

2. サブスクリプションを1つずつ追加し、名前を付けてから更新する

Home右上の「+」をタップし、TypeをSubscribeに設定して、サブスクリプションURLとメモを入力します。登録元は1つずつ追加し、想定したグループが作成されたことを確認してから次を追加してください。リストが空になったり、グループが重複したりした場合に、直前の操作を特定しやすくなります。

  1. 登録元を準備する

    利用中のサービス提供元からサブスクリプションURLを取得し、アカウント管理ページのURLではなく、現在のアカウントに紐づくサブスクリプションであることを確認します。認証情報を含む完全なURLをメモや公開記録に貼り付けないでください。

  2. 追加画面を開く

    Home →「+」→ Type → Subscribeの順に進みます。サブスクリプションURLをURL欄に入力してください。個別サーバーのアドレスをサブスクリプションURLとして入力しないようにしましょう。

  3. メモを入力する

    Remarksに「登録元A/日常用」など、見分けやすい名前を入力します。登録元Bには別の接頭語を使い、両方のグループが「デフォルト」になって更新対象を判別できなくなるのを防ぎましょう。

  4. 保存して更新する

    保存後にHomeへ戻り、グループが表示されていることを確認してサブスクリプションを更新します。必要に応じてHomeを下に引いて更新してください。まずは追加したグループの結果を確認し、同じURLをすぐに何度も追加しないでください。

  5. 選択中の項目を確認する

    新しいグループを開き、サーバーの左にある丸印をタップして選択中の項目が切り替わったことを確認したら、Connectivity Testで接続を調べます。インポートが完了しても、そのグループ内のサーバーが選択されたとは限りません。

3. グループ・サーバーの並べ替えと選択中の項目

Homeに戻り、並べ替える対象がサブスクリプショングループ全体なのか、グループ内のサーバーなのかを確認します。該当するリストの編集・並べ替え操作で対象範囲を確認してください。画面の状態によってグループとサーバーの操作場所は異なります。操作前に対象のグループを開き、別のグループを並べ替えないようにしましょう。

名前による並べ替えは、名前が固定されたリストの整理に適しています。遅延による並べ替えは、テスト直後に候補を一時的に選ぶときに便利です。遅延テストの結果はネットワーク環境や測定方法に左右されるため、数値が最小の項目を最も安定した接続先と判断することはできません。サブスクリプション更新でサーバーリストが再生成される場合もあるので、手動で並べ替えた後は更新後に再確認してください。

対象整理の目的操作後の確認
サブスクリプショングループ日常的に使う登録元を見つけやすい位置に置く登録元の名前とグループ内のサーバーが対応しているか
グループ内のサーバー名前やテスト結果から候補を探す並べ替えが対象グループだけに適用されたか
サーバー左側の丸印現在使用するサーバーを選ぶ選択マークが意図した項目に付いているか
Config内のポリシールールに一致した後の処理を指定するポリシーが特定のサーバーやグループを参照しているか

ポイント:選択マークを確認してから並べ替えの効果を判断する

リストの先頭が現在のサーバーとは限りません。並べ替えたら、まず丸印が付いた項目を確認し、実際にリクエストを送ってみましょう。Configが特定のサーバーを参照している場合は、リストの順序を変え続けるのではなく、該当するポリシーを確認してください。

4. 登録元と接続情報を照合して重複を確認する

Homeで同じ名前のサーバーが2つ見つかったら、それぞれの編集画面を開いて接続情報を確認します。名前はメモにすぎず、同じ名前でも接続先が同じとは限りません。反対に、異なる名前でも同じサーバーを指している場合があります。削除が必要かどうか判断するには、まず登録元を確認し、プロトコル、アドレス、ポート、認証情報を比較してください。

たとえば、説明用の2つの項目がどちらもアドレスexample.com、ポート443と表示されていても、一方がTrojan、もう一方がVLESSなら、重複した接続先とは判断できません。プロトコルとポートが同じ場合も、認証情報、TLS、トランスポート設定を確認してください。これらは比較方法を説明する例であり、利用可能なサービスを示すものではありません。

重複を解消するために、サービス提供元が指定したポートやプロトコルを一律に変更しないでください。複数サブスクリプションの整理で変更するのは、登録元の記録や表示方法にとどめます。接続情報を変更してよいかどうかは、サービス提供元の設定に従ってください。

5. 古いサブスクリプションを削除する前に切り替えと参照先を確認

Homeで削除する前に、対象を確認してください。サーバーを1つ削除する場合はその項目だけが対象です。サブスクリプショングループを削除すると、登録元全体と関連するリストに影響します。対象の項目から削除操作を行い、確認メッセージでグループ名と削除範囲を確認してください。対象が明確でないまま続けて操作しないようにしましょう。

  1. 残すサブスクリプションから利用可能なサーバーを選び、Connectivity Testを実行して、実際に利用するページにもアクセスできることを確認します。
  2. Configを開き、現在有効な構成ファイルを確認します。ルールやポリシーが古いサーバー名やポリシーグループを参照している場合は、古い登録元を整理する前に参照先を変更してください。
  3. Homeに戻り、古いサブスクリプションを削除します。確認メッセージで、残す隣接項目ではなく削除対象の登録元全体が指定されていることを確認してください。
  4. 残すサブスクリプションを更新し、リストと選択中の項目が正しいことを確認します。必要に応じて接続を再確立し、確認済みの設定で新しいリクエストを送信してください。

6. 更新後に接続先が変わった場合はGlobal Routingを確認

HomeでGlobal Routingを開き、現在の設定がConfig、Proxy、Direct、Sceneのどれかを確認します。サブスクリプションの更新で取得するのはサーバーリストであり、リクエストのルーティング方法を決めるのはGlobal Routingです。それぞれを分けて確認してください。サーバーをリストの先頭に移動しても、Directの処理は変わらず、Config内のルールの代わりにもなりません。

Config

おすすめ

現在有効な設定に従ってリクエストを処理します。ルーティング設定が明確なユーザーに適しています。サブスクリプション更新後は、設定内のポリシーが引き続き対象を参照できるか確認してください。

適した用途:ルールとポリシーの参照先を確認したうえでの日常利用

Proxy

プロキシ経由でルーティングし、現在のサーバーの接続状況を確認します。問題の切り分けでは実際のリクエストも試してください。サーバーリストに表示された遅延値だけで接続結果を判断することはできません。

適した用途:現在のサーバーを一時的に確認し、ルールによる影響を抑えて調べる

Direct

リクエストを直接接続で処理します。この場合、サブスクリプション内のサーバーを切り替えても、プロキシ接続の有効な確認にはなりません。テスト前に必要なルーティング方法を確認してください。

適した用途:直接接続が必要な場合、または直接接続経路を確認する場合

Sceneを使用している場合は、現在のシーンに対応する設定も確認してください。固定された4つ目の接続経路と捉えないようにしましょう。一時的な調査が終わったら、必要なルーティング方法に戻し、実際のページに正常にアクセスできることを確認してください。

7. 複数サブスクリプションの更新と重複に関するよくある質問

2つ目のサブスクリプションを追加すると、1つ目は上書きされますか?

Home →「+」→ Type → Subscribeから登録元を新規作成する操作と、既存の登録元のURLを編集する操作は別です。保存後、2つの独立したグループがあることを確認してください。既存の記録でURLを置き換えた場合は、元のグループが新しい登録元に変更されているか確認します。

サブスクリプションの1つだけ更新がタイムアウトします。どう確認すればよいですか?

まず、その登録元のURLが完全で、アカウントが正常な状態か確認し、ほかの登録元が更新できるかも確認します。プロキシ経由で更新する必要がある場合は、Settings → Subscribeを開いてUpdate via Proxyを確認してください。有効なプロキシ接続が先に確立されている必要があります。この設定をオンにするだけで、利用できない接続経路が解消するわけではありません。

更新後、削除したノードが再び表示されるのはなぜですか?

サブスクリプションからそのサーバーが引き続き返されると、更新時に項目が再作成されることがあります。まず同じURLを二重に登録していないか確認してから、登録元全体を残すか、古いサブスクリプションを削除するか決めてください。ローカル項目を何度も削除しても、恒久的な除外にはなりません。

グループが多い場合、名前でまとめて削除できますか?

登録元ごとに1つずつ確認し、名前が同じという理由だけでまとめて処理しないでください。現在選択中のサーバーとConfigからの参照を確認したうえで、不要と判断した登録元を1つずつ削除します。操作のたびに、残すリストを確認してください。

整理後は、機密性の高いURLを含めずに登録元と用途を記録しておけば十分です。その後は「登録元を更新する、選択中の項目を確認する、ルーティングを照合する、リクエストを検証する」の順にメンテナンスすると、サブスクリプションの内容変更とローカル設定の問題を分けて調べられます。

App Storeで正規版を確認