この記事は、サービス提供元からサブスクリプションを入手済みで、複数の接続元を整理したい方を対象としています。まず取得元と現在の接続状況を確認し、取得元ごとにグループ分けして表示順を調整した後、重複や期限切れの項目を確認します。サブスクリプションの登録、サブスクリプション内のノード、Configはそれぞれ別のものです。Homeの一覧を整理してもルーティングルールは変わりません。また、ノードを削除しても、提供元からの更新内容にそのノードが含まれなくなるわけではありません。
サブスクリプション・ノード・Configの違い
ShadowrocketのHomeでは、サーバー一覧の確認、接続先の選択、接続の制御を行います。Subscribeの登録にはサブスクリプションのURLが保存され、更新時にはそのURLからサーバー情報を取得します。ノードは個々の接続パラメータです。Configでは設定ファイルを管理し、ルールやポリシーなどを設定します。サブスクリプションを追加しても、現在のConfigが切り替わるわけではなく、すべての接続がサブスクリプション間で自動的に選択されるわけでもありません。
整理を始める前に、Homeで現在選択中のノードとその取得元を控え、Global Routingと有効なConfigを確認します。特にConfigで固定のノード名やポリシーグループを使っている場合、名前の変更やノードの削除によって、以後の選択結果が変わることがあります。復元できる設定と元のサブスクリプションURLを先に保管し、削除後に名前だけで取得元を推測する事態を避けましょう。
取得元ごとに追加・グループ分け
複数のサブスクリプションは、地域別にまとめるのではなく、まず取得元ごとに分けましょう。取得元が異なってもノード名が同じ場合があります。「地域＋番号」だけで判断すると、一方の取得元の更新失敗を別の取得元の問題と誤認しかねません。サブスクリプションはサービス提供元から入手し、それぞれのURLの用途を確認してから、同時に保持する必要があるか判断してください。
-
登録済みの項目を確認
Homeを開き、登録済みのサブスクリプショングループを展開して、同じ取得元を追加済みでないか確認します。URLを比較するときは端末上で全文を確認してください。グループ名だけで判断したり、リンクを他人に送ったりしないでください。
-
サブスクリプションを追加
Home → 右上の「+」→ Add Server → TypeでSubscribeを選択します。URLにサービス提供元から入手したサブスクリプションURLを貼り付け、前後に空白や改行がないことを確認してください。
-
備考を入力
Remarksには「取得元A・日常用」「取得元B・予備」など、取得元と用途が分かる内容を入力します。パスワードや完全なtokenなどの認証情報は記載せず、保存してHomeに戻ります。
-
更新して確認
Homeをプルダウンして更新し、サブスクリプションの読み込みを待ちます。該当グループを開き、ノードが表示されているか、想定した取得元に分類されているか確認してから次のサブスクリプションを追加しましょう。一度に複数追加すると、問題の原因を特定しにくくなります。
グループ名は取得元の識別用、ノード名は接続先の選択用であり、同じ名前にする必要はありません。更新でローカルの名前が上書きされたり、Configで名前を参照する設定に影響したりするのを避けるため、まずはサブスクリプションから返されるノード名を維持しましょう。取得元が分かりにくい場合は、グループ内のノードを一つずつ改名するのではなく、サブスクリプション登録のRemarksを変更してください。
並べ替えで変わるのは表示順
並べ替えは表示上の設定であり、自動フェイルオーバーの設定ではありません。ノードを先頭に移動しても自動選択されるわけではなく、予備の取得元を一覧の下に移動しても接続パラメータは変わりません。整理する前に、サブスクリプショングループの順序と、グループ内のノードの順序のどちらを変更するのかを決め、2つの階層を混同しないようにしましょう。
- グループの順序：日常用の取得元を上に、予備の取得元を下に配置します。Homeのリスト編集画面で現在の一覧にドラッグハンドルが表示される場合は、対象の登録をドラッグして並べ替え、編集を終了します。移動の代わりに削除して再追加するのは避けてください。
- グループ内の順序：Homeの一覧にある並べ替え機能を使う場合は、まず適用範囲を確認します。名前順は番号で管理する項目を探すのに便利です。テスト結果順にする場合は、同じ範囲のテストを完了してから並べ替えてください。
- テスト条件：同じWi-Fiまたはモバイル通信を使って比較し、テスト中にネットワークを切り替えないでください。テスト未完了、タイムアウト、既に表示されている遅延値は、それぞれ異なる結果です。
- 更新後：サブスクリプションの更新によってノードが追加・削除されたり、順序が変わったりすることがあります。一度更新した後に表示順が維持されているか確認し、ローカルで一度並べ替えた順序が提供元で固定されているとは考えないでください。
画面レイアウトによって編集や並べ替えの入口は異なる場合があります。実際にHomeで利用できる操作を確認し、ドラッグハンドルがない場合は、すべてのグループを手動で移動できると決めつけないでください。グループ位置をカスタマイズできなくても、Remarksの命名を統一すれば取得元を識別できます。命名方法を頻繁に変えると、ノード名と表示順の両方が変わり、確認に手間がかかります。
要点：名前を統一してから更新後の順序を確認
グループ分けと並べ替えが終わったら、対象のサブスクリプションを手動で更新し、現在選択中の項目が想定した取得元のものか確認します。順序が提供元の並びに戻る場合は、取得元をRemarksで識別し、位置を保つために削除と再追加を繰り返さないでください。
ノードの重複はパラメータで確認
名前が同じだからといって重複とは限らず、名前が違っていても同じ設定を指している場合があります。プロトコル、サーバーアドレス、ポート、認証情報に加え、そのプロトコルで使用するトランスポートやTLSのパラメータを比較してください。たとえば2つの項目にポート443が表示されていても、同じポートが設定されていることしか分からず、接続先サーバーや認証情報が同じとは限りません。
| 表示されている状態 | 追加で確認する項目 | 判断の目安 |
|---|---|---|
| 名前が完全に一致 | プロトコル、アドレス、ポート、認証パラメータ | パラメータが異なる場合は取得元を区別して残し、名前だけでまとめて削除しないでください。 |
| アドレスとポートが同じ | TLS、Server Name、トランスポートパスなど、該当する項目 | 接続方式が異なれば、用途の異なる設定である可能性があります。 |
| 同じURLを2回追加した | 2つのSubscribe登録の完全なURL | 完全に同じと確認できた場合は、通常、取得元の登録を1つ残せば十分です。 |
| 異なるURLから似たノードが返される | 取得元の用途、認証情報、実際の接続結果 | まずはグループを残し、一覧の見た目だけで重複と判断しないでください。 |
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、共通の項目一覧をそのまま使って重複を判断しないでください。必要なパラメータはプロトコルごとに異なります。各項目の編集詳細を開き、そのプロトコルで実際に使用されるフィールドだけを比較してください。認証情報は端末上でのみ照合し、公開の重複チェックツールに入力しないでください。
同じサブスクリプションを重複して追加しただけなら、2つのグループからノードを一つずつ削除するのではなく、重複したSubscribe登録を整理してください。サブスクリプションから同じ項目が継続して返される場合、ローカルで削除しても次回の更新で再び表示されることがあります。長期的に削除する必要がある場合は、サービス提供元にサブスクリプションの内容を確認してください。URLのクエリパラメータをむやみに変更しないでください。見た目が似たURLでも、異なる権限や内容に結び付いている場合があります。
期限切れのサブスクリプションと個別ノードを削除
一度の接続タイムアウトだけで、サブスクリプションが無効になったとは限りません。サブスクリプション更新リクエストの失敗、特定ノードへの接続不可、現在のネットワークからサーバーに到達できない状況は、それぞれ別の問題です。どの段階で問題が起きているのかを確認してから、削除する対象を決めましょう。一時的に更新に失敗しただけで、利用中のサブスクリプションをすぐ削除する必要はありません。
- 代替の接続先を確認。Homeで、利用可能であることを確認済みの別のノードを選択し、実際に必要なページを開いてください。接続スイッチがオンになっているだけで判断しないようにします。
- 設定からの参照を確認。削除予定の名前がConfigのポリシーグループやルールから参照されていないか確認します。参照がある場合は、先に該当する選択設定を変更してから整理してください。
- ノードを1つ削除。Homeで対象のノードを左にスワイプし、削除操作を行います。削除対象がノードの行であり、サブスクリプショングループではないことを確認してください。サブスクリプション内の項目は、更新後に再び表示される場合があります。
- 取得元全体を削除。サブスクリプション登録を削除する前に、確認画面に表示される対象と範囲を読んでください。削除方法によって処理範囲が異なることがあります。削除後は、該当するグループとその項目が残っていないか確認します。
- 最後に再確認。Homeに戻り、現在選択中の項目、残っているサブスクリプション、接続結果を確認します。次に、残したサブスクリプションを更新し、必要な取得元を誤って削除していないか確認してください。
Global Routingで一覧の問題とルーティングの問題を切り分ける
整理後に「ノードを変更しても結果が変わらない」場合は、まずHome → Global Routingを確認します。ノード一覧で分かるのは「どの接続先があるか」であり、Global Routingで決まるのは「接続をどのポリシーで処理するか」です。以下の比較はルーティング選択の確認用であり、どのネットワークにも一律に適したモードを示すものではありません。
Config
おすすめ現在有効な設定に従って接続を処理します。ルールは順番に照合され、一致したルールのポリシーが適用されます。DIRECTルールに一致した接続は、Homeでノードを変更してもそのノード経由にはなりません。
適したケース：Configを確認済みで、ルールに従って日常的に使う場合
Proxy
通信をプロキシ経由で処理し、一時的にノードの接続状況を比較するのに使えます。テスト後は元のモードに戻してください。プロキシモードでの結果だけで、Configのルールが正しく適用されていると判断しないでください。
適したケース：ルールの選択とノードの利用可否の違いを一時的に調べる場合
Direct
宛先に直接接続します。このモードでは、Homeでプロキシノードを変更しても、同じリクエストがそのノード経由になるわけではありません。そのため、サブスクリプション内のノードの状態を比較する用途には使えません。
適したケース：現在のネットワークから直接接続した場合と比較する場合
Scene
設定済みのシーン条件に応じてルーティングを適用します。問題を調べるときは、現在どのシーンが一致しているかも確認し、ネットワーク環境による変化をサブスクリプションの並べ替えによる変化と取り違えないようにしてください。
適したケース：シーンを明確に設定しており、一致条件を確認できる場合
ConfigのDOMAIN-SUFFIX、GEOIP、IP-CIDRなどのルールは異なる宛先に一致することがあり、FINALはそれ以前のルールに一致しなかった接続を処理します。特定の宛先が常にDIRECTになる場合は、サブスクリプションを整理し続けるのではなく、一致しているルールを確認してください。接続を自動的に開始する動作を維持したい場合は、Settings → On Demandも確認します。この設定はサブスクリプションのグループ分けや一覧の並べ替えには関係しません。
サブスクリプション整理のよくある質問
削除したノードが更新後にまた表示されるのはなぜですか？
まず、そのノードがSubscribeから返される内容に含まれているか確認してください。提供元の内容に同じ項目が残っていれば、更新後に一覧へ再び追加されることがあります。同じURLを重複して追加していないか確認し、取得元の登録が1つだけなら、提供元に返される内容を問い合わせてください。項目を何度も個別に削除しないでください。
2つのサブスクリプションに同じ名前のノードがあります。片方をまとめて削除できますか？
名前が同じという理由だけで削除してはいけません。項目の詳細を開き、プロトコル、サーバーアドレス、ポート、該当する認証やトランスポートのパラメータを比較してください。さらに、2つのサブスクリプションURLが完全に同じか確認します。取得元の用途と内容を確認し、不要だと判断できた場合にのみ該当する登録を削除してください。
1つのサブスクリプションだけ更新に失敗しました。すべて追加し直す必要がありますか？
まずHomeで該当する取得元のURLを個別に確認し、リンクが途中で切れていないか、現在のネットワークからそのサブスクリプションURLにアクセスできるかを調べます。他の取得元を更新できるなら、すべての登録をいったん消す必要はありません。該当URLの権限やサービス状況は、サービス提供元に確認してください。
最速のノードを一番上に置けば自動で使われますか？
表示位置だけを理由に自動で切り替わることはありません。Homeに戻って実際に選択中の項目を確認し、Global RoutingとConfigのポリシー選択も確認してください。遅延テストの結果はその時点のネットワーク環境によるもので、実際の通信テストの代わりにはなりません。
整理する際は、一度に変更する項目を1つに絞りましょう。取得元のRemarksを変更し、次に順序を調整し、その後に重複や不要と確認できた登録を整理します。各手順の後に更新とテストを行えば、問題をどの操作が原因か特定しやすくなります。取得元が分からない長い一覧にすべてのノードをまとめるより、必要な取得元ごとの区別を残す方が、後の管理に役立ちます。