利用中のサービスとサブスクリプションがある場合は、まず提供元ごとに整理し、その後に一覧の順序や重複項目を確認します。この記事では、Shadowrocketのサブスクリプション、ノード、ルール設定の違いを説明し、名前の付け方、グループごとの更新、重複ノードの確認、削除前のチェック方法を紹介します。基本は、内容を変更する前に提供元を確認することです。名前が同じだからといって、接続パラメータも同じとは限りません。
1. サブスクリプション・ノード・Configの違い
サブスクリプションは複数の接続設定を取得するための情報源で、ノードはその中に含まれる個々の接続設定です。1つのサブスクリプションに複数のノードが含まれる場合があり、同じノードが別のサブスクリプションや個別に読み込んだ項目としてHomeに表示されることもあります。そのため、Homeに似た項目が2つ表示されても、すぐに読み込みエラーとは判断できません。
Configはルール設定を管理し、Settingsはアプリの設定を管理します。Homeのサブスクリプション名を整理しても、Config内のルールやポリシーグループが変更されるわけではありません。ルール設定でノード名を指定したり、名前でノードを絞り込んだりしている場合は、名前の変更・更新・削除後に参照先も確認してください。
ここでいう「グループ」は、まずサブスクリプションの提供元ごとに一覧を見分けるためのものです。ルールから選択できるポリシーグループが自動で作成されるわけではありません。ドメインごとに異なる出力先を選ぶ場合は、Configのルールやポリシー設定を別途確認してください。サブスクリプションの備考だけでは設定できません。
2. Remarksで提供元を識別し、読み込み前に重複を確認
各サブスクリプションに、提供元が分かる変更しない備考を設定しましょう。サブスクリプションの識別情報とノードの用途は分けて記載します。たとえば、サブスクリプションの備考を「01-提供元A-普段用」「02-提供元B-予備」とし、ノード名はひとまずそのままにします。番号は手動で見分けるためのもので、アプリが自動で並べ替えることを意味しません。
- Homeを開き、既存のサブスクリプショングループを確認します。該当するサブスクリプションの編集画面を開き、URL（サブスクリプションのアドレス）が保存済みか確認してください。
- 新規追加が必要な場合は、Homeの追加メニューを開き、TypeをSubscribeに設定して、すでに利用しているサブスクリプションURLを入力します。
- Remarksに提供元を識別できる短い名前を入力します。保存後、そのサブスクリプションに想定したノードが表示されているか確認してください。
- 既存のサブスクリプションの名前だけを変える場合は、元のサブスクリプションのRemarksを編集します。表示名を変更するために再度読み込む必要はありません。
サブスクリプションの項目を確認
- Type（種類）
- サブスクリプションを追加する場合はSubscribeを選ぶのがおすすめです。初期値は現在のアプリ画面で確認してください。
- URL（サブスクリプションのアドレス）
- ご自身が利用している完全なURLを入力してください。共通して使える既定のURLはありません。
- Remarks（備考）
- 「01-提供元A-普段用」などがおすすめです。既定の内容は現在のアプリ画面で確認してください。
- 保存後の確認
- 新しいグループが表示されたかだけでなく、備考とノードの内容が一致しているか確認してください。
項目の場所は現在のアプリ画面で確認してください。ノードの編集画面をサブスクリプションの編集画面と取り違えないようにしましょう。
名前付けのポイント
- 提供元の識別
- 「提供元A」「提供元B」のように呼び方を統一し、「新しいサブスクリプション」のような曖昧な名前は避けます。
- 用途の識別
- 「普段用」「予備」など個人の用途を記載し、備考を品質評価として使わないようにします。
- 番号の接頭辞
- 01、02、03のように表記を統一すると、一覧の順序を目視で確認しやすくなります。
- 元のノード名
- 最初の整理では変更せず、提供元から返された内容と照合できるようにしておくのがおすすめです。
これは手作業で整理するための命名ルールであり、アプリの既定のグループ分けや並べ替え設定ではありません。
サブスクリプションURLにはアクセストークンが含まれている場合があります。提供元の重複を確認する際は、デバイス上で完全なURLを比較できますが、URL、QRコード、編集画面全体を他人に送らないでください。ドメインとパスが同じでも、トークンが異なれば権限が異なる場合があります。先頭部分だけを見て統合しないでください。
3. 並べ替えは現在の一覧機能に従い、番号だけで自動整列すると考えない
順序を整理するときは、「サブスクリプショングループの位置」と「グループ内のノードの位置」を分けて考えます。まず操作対象がどちらの階層かを確認し、画面に実際に表示される並べ替えや編集機能を使ってください。ノード一覧で一度操作しただけで、すべてのサブスクリプショングループが並べ替わったと判断しないようにしましょう。
- 手動で移動：一覧を編集モードにしたときに移動ハンドルが表示される場合は、よく使う項目を選びやすい位置に移動できます。該当する操作が表示されない場合は、ドラッグ手順を適用しないでください。
- 名前順：現在の画面に名前順の並べ替え機能がある場合は、先に名前の付け方を統一してから該当する並べ替え方法を選びます。番号を付けただけでは、自動で並べ替え方法が切り替わることはありません。
- 遅延の測定結果：テストで得られる数値は、その時点のネットワーク環境を反映したものです。提供元の分類の代わりにはならず、継続的なダウンロード速度を示すものでもありません。
- 更新後の順序：提供元から返されるノードの構成は変わることがあります。更新後は、よく使うノードの位置と現在選択中の項目を改めて確認してください。
ポイント：提供元の備考を先に統一し、その後でノードの位置を整理
よく使うサブスクリプションには「01-提供元A-普段用」と付け、常用ノードの元の名前も記録しておきます。更新後にノードの位置が変わっても、提供元から探し直せるため、一覧の何番目かに頼る必要がありません。
ノード名がConfigのポリシーから直接参照されている場合、並べ替えのために一括で接頭辞を追加するのは避けましょう。まずサブスクリプション側の備考を変更し、ポリシーの参照方法を確認します。名前への依存がないと分かってから、ノード名の変更を検討してください。
4. グループごとの更新：記録してから更新し、結果を確認
サブスクリプションの更新は、提供元からノード情報を再取得する操作です。既存ノードがオンラインかどうかを調べるだけの操作ではありません。提供元がノードを追加・削除したり、接続パラメータを変更したりすることがあるため、更新後に件数や名前が変わっても、必ずしも端末側の不具合とは限りません。更新前に、そのグループのノード数と使用中のノード名を記録しておくことをおすすめします。
- Homeで対象のサブスクリプションを探し、そのサブスクリプションに用意されている更新操作を実行します。操作の名称や場所は現在のアプリ画面で確認してください。
- 操作が完了するまで待ち、成功またはエラーの表示を確認します。更新を連続して実行しないでください。
- 更新前後のグループ内容を比較し、よく使うノードが残っているか、新しい項目がその提供元のものかを確認します。
- 現在選択中のノードを確認します。以前のノードが削除されていた場合は、引き続き利用できるノードを選び直し、そのノードに依存するポリシーも確認してください。
- このグループの確認が終わってから次のグループを更新し、問題がどの提供元にあるか特定しやすくします。
更新がタイムアウトした場合、今回の取得が完了しなかったことを示すだけで、すべてのノードが無効になったとは限りません。まず端末のネットワーク接続、サブスクリプションURLが完全か、提供元からアクセス権の変更が通知されていないかを確認し、アプリに表示されたエラー情報を確認してください。既存ノードで接続できても、その時点でサブスクリプションURLにアクセスできるとは限りません。
5. 重複ノードの整理：名前だけでなく接続パラメータを比較
同じ名前のノードでも、サーバー、ポート、伝送パラメータが異なる場合があります。名前が違っても、同じ接続設定を指していることがあります。整理する前に、それぞれの編集画面でパラメータを比較し、どのサブスクリプションから取得したか記録してください。プロトコルや認証情報が異なる項目は、表示名が似ているだけで削除しないでください。
| 確認項目 | 比較する内容 | 判断と対応 |
|---|---|---|
| サブスクリプションの提供元 | 同じ完全なサブスクリプションURLを重複して読み込んでいないか | ノードを1つずつ削除して更新で再び戻る前に、重複したサブスクリプションを先に整理します。 |
| プロトコルとアドレス | Type、サーバーアドレス、ポートが一致しているか | たとえばポートが443と8443では異なるため、同じ名前だけで重複と判断できません。 |
| 認証情報 | プロトコルに応じて、パスワード、UUID、鍵などの項目を比較 | 認証情報が異なる場合は別項目として扱います。確認内容を公開しないでください。 |
| 伝送方式とTLS | 伝送方式、パス、Host、SNI、TLS関連の設定 | サーバーとポートが同じでも、異なる接続方式を使用している場合があります。 |
| ルールからの参照 | Configでノード名や名前による絞り込み条件を使用しているか | 削除前に、参照先が存在しない項目にならないことを確認してください。 |
上記のポート番号は比較方法を示す例であり、特定の値に統一することを推奨するものではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは項目がそれぞれ異なります。実際のプロトコルに応じて確認し、現在の設定で有効なパラメータを維持してください。
同じ提供元を重複して読み込んだ場合は、備考が分かりやすく、参照関係も確認済みのグループを優先して残し、余分なサブスクリプションを削除します。異なる提供元の場合は、接続パラメータが同じでも、それぞれの更新関係を維持する必要があるか先に確認してください。端末上でノードを削除しても、提供元から今後配信されなくなるわけではありません。
- 同じ名前でもパラメータが異なる：残し、提供元の備考で識別します。
- 同じ提供元を重複して読み込み：完全なサブスクリプションURLを確認してから、サブスクリプション単位で整理します。
- 個別に読み込んだ項目とサブスクリプション内の項目が重複：個別項目を引き続き使うか確認してから、どちらを削除するか決めます。
- 削除後、更新すると再び表示される：その項目がサブスクリプションから配信されていることを示します。繰り返し削除するのではなく、端末上での整理方法を見直してください。
6. サブスクリプションを削除する前に、選択中のノードとポリシーの参照先を確認
ノードの削除とサブスクリプションの削除は別の操作です。実行前に、選択中の対象がグループか個別項目かを確認し、確認メッセージをよく読んでください。そのグループ内のノードを使用中の場合は、削除後に接続先が不明確にならないよう、利用可能と確認済みの別の項目に切り替えておくことをおすすめします。
- Homeで削除するサブスクリプションの編集または管理画面を開きます。画面のスワイプ操作で削除できる場合も、対象を確認してから実行してください。
- サブスクリプションのRemarksと提供元のアドレスを確認し、残す予定のグループではないことを確かめます。
- 削除の確認メッセージを読み、グループ内のノードも削除されるか確認してください。削除対象の範囲は、現在のアプリに表示される案内に従ってください。
- 削除後はHomeに戻り、グループと選択中のノードを確認してから、Configで関連するポリシーの参照先を確認します。
- 復元が必要な場合は、ご自身で安全に保管した元のサブスクリプションを使って再度読み込みます。端末上の記録を削除しても、提供元側のサービス契約が解約されるわけではありません。
接続結果を確認するときは、Global Routingで現在選択されているProxy、Direct、Config、Sceneも区別してください。これらの選択はリクエストの出力先を決めるもので、サブスクリプションの提供元を管理するものではありません。リクエストが想定したノードを経由しない場合は、サブスクリプションをさらに削除するのではなく、現在のルーティング選択と設定を確認してください。
7. 複数サブスクリプションの管理に関するよくある質問
備考に01、02を付けたのに、なぜ順序が変わらないのですか？
番号は名前の一部にすぎません。変更したのがサブスクリプションのRemarksかノード名かを確認し、現在の一覧に名前順の並べ替えや手動移動の機能があるか確認してください。該当する機能がない場合は、番号を識別の目安として使い、自動並べ替えの設定とは考えないでください。
削除した重複ノードが、更新後にまた表示されるのはなぜですか？
そのノードが提供元から返される内容に含まれている可能性があります。同じサブスクリプションを重複して読み込んでいないか確認してください。重複でない場合、サブスクリプションの更新関係を維持することと、提供元の項目を恒久的に削除することは別の問題です。端末上で削除しても、提供元側の内容は変更されません。
2つのサブスクリプションに同じ名前のノードがあります。片方を削除してもよいですか？
まず提供元、プロトコル、サーバー、ポート、認証情報、伝送パラメータを比較し、Config内の参照も確認してください。名前が同じというだけでは、重複とは判断できません。同じ提供元を重複して読み込んだと確認できてから、サブスクリプション単位で余分なグループを削除します。
サブスクリプションを一時的に使わないだけなら、削除が必要ですか？
通常はサブスクリプションを残したまま、別のノードを選べます。ConfigやSceneを使っている場合は、ポリシーの選択も確認してください。元の提供元情報を残せるため、再び使うときに読み込み直す必要がありません。削除は、端末上の記録を今後残さないと確認できた場合に適しています。
整理が終わったら、サブスクリプションの備考、提供元を識別する情報、よく使うノードの元の名前、ポリシーの依存関係を個人用に記録しておきます。トークンを含む完全なURLや認証情報は、別の安全な場所に保管してください。以後は更新のたびに変化した部分だけを確認すると、一覧全体を定期的に消去するより問題を追跡しやすくなります。