v2rayNのサブスクリプショングループ設定:複数サービスの管理とサーバー絞り込み実践

複数のサービスを使うときに、サブスクリプショングループで提供元を分け、更新間隔を設定し、キーワードでサーバーを絞り込む方法を解説。グループごとの一括速度測定でノード一覧を整理できます。

この記事の要点

2つ以上のサブスクリプションをすでに登録していて、ノード一覧の整理に困っている v2rayN ユーザー向けの記事です。サブスクリプショングループを分けて更新頻度とノード範囲を管理し、キーワード絞り込みとグループ別の速度測定で接続先を選ぶ時間を短縮します。複数の提供元に合計数百ノードあっても、必要な地域や回線をすばやく見つけられます。

まずは提供元ごとに分け、すべてのノードを1つの一覧に混在させない

v2rayNでサブスクリプションを登録すると、サーバー名、アドレス、ポート、プロトコル、通信パラメータが個別の設定として解析されます。複数のサブスクリプションを同じ画面に表示すると、香港、日本、シンガポールなど名前の似たノードが混在しがちです。更新に失敗したり回線に問題が起きたりしたときも、どのサービス提供元の設定なのか判断しにくくなります。

サブスクリプショングループが解決するのは「提供元の管理」であり、プロトコル変換ではありません。通常は1つのグループに1つのメイン購読URLを割り当て、同じサービスの予備URLを設定することもできます。VMess、VLESS、Trojan などのノードは同じグループ内で共存でき、v2rayNは各サーバー設定に応じて適切なコア機能を呼び出します。グループ自体は整理、更新、絞り込みだけを担当します。

サブスクリプションを保存グループを更新キーワードで絞り込みグループの速度測定ノードを選択

提供元には、長期的に見分けやすい短い名前を付けましょう。たとえば「メイン-A」「予備-B」「低倍率-C」などです。「サブスク1」や「新しい購読」のような名前だけでは、3か月後に継続・停止・URL再取得の判断が難しくなります。グループ名に購読URLの機密パラメータを含める必要もありません。

サブスクリプショングループの作成:名前、URL、更新パラメータの設定方法

以下では v2rayN 7.x の中国語インターフェースを例にします。「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、新しい項目を追加して、別名、購読URL、更新間隔を入力します。7.xの一部のマイナーバージョンでは入口が「サブスクリプショングループ設定」または「サブスクリプション設定」と表示されますが、各項目の役割は同じです。保存してメイン画面に戻り、「サブスクリプショングループ」→「現在のサブスクリプションを更新」または「すべてのサブスクリプションを更新」を実行します。

複数グループを初めて作るときは、すべての提供元を連続して一括更新しないでください。まず1つ目を有効にして更新し、サーバー数と名前が想定どおりか確認してから次のグループへ進みます。空の一覧、形式エラー、大量の重複ノードが発生しても、追加したばかりのURLを正確に特定できます。

  1. 「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、「追加」を選択します。
  2. 別名には「メイン-A」のような安定した提供元名を入力し、完全なURLをそのまま名前に貼り付けないでください。
  3. 購読URLを入力して「有効」の状態にします。予備グループを一時的に使わない場合は無効にできます。
  4. 自動更新間隔は24時間または48時間に設定し、起動のたびにすべてのサブスクリプションへリクエストが送られないようにします。
  5. 設定を保存してメイン画面に戻り、現在のグループを手動で1回更新します。
  6. グループ名、ノード数、サーバー名、プロトコル列を確認してから、次のグループを追加します。

メインサブスクリプション

別名
メイン-A
状態
有効
自動更新
24時間
用途
日常接続
速度測定範囲
現在のグループ

更新頻度は標準的に設定し、低遅延・低倍率の回線を優先して残します。

予備サブスクリプション

別名
予備-B
状態
有効
自動更新
48時間
用途
障害時の切り替え
速度測定範囲
必要時に実行

頻繁に速度測定を行う必要はありません。メインの提供元に問題があるときだけ更新して再測定します。

