複数のサブスクリプションを整理するには、まず登録元を区別し、表示順を調整してから重複した登録を整理します。自身でサービスとサブスクリプションを利用しており、iPhoneまたはiPadでShadowrocketを使う方が対象です。手順に沿って登録元を確認し、同名ノードが重複しているかを判断して、削除前に復元に必要な情報を保管できます。ノードやサブスクリプションの提供・販売・推奨は行いません。
1. サブスクリプション、ノード、Configの違いを確認
サブスクリプションはノード情報を取得するための登録先、ノードは接続に使うプロトコルの設定一式、Configはルールなどの設定をまとめるものです。それぞれ役割が異なります。Homeにサブスクリプションを追加しても、独立したルーティングルールが自動で作成されるわけではありません。2つのノードグループを並べても、登録元が統合されるわけではありません。
整理を始める前に、Homeで各サブスクリプションのメモ、登録先、ノード数を確認します。「普段使い」「予備」「テスト」など、登録元を見分けられるメモを付けると便利です。メモは端末上で識別するためのもので、回線品質やサービスのランクを示すものではありません。認証情報を含むサブスクリプションURLをメモに記載しないでください。
| 項目 | 確認場所 | 整理時の役割 |
|---|---|---|
| Subscribe | Homeのサブスクリプション項目 | ノードの登録元を確認し、その登録元の更新や保持を管理します。 |
| ノード | Homeで展開したリスト | プロトコル、サーバー、ポート、認証パラメータを確認し、実際の接続先を選びます。 |
| Config | Config | ルールやポリシーからの参照を確認し、整理後も古い名前が参照されていないか調べます。 |
| 更新オプション | Settings → Subscribe | サブスクリプション関連の設定を確認します。利用できる項目は現在の画面で確認してください。 |
1つのサブスクリプションに、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなど、異なるプロトコルの項目が含まれる場合があります。プロトコルが異なるからといってサブスクリプションを重複して追加しないでください。また、表示名が同じという理由だけで削除するのも避けましょう。重複しているかどうかは、登録元と接続パラメータを照合して判断します。
2. 登録元ごとに追加・整理し、同じURLを重複登録しない
複数のサブスクリプションを利用している場合は、まず登録元を一覧にし、不足分だけを追加します。追加前にHomeで既存の項目を探し、サブスクリプションの編集画面でURLを比較してください。同じURLがすでに登録されている場合は、「+」から再追加せず、既存の項目を更新します。
-
登録元を記録
Homeで既存のサブスクリプションを1つずつ確認し、メモ、ノード数、用途を記録します。URL全体は自身で管理する安全な場所に保管し、公開の掲示板などに投稿しないでください。
-
不足分を追加
Homeの右上にある「+」→ Type → Subscribeを選び、自身が利用しているサブスクリプションURLを入力します。登録元を見分けられるメモを設定して保存してください。単一ノードのプロトコルではなく、Subscribeを選択したことを確認します。
-
1つずつ更新
Homeに戻り、該当するサブスクリプション項目の更新操作を使います。全体を更新する必要がある場合は、その後で下に引いて更新してください。まず1つ更新して結果を確認してから次に進むと、同時に変化して登録元が分からなくなるのを防げます。
-
グループを確認
該当するサブスクリプションを展開し、取得したノードが想定した登録元のものか確認します。その後、使わないグループは折りたたみます。登録元ごとのグループ分けはリストの整理に役立ちますが、そのグループを使うリクエストを自動で決めるものではありません。
URLが異なっていても、登録元が別とは限りません。旧URLと新URLが同じ内容を返す場合や、2つの登録先が同じアカウントに属する場合があります。用途は自身が保有する登録元の説明に基づいて確認し、「予備をもう1つ」といった理由だけで内容がまったく同じ登録を残し続けないようにしましょう。
3. グループの並べ替えと接続方針を分けて考える
並べ替えで変わるのは項目の探しやすさであり、自動切り替えの方針ではありません。ノードをリストの先頭に置いても、現在の接続に失敗したとき自動で引き継がれるわけではありません。「リストの表示順」と「リクエストの実際の経路」をそれぞれ確認すれば、表示の変化を接続の変化と誤解せずに済みます。
Homeで整理したいサブスクリプションまたはノードの操作メニューを開き、現在の画面で利用できる並べ替えや編集の操作を確認します。手動で移動できる場合は、普段使う登録元を前に配置します。名前や遅延による並べ替えしかない場合は、画面に表示される選択肢を使ってください。サブスクリプショングループの順序と、グループ内のノード順を混同しないようにし、一括操作の前に対象範囲を確認します。
- 登録元の順序：まずサブスクリプショングループを並べ、普段使うものを前に、予備を後ろに配置します。しばらく使わないグループは折りたたむと誤選択を防げます。
- グループ内の順序：名前順は特定の項目を探すのに便利です。遅延順は現在のテスト結果を確認しやすくしますが、遅延はスループットではなく、長期的な安定性を示すものでもありません。
- 更新後の確認：登録元から返される名前や項目が変わると、並び順にも影響する場合があります。更新後はよく使う項目を再確認し、以前の行番号を目印にしないでください。
以下では、並べ替えとルーティングの違いを説明するため、Global Routingの3つのモードを比較します。Sceneは自身の利用状況に合わせて個別に確認してください。サブスクリプションの数から動作を推測することはできません。
Config
推奨現在のConfigに設定されているルールに基づいて方針を決めます。ノードを整理する前に、使用中のConfigでポリシーグループや名前を使って該当項目が参照されていないか確認してください。すべての通信がHomeで現在選択中のノードを使うとは限りません。
適した用途：ルールに基づく振り分け設定を確認済みで、普段のルール動作を維持したい場合。
Proxy
リクエストをプロキシ経由にします。ルールの影響を切り分ける際に利用できます。この場合も、実際に選択されているノードまたはポリシーを確認してください。リストの先頭が自動選択されるわけではありません。
適した用途：既存のノードを一時的に検証し、接続パラメータとルールのどちらに問題があるかを切り分けたい場合。
Direct
直接接続にします。このモードでページを開けても、整理したばかりのプロキシノードが検証済みという意味ではありません。
適した用途：現在のネットワークで直接接続できるか比較して確認する場合。
結論：並べ替え後に選択中の項目を確認
並べ替えたら、Homeで使用するノードを明示的に選択し、Global Routingも確認してください。Configを使う場合は、実際に参照されているポリシーも確認します。リスト上の位置だけで接続先を判断しないでください。
4. 重複ノードはパラメータで判断し、名前だけで一括削除しない
「同じ名前」と「同じ接続設定」は別のものです。同じ名前でも、サーバーアドレス、ポート、プロトコルが異なる場合があります。同じサーバーでも複数のポートを開き、異なる認証情報を使っていることがあります。反対に、名前がまったく異なる2つの項目が同じ接続パラメータを使っている場合もあります。
| 表示上の状況 | 確認する項目 | 対処方法 |
|---|---|---|
| 名前は同じで、ポートが443と8443 | プロトコル、サーバー、認証、TLS、トランスポートのパラメータ | 同名だけを理由に削除しないでください。異なる接続先の可能性があります。 |
| サーバーとポートが同じ | パスワードまたはUUID、TLS Server Name、トランスポートの種類とパス | ほかのパラメータが異なる場合、別の接続設定の可能性があります。 |
| 同じサブスクリプションURLを2回追加 | URL全体、2つの内容、Configからの参照 | 有効だと確認できた登録元を1つ残し、重複したサブスクリプション項目を削除します。 |
| 同じ項目が2つの登録元に存在 | 登録元の用途と今後の更新方法 | まず残す登録元を決めます。ノードだけを削除しても、更新後に再び表示される場合があります。 |
表のポート番号は判断方法を説明するための例であり、入力を推奨する値ではありません。重複を解消する目的でサーバー、ポート、認証パラメータを変更しないでください。これらは自身の設定と一致している必要があります。WireGuardの場合は、パスワードやUUIDの確認方法を当てはめず、鍵の対応関係やEndpointなどのパラメータを比較します。
より安全に整理するには、まず重複登録されたサブスクリプションを削除し、次に複数の登録元にまたがる重複を確認し、最後に手動で追加した単独ノードを確認します。登録元が同じ項目を繰り返し返す場合、手動削除は端末上だけの対処で、次回更新時に再表示されることがあります。同じ行を何度も削除するのではなく、まず登録元から返される内容やフィルタ条件を確認してください。
結論：まず重複した登録元を整理
2つのグループが同じ完全なサブスクリプションURLから取得されている場合は、登録元を1つ残して更新を確認しましょう。片方のグループからノードを1つずつ削除するより、結果を保ちやすくなります。
5. 削除前に復元情報を保管し、削除後に参照を確認
サブスクリプションの登録を削除することと、サービスを解約することは別の操作です。端末上で項目を削除しても、元のサービスにおけるアカウント管理の代わりにはならず、登録元の認証情報が無効になるわけでもありません。URLの漏えいに対処する場合は、Homeの表示項目を削除するだけでなく、自身が利用する登録元のアカウント管理画面で認証情報を処理してください。
-
復元情報を保管
有効なサブスクリプションURLと必要な説明を自身で保管していることを確認します。アプリの設定バックアップやエクスポート機能を使う場合は、バックアップ範囲を確認し、すべてのサブスクリプション認証情報が必ず含まれると決めつけないでください。
-
接続先を切り替え
削除予定のグループ内のノードを使用中なら、先に接続を切るか、残すことが決まっているノードに切り替えます。その後、使用中のConfigでポリシーからの参照を確認してください。
-
登録元を削除
Homeで対象のサブスクリプション項目を削除し、確認画面に表示された対象と範囲を確かめます。子ノードの操作をサブスクリプション全体への操作と取り違えないでください。
-
結果を確認
残したサブスクリプショングループ、現在のノード、Configを確認します。Configに古いノード名への参照がある場合は、実際の構成に応じて変更し、接続とアクセスをもう一度検証してください。
更新失敗への最初の対処として、サブスクリプションを削除しないでください。まず以前の内容を保管し、URL、ネットワーク、登録元からの応答状況を確認すると、問題を特定しやすくなります。重複、登録元の停止、不要になったことを確認してから削除します。検証が終わっていない場合は、誤選択を防ぐため、まずグループを折りたたんでください。
6. 更新後の並び順の変化や重複の再表示に関するよくある質問
削除したノードがまた表示されるのはなぜですか？
まず、そのノードがサブスクリプションに含まれているか確認します。登録元が同じ項目を引き続き返す場合、更新後に再び追加されることがあります。Homeで登録元を確認してください。同じURLを重複して追加しただけなら、子ノードを削除し続けるのではなく、余分なサブスクリプション登録を削除します。
2つのサブスクリプションに同じメモを設定できますか？
メモを同じにしても登録元は統合されず、誤削除の原因になります。それぞれのサブスクリプション編集画面を開き、異なるメモを設定してURLを確認してください。まとめて探しやすくしたい場合も、まず登録元を見分けられる状態にし、その後でグループ内の名前や表示順を整理します。
並べ替え後に先頭の項目が変わりました。接続先も変わりますか？
並び順だけで判断しないでください。Homeに戻って実際に選択されている項目を確認し、Global Routingも確認します。Configを使っている場合は、ポリシーグループで現在選択されている項目も確認してください。特定の項目を使う場合は、先頭行に頼らず明示的に選択します。
1つの更新に失敗しました。すべてのサブスクリプションを追加し直す必要がありますか？
必要ありません。更新に失敗したサブスクリプションだけを個別に更新し、正常な登録元はそのまま残します。URL全体、現在のネットワーク、登録元の状態を確認し、Settings → Subscribeで関連する更新設定を確認してください。設定を変更する前に元の値を記録し、一度に変更する条件は1つにします。
整理を終えるたびに、残した登録元を更新できるか、よく使うノードが残っているか、現在のポリシーが想定どおりかを確認します。更新成功は取得と解析が完了したことを示すだけで、各ノードに接続できることを単独で証明するものではありません。実際に使う項目を選んで検証してください。
- 登録元の確認：同じ完全なURLは必要な分だけ残し、メモで用途を区別します。
- リストの確認：使わないグループを折りたたみ、並べ替えの対象範囲を明確にします。更新前の行番号を目印にしないでください。
- 接続の確認：Homeで選択中の項目とGlobal Routingを確認し、必要に応じてConfig内の参照も確認します。
- プライバシーの確認：トラブル情報を共有する前に、サブスクリプションの認証情報、パスワード、UUID、秘密鍵などの機密情報を隠します。