複数のサブスクリプションは、まず提供元ごとにグループ分けし、各グループ内で地域や用途を検索してから、候補サーバーだけを速度テストします。この記事では、一覧の検索、サブスクリプションのインポート時の絞り込み、ルーティングの違いを整理。2つのサブスクリプションを整理する手順、更新前後の確認方法、サーバーの消失・重複・速度テストのタイムアウトへの対処順も紹介します。登録はできてもサーバー一覧の管理に困っているv2rayNユーザー向けです。
サブスクリプショングループ・サーバー検索・ルーティングの違い
v2rayNのサブスクリプショングループは、サーバーの提供元を管理するための機能です。グループごとにサブスクリプションURLや更新設定を保存し、更新時にそのURLから取得したサーバー情報をクライアントに取り込みます。複数のプロキシサービスを利用する場合は、サブスクリプションを分けて保存しましょう。共有リンクをすべて1つの手動リストに貼り付けると、各サーバーの提供元や更新対象が分かりにくくなります。
グループを作成しても、プロキシ経由で接続するWebサイトが決まるわけではありません。サーバー一覧の検索は、現在表示される項目を絞り込むだけです。サブスクリプション設定のフィルターは、今回のインポート結果に影響する場合があります。ルーティングルールは、アプリからのリクエストをプロキシ経由、直接接続、またはブロックのいずれにするかを決めます。それぞれ作用する段階が異なるため、「仕事用グループ」を作るだけではドメイン単位のルーティング設定の代わりになりません。
| 操作 | 影響する対象 | 用途 |
|---|---|---|
| サブスクリプショングループを切り替える | 現在表示している提供元の範囲 | メイン用と予備用のサブスクリプションを別々に管理 |
| サーバー一覧を検索 | 現在表示中のサーバー | 名前にJPを含むサーバーを一時的に探す |
| サブスクリプションのインポートを絞り込む | 更新時に取り込む項目 | 条件を確認してインポート数を減らす |
| ルーティング | 実際のリクエストの接続先選択 | 指定したドメインを直接接続またはプロキシ経由にする |
提供元ごとに2つのグループを作り、それぞれ更新する
まずは提供元が明確な2つのグループを作り、よく使うサブスクリプションを「メイン-A」、もう一方を「予備-B」のように命名するのがおすすめです。名前は管理上の用途を示すだけで、クライアントが自動的にフェイルオーバーするわけではありません。同じサービスの異なるプランを利用している場合も、実際のサブスクリプションURLごとに分け、誤更新を防ぎましょう。
- 「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、新しいグループを追加して「メイン-A」と対応するサブスクリプションURLを入力します。保存前に、URLがサービス提供元のクライアント用サブスクリプションページから取得したもので、アカウントのログインページではないことを確認してください。
- 同じ手順で「予備-B」も追加します。初回設定では、提供元が付けた元の名前を確認できるよう、インポート時の動作は既定のままにして、フィルター条件はまだ設定しません。
- 保存したら「メイン-A」に切り替え、サブスクリプショングループのメニューから現在のサブスクリプションを更新します。「すべて更新」も選べる場合、最初は現在のグループだけを更新すると、失敗した提供元を特定しやすくなります。
- サーバーが一覧に表示されたことを確認し、「予備-B」に切り替えて同じ操作を行います。失敗した場合は、グループを何度も追加するのではなく、まず更新ログを確認してください。
- 各グループから代表的なサーバーを選び、名前、地域表示、プロトコルを記録します。URLの入力先を取り違えていないか、同じサブスクリプションを重複登録していないかも確認しましょう。
メイン-A
- 提供元
- 普段使うサブスクリプションURL
- 命名
- 「メイン」を固定の接頭辞にする
- 初回更新
- 現在のグループだけを更新
- 初回の絞り込み
- インポート時の絞り込みは設定しない
まず全件を正常にインポートできることを確認してから、サーバーを絞り込みます。
予備-B
- 提供元
- もう1つの独立したサブスクリプションURL
- 命名
- 「予備」を固定の接頭辞にする
- 初回更新
- 更新ログを個別に確認
- 利用方法
- 必要に応じてサーバーを手動で切り替える
グループ名を付けても、負荷分散や自動フェイルオーバーは設定されません。
サブスクリプションURLには通常、アカウントに関連するトークンが含まれるため、認証情報として扱ってください。スクリーンショットを共有する際は、URL全体、QRコード、アカウント情報を隠しましょう。問題の調査に必要なのは、エラーの種類、操作した画面、個人情報を伏せたサーバー名です。実際に利用できるサブスクリプションを公開する必要はありません。設定を移行する前に、エクスポートファイルにこれらの情報が含まれていないかも確認してください。
キーワードでサーバーを絞り込む：まず検索し、インポート時のフィルターはその後に検討
サーバー名の付け方に統一ルールはありません。同じ地域でも「日本」「JP」「Tokyo」など表記はさまざまで、サービス提供元が倍率、回線種別、期限の通知を名前に加えることもあります。まず対象のグループに切り替え、サーバー一覧の検索欄やフィルター欄で実際に使われているキーワードを1つずつ試しましょう。複雑なルールをいきなり作るより、結果を確認しやすくなります。
- 地域名：まず「日本」で検索し、見つからなければ入力を消してから
JPやTokyoを試します。結果が0件でも、現在の検索条件に一致しなかっただけで、その地域のサーバーがサブスクリプションにないとは限りません。 - 用途：サービス提供元がサーバー名に用途を含めている場合に限り、「専用回線」「ストリーミング」などで検索します。名前に付いたラベルだけで、目的のサービスに実際に接続できるとは判断できません。
- 倍率：名前に
0.5xや2xが含まれている場合は、どのような課金倍率なのかサービス提供元に確認してから、残す項目を決めましょう。数字は速度を保証するものではありません。 - 通知用の項目：名前に「残り通信量」「有効期限」が含まれる項目は、サブスクリプション情報の表示用かもしれません。通常のサーバーと一緒に速度テストしたり、利用中のサーバーに設定したりしないでください。
検索欄が正規表現に対応している、またはスペースが「すべての条件に一致」を意味すると決めつけないでください。通常のキーワード検索と、サブスクリプション設定の正規表現フィルターは別の仕組みかもしれません。JP|日本 を入力して結果が出ない場合、画面が縦棒を通常の文字として扱っている可能性があります。まず単一のキーワードで検索が機能することを確認し、使用中のバージョンで該当項目の説明を確認してください。
| 実現したいこと | まず行うこと | 避ける操作 |
|---|---|---|
| 一時的に日本のサーバーだけ表示する | 対象グループで実際の地域名を検索 | 他の地域の項目をそのまま削除する |
| 更新後も一部の名前だけをインポートする | サブスクリプションのフィルター条件を確認 | 検索欄の式をそのままフィルター欄にコピー |
| 一覧をすべて表示する | 検索をクリアし、必要ならインポートフィルターを解除してから再更新 | 条件を確認せず、クライアントだけを再起動する |
| プロトコルで項目を選ぶ | 一覧のプロトコル列と設定の詳細を確認 | メモ欄のVMessやVLESSの表記だけで判断 |
使用中のバージョンにサブスクリプションのフィルター欄がある場合は、条件が「一致する項目を残す」のか「一致する項目を除外する」のかを確認してから、元の条件を保存して変更してください。インポート時の絞り込みを一覧に反映するには、通常、サブスクリプションを再更新する必要があります。一覧でサブスクリプションのサーバーを手動削除しても、次回の更新時に再表示されることがあります。項目を継続的に減らすには、手動削除を繰り返すのではなく、内容を確認できる明確なフィルター条件を設定しましょう。
グループ別の速度テスト：候補を絞ってから比較
サブスクリプションをすべて登録した直後に、全サーバーを一斉に速度テストするのは避けましょう。大量の同時テストはローカル回線を圧迫するうえ、サーバー側の接続制限にかかる場合もあり、結果を比較しにくくなります。候補を少数に絞り、一覧からテストする行を明示的に選んで、サーバーメニューまたは右クリックメニューからテストを実行してください。「表示中」の項目が「選択中」と同じとは限りません。
以下は整理手順の目安であり、性能テストの結果ではありません。各回で同じネットワークとテスト先を使い、ファイルのダウンロードなどを同時に行わないようにします。時間をまたいで比較する場合は、遅延の数値だけでなくテスト日時も記録してください。
- まずポートへの接続を確認：TCP遅延は、サーバーのポートまで接続できるかを主に示します。サーバーポートが
443で接続に成功しても、プロトコル認証、TLS設定、接続先へのアクセスが正常とは限りません。 - 次に実際のリクエストを確認：クライアントに実際の接続遅延テストがある場合は、テスト先も記録します。プロキシのハンドシェイク、リモートへの接続、接続先サイトの応答に左右されるため、TCP遅延と同じ指標として直接比較することはできません。
- 必要な場合だけダウンロード速度を測定：速度テストでは通信量が発生します。候補を少数に絞り、サービス提供元の課金ルールを確認してから実行しましょう。並べ替えのためにグループ全体を何度もテストする必要はありません。
- 最後に用途を確認：サーバーを利用中に設定し、実際に使うサイトやアプリを開いて、ログイン、読み込み、その後も継続して使えるかを確認します。
結論：実際のリクエストが安定して完了するサーバーを優先
複数回続けて実際のリクエストを完了できた候補は、遅延が一度だけ低かった候補より優先しましょう。利用するサーバーを確認したら検索を解除し、一覧の先頭行を現在使用中のサーバーと取り違えないようにしてください。
サブスクリプションの更新方法：提供元と確認記録を残す
サブスクリプションの更新では、サービス提供元が現在返すデータを取得しますが、ローカルの変更がすべて保持されるわけではありません。サーバーのメモ、アドレス、ポートなどのパラメーターは更新時に置き換わることがあります。独自に変更した設定を長期保存したい場合は、手動管理のグループを別途作成し、そのコピーは元のサブスクリプションに合わせて自動修正されないことを明確にしておきましょう。
- 更新前：現在利用中のサーバーのグループ名とサーバー名を記録します。重要な会議やデータ転送の最中に、まとめて更新したりサーバーを切り替えたりしないでください。
- 更新時：問題が起きているグループを優先して更新します。直接接続で更新する方法とプロキシ経由で更新する方法がある場合は、サブスクリプションURLへの接続可否に応じて選びましょう。サーバーに接続できないからといって、サブスクリプションURLにも直接接続できないとは限りません。
- 更新後：成功・失敗のログを確認し、検索をクリアしてサーバーが正常に取り込まれたかを確認します。さらに、利用中のサーバーが一覧に残っていて、引き続き使えることを確認してください。
- 定期メンテナンス：使用中のバージョンに自動更新間隔の設定がある場合は、サービス提供元の更新頻度と実際の必要性に応じて設定します。頻繁な変更がなければ、数分単位で更新する必要はありません。
同じ名前の項目でも、同じサーバーとは限りません。比較する際は、少なくとも提供元、サーバーアドレス、ポート、プロトコル、トランスポートの設定を確認しましょう。2つのグループに同じ名前を付けていても、別アカウントの場合があります。一方、同じサブスクリプションURLを2回追加した場合は、優先して整理すべき重複です。メモの名前だけを基準に一括削除すると、設定の異なる有効な項目まで消してしまうおそれがあります。
よくある問題：サーバーが消える、更新結果が変わらない、グループの速度テストが失敗する
更新は成功したのにサーバー一覧が空の場合、まず何を確認すればよいですか？
まずサーバー一覧の検索をクリアし、更新したグループに切り替えてください。それでも空の場合は、サブスクリプションのフィルター条件が厳しすぎないか、ログに解析エラーが出ていないかを確認します。Webページの内容を取得できても、有効なサブスクリプションを取得できたとは限りません。ログインページやアカウントの期限切れを知らせるページでも、取得自体は成功と表示される場合があります。サービス提供元から適切なサブスクリプションURLを取得し直し、「ダウンロード成功」だけでインポート成功と判断しないでください。
更新後も一覧が変わりません。更新に失敗したのでしょうか？
必ずしもそうとは限りません。サービス提供元から返されたデータに変更がなければ、一覧がそのままなのは正常です。まず更新ログと選択したグループを確認し、検索条件が残っていないかも確認してください。新しいサーバーがあるのに表示されない場合は、インポートフィルターを調べましょう。変化を確認するためだけに、同じサブスクリプションを何度も登録しないでください。
グループ内のサーバーがすべてタイムアウトします。サブスクリプションを削除すべきですか？
まずテストの種類、システム時刻、ローカルネットワークを確認し、別のグループにある、利用可能と分かっているサーバーと比較してください。グループ全体で失敗する場合は、アカウントの期限切れ、サービス提供元の障害、プロトコル設定、テスト先が原因かもしれません。TCPテストが成功して実際のリクエストが失敗する場合は、コアのログで認証やハンドシェイクの情報を確認します。グループを作り直しても接続設定の問題は解決しません。
「予備-B」に切り替えると、通信は自動的に予備サーバーを使いますか？
グループの切り替えは、通常、一覧の表示を切り替えるだけです。利用するサーバーに設定する操作を明示的に行い、クライアントに表示される現在のサーバーを確認してください。システムプロキシの有効化、アプリがプロキシを使うかどうか、ルーティングの選択はそれぞれ別の設定です。ブラウザーとターミナルで動作が異なる場合は、それぞれのプロキシ設定を確認し、サブスクリプショングループの調整を続けるだけにしないでください。
整理後の日常メンテナンスでは、「提供元を確認→現在のグループを更新→検索条件をクリア→候補を絞り込み→利用中のサーバーを確認」の順に進めます。ドメインごとに直接接続するかプロキシ経由にするかを設定する場合は、応用設定でルーティングの説明を確認してください。グループはサーバーを整理し、ルーティングはリクエストを適切な接続先へ送ります。