現在のプロキシ経由でサブスクリプションを更新する必要がある場合は、まず利用可能だと確認済みのノードに接続し、対象のサブスクリプション設定で「プロキシ経由で更新」に類する項目を有効にします。この機能は購読リクエストの送信経路だけを変更し、無効になったURLを自動修復するものではありません。タイムアウトや空のレスポンスが続く場合は、URLがまだ有効か確認してください。

キーワード絞り込み:情報ノードを先に除外し、目的の地域を残す

サブスクリプションには接続可能なサーバーだけでなく、「残り容量」「有効期限」「プラン案内」などの情報ノードが含まれることもあります。これらは通常、サーバー名を使ってアカウント状態を示す項目で、速度測定しても意味がありません。まず情報語を除外し、その後に用途に合う地域名や回線名を残す順序で整理しましょう。

v2rayN 7.xでは、マイナーバージョンによって絞り込みの入口がサブスクリプション設定内やサーバー一覧の検索欄にある場合があります。サブスクリプション単位のフィルターは更新後に残る項目へ適用されるため、恒久的なルールに適しています。メイン画面のテキスト絞り込みは現在の表示だけを変えるため、一時的な検索に向いています。初回設定ではまずメイン画面でキーワードを試し、意図しない除外がないことを確認してからサブスクリプション単位のルールに登録してください。

絞り込みの目的 キーワード例 期待する結果 適用場所
情報ノードを除外 残り、有効期限、プラン、公式サイト 接続できない案内項目を削除 サブスクリプション単位のフィルター
香港のノードを残す 香港、HK、Hong Kong 名前が一致する香港回線だけを表示 メイン画面での一時的な絞り込み
低倍率を探す 0.2x、0.5x、低倍率 通信量の消費が少ないノードをすばやく特定 メイン画面での一時的な絞り込み
テスト回線を除外 テスト、実験、一時 不安定な候補を減らす サブスクリプション単位のフィルター

現在のバージョンが正規表現に対応している場合は、同義の地域名を1つのルールにまとめられます。入力前に画面の説明に「正規表現」または「Regex」と明記されていることを確認してください。通常のテキスト絞り込み欄は、文字列をそのまま照合するだけの場合があります。次の2つの式は、香港の地域名と一般的な情報ノードをそれぞれ照合するものです。まず一時的な絞り込みで結果を確認することをおすすめします。

地域の照合:(香港|HK|Hong Kong)
情報ノード:(残り|有効期限|プラン|公式サイト|通信量)

結論:恒久的に除外し、一時条件は必要に応じて使う

「残り」「有効期限」など変わりにくい情報語は、サブスクリプション単位の除外ルールに適しています。香港、日本、低倍率などの条件は利用場面によって変わるため、メイン画面の一時的な絞り込みに残す方が安全です。更新後に他の地域まで見えなくなるのを防げます。

フィルタールールが長くなるほど、誤って削除する可能性が高まります。たとえば「US」で米国ノードを探すと、別の英語名に含まれる連続文字まで一致することがあります。「港」も地域名ではないメモに一致する可能性があります。より確実なのは、サブスクリプションの命名規則を確認し、「香港」「HK-」や区切り記号付きの完全な語を優先する方法です。ルールを適用する前後でノード数も記録しておきましょう。

更新間隔の設定:過剰なリクエストと古い一覧を防ぐ

サブスクリプションの更新はノードの速度測定ではありません。更新では最新のサーバー設定をダウンロードして解析するだけで、サーバーが現在接続可能だとは限りません。速度測定は既存の設定に対してテストを行います。2つを分けて実行すれば、v2rayNを開くたびに複数の購読リクエストや大量の接続テストが発生するのを防げます。

日常的に使うメインサブスクリプションは24時間ごと、変更の少ない予備サブスクリプションは48時間または72時間ごとに更新するとよいでしょう。一時的なサブスクリプションや利用を停止した提供元は自動更新を無効にし、必要なときだけ手動更新します。サービス提供元から購読URLの再取得を求められている場合、間隔を変更しても古いURLの無効化は解決できません。

グループ種別 推奨間隔 速度測定の予定 適用状況
メイングループ 24時間 更新後に実接続の遅延を1回測定 毎日使用し、ノードの変化が比較的多い
予備グループ 48~72時間 切り替え前に再測定 メイン回線に問題があるときだけ有効化
低倍率グループ 24時間 ダウンロード前に測定 通信量倍率とスループットを確認
一時停止グループ 自動更新を無効化 実行しない 設定を残したまま一時的に使わない

複数グループをまとめて更新するときは、v2rayNのログでリクエスト結果を確認できます。更新が成功したのにノード数が0の場合、フィルター条件が厳しすぎる、購読内容の形式が変わった、URLが案内ページを返しているといった原因がよくあります。接続がタイムアウトする場合は、ネットワーク経路と「プロキシ経由で更新」の設定を確認してください。1回のタイムアウトだけでグループ全体を削除しないでください。

グループ別に一括速度測定:実接続の遅延で候補を絞り込む

サーバー一覧の整理が終わったら、全件ではなくグループ単位で速度を測定します。目的のサブスクリプショングループに切り替え、そのグループのサーバーを選択して実接続遅延テストを実行します。実接続遅延はプロトコルのハンドシェイクと対象への接続を含むため、アドレスの応答だけを見るより実際のプロキシ接続確立時間に近い指標です。ただし、ダウンロード速度と同じではありません。

メイングループに86ノードあるとします。まずキーワードで「香港、HK」を残し、候補を18件まで絞ります。実接続テスト後、タイムアウトした項目や一時的に無視する項目を除外し、120~220ミリ秒の範囲から3~5件を選びます。その後、普段使うWebページを開いたり短時間のダウンロードを行ったりして、初回表示の遅さ、継続的な揺らぎ、スループットの明らかな低下がないか確認します。

  1. 「メイン-A」グループに切り替え、予備の提供元が混ざっていないことを確認します。
  2. 絞り込み欄に地域名を入力し、86ノードを10~20件程度まで減らします。
  3. 現在の絞り込み結果をすべて選択し、実接続遅延テストを実行します。
  4. まずタイムアウト、エラー、500ミリ秒を超えるノードを除外します。
  5. 低遅延の結果から3~5件を残し、実際のWebページとダウンロード性能を確認します。
  6. サーバーを選択したらシステムプロキシを有効にし、ローカルの待受ポートが正常か確認します。

ローカルポートは「設定」→「パラメータ設定」に表示される値を基準にしてください。一部の設定では10808がローカルの混合ポートまたは SOCKS 待受ポートとして使われますが、バージョンやユーザー設定によって異なる場合があります。ログにポート使用中のメッセージが出たら、そのポートを使っている古いプロセスを終了するか、パラメータ設定で未使用のポート(例:10818)に変更し、保存後にコアを再起動します。

結論:速度測定は候補を落とすためのもので、永久的な順位付けではない

一度135ミリ秒だった結果が、混雑する時間帯にも最速とは限りません。実接続遅延でタイムアウトや高遅延ノードを先に除外し、複数の候補を実際に試す方が、ランキング1位を固定して使い続けるより確実です。

プロトコル名をそのまま速度順位として扱うべきでもありません。VMess、VLESS、Trojan は異なるプロキシプロトコルと組み合わせ方を示すもので、実際の使用感はサーバー負荷、入口の品質、通信方式、出口地域、ローカルネットワークにも左右されます。同じ地域内で接続性、遅延、安定性を比較し、倍率も考慮して選べばよく、プロトコル名が違うという理由だけで大量のグループに分ける必要はありません。

ルーティングとサブスクリプショングループは分けて考える

サブスクリプショングループは「どのサーバーがあり、どこから提供されたか」を決めます。ルーティングは「接続をプロキシ、直接接続、ブロックのどれで処理するか」を決めます。両者を混同すると、サブスクリプションを何度も入れ替えているのに、アクセス経路を実際に左右するルールが直っていないという結果になりがちです。

たとえばメイングループで VLESS サーバーを選択しても、ブラウザーのリクエストがそのサーバーを通るかどうかは、システムプロキシ、TUNモード、アプリ自体のプロキシ設定、そして v2rayN で現在有効なルーティングルールによって決まります。サブスクリプションを更新してもカスタムルートは自動変更されず、グループを切り替えてもルールの優先順位は自動修正されません。

サブスクリプショングループ

管理対象
サーバー設定
主な項目
名前、アドレス
更新単位
単一の提供元
絞り込み基準
ノードのメモ

提供元の分離、更新頻度の管理、速度測定範囲の縮小に使用します。

ルーティング

管理対象
接続リクエスト
主な項目
ドメイン、IP、ポート
実行結果
プロキシまたは直接接続
照合順序
ルールの優先順位に従う

通信経路を決めるために使用し、サブスクリプションのダウンロードやノード整理は行いません。

「ノードの速度測定は成功するのにWebページがプロキシを通らない」場合は、現在のサーバーがアクティブノードに設定されているか、システムプロキシが有効か、ローカルポートが待受中か、ルーティングルールが対象を直接接続にしていないかの順に確認します。更新はサーバー一覧を刷新するだけなので、何度もサブスクリプションを更新しないでください。

よくある問題:更新失敗、ノード重複、絞り込みによる誤除外

複数サブスクリプションの管理で問題が起きやすいのは、URLへのリクエスト、内容の解析、フィルタールール、速度測定範囲の4段階です。まずどの層の問題かを確認してから該当する設定を変更しましょう。すべての設定を削除して再登録するより、既存のグループ構成を保ちやすくなります。

サブスクリプションの更新がタイムアウトで失敗した場合は?

まず検証済みの利用可能なノードに接続し、「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、その提供元でプロキシ経由の更新を有効にしてから、このグループだけを更新します。それでもタイムアウトする場合は、URLが変更されていないか確認してください。

更新に成功したのに一覧が空なのはなぜ?

まず対象グループの包含・除外ルールを無効にして、手動で1回更新します。ノードが戻ればフィルター条件が厳しすぎます。0件のままならログの解析結果を確認し、購読URLがサーバー設定ではなく案内ページを返していないか確認してください。

2つのグループに同じノードがある場合は?

同じ購読URLを重複登録していないか、または2つのURLが同じ提供元から生成されたものではないか確認します。更新が安定しているグループを残し、もう一方を無効にして48時間様子を見て、問題がなければ削除します。

香港ノードを絞り込むと1件も残らないのはなぜ?

まずサービス提供元が実際に使っている命名を確認します。HK、Hong Kong、地域番号などの表記かもしれません。メイン画面の絞り込み欄でキーワードを1つずつ試し、ヒットすることを確認してからルールを組み合わせます。最初から厳しすぎる正規表現を設定しないでください。

実接続遅延は低いのにダウンロードが遅いのはなぜ?

遅延は接続確立時の応答時間だけを示します。低遅延の候補を3つ選び、それぞれ30~60秒テストして、継続速度と揺らぎを比較してください。同時にノードの倍率、サーバー負荷、現在の時間帯の混雑状況も確認します。

長期運用できるグループ管理の手順

サブスクリプション管理のために毎日整理し直す必要はありません。安定した命名を決めたら、週に1回、更新結果と異常ノードを確認すれば十分です。頻繁に変えるべきなのは現在の絞り込み条件とアクティブサーバーであり、グループ構成ではありません。

メイン、予備、低倍率の提供元をそれぞれ独立させれば、更新失敗の影響は1つのグループに限定されます。キーワード絞り込みは表示範囲を狭め、実接続の速度測定は明らかに使えない候補を落とし、ルーティングルールは実際のリクエスト経路を処理します。役割を分けて管理すれば、ノードが数百件に増えても日常操作を分かりやすく保てます。

クライアント入口 各プラットフォームのダウンロードを見る