この記事は、v2rayNに2つ以上のサブスクリプションを保存し、数十から数百のノードを管理しているユーザー向けです。まず提供元ごとに購読グループを作り、地域・回線・用途を統一したメモで表記します。最後にキーワードフィルターと遅延順で候補を絞れば、更新後も再利用できるノード管理ルールを整えられます。
サブスクリプションの提供元、ノード属性、実行設定を分けて考える
複数のサブスクリプションを同じサーバー一覧に混在させると、ノード数の多さよりも、3つの階層が混同されることが問題になります。購読グループはノードの取得元、ノード名はサーバー側が示す地域や回線情報、現在の設定はv2rayNがその時点でXrayまたはv2flyコアに渡して実行しているレコードです。1つの階層を変更しても、他の2つが自動的に書き換わるわけではありません。
まず「購読グループ」→「購読グループ設定」でサブスクリプションを1件ずつ保存し、提供元ごとに個別の項目を作ることをおすすめします。複数のURLを判別しにくい名前へまとめるのは避けてください。グループの別名は「メイン-A」「予備-B」「テスト-C」のように、提供元と位置付けが分かる名前にします。「購読1」「購読2」だけでは不十分です。更新失敗、ノードの重複、通信量の期限切れが起きても、該当する提供元をすぐ特定できます。
更新の正常な流れは、v2rayNが選択したグループのサブスクリプションURLを読み取り、内容をダウンロードし、VMessやVLESSなどのノードレコードを解析して、そのグループへ結果を書き込むというものです。サーバー一覧に表示される名前は通常、サブスクリプションの内容に由来します。ローカルの絞り込みは表示するレコードだけを決めるもので、リモート側のサブスクリプションは変更しません。
メイングループ
- 別名
- メイン-A
- 更新方法
- 手動確認後に更新
- ノード範囲
- よく使う地域
- 確認頻度
- 週1回
日常的に使う安定した回線を残し、現在のノードを頻繁に変更しない。
予備グループ
- 別名
- 予備-B
- 更新方法
- 必要なときに更新
- ノード範囲
- 地域横断の予備
- 確認頻度
- 月2回
メイン回線に問題があるときだけ展開し、一覧上の視覚的なノイズを減らす。
専用グループ
- 別名
- 仕事-C
- 用途
- 固定業務
- ルーティング
- 独立したルールセット
- 変更方針
- テスト後に切り替え
固定出口が必要なノードと、日常の閲覧に使うノードを分ける。
観察グループ
- 別名
- テスト-D
- 用途
- 新回線の検証
- 保持期間
- 7日間
- 速度テスト回数
- 3ラウンド
安定性を確認してから日常の選択範囲へ移し、1回の遅延結果だけで判断しない。
フィルターしやすいノードメモのルールを作る
サーバー名は表記形式が安定している場合に限り、長期的なフィルターに適しています。同じ地域が「香港」「HK」「Hong Kong」「港」のように混在すると、検索結果はサブスクリプション側の命名に左右されます。地域、回線、用途、番号を固定位置に置く統一形式を決めるのが堅実です。たとえば「HK-IEPL-Work-01」とすれば、名前を見るだけでノードの属性を判断でき、1つのキーワードでもすばやく絞り込めます。
地域は2〜3文字の大文字を使い、回線種別はサブスクリプションに実際に記載された情報を残し、用途には確認済みの事実だけを書きます。ノード名だけを見て通常回線を専用線として記録したり、「低倍率」を「低遅延」と見なしたりしないでください。メモは分類のためのもので、遅延、速度、可用性はテストで確認します。
推奨形式：地域-回線-用途-番号
HK-IEPL-Daily-01
JP-BGP-Work-02
SG-Direct-Backup-01
US-Transit-Media-03- 地域フィールド：HK、JP、SG、US、DEなどの短い表記に統一し、同じ地域に複数の書き方を使わない。
- 回線フィールド：サブスクリプションに明記されたIEPL、BGP、Direct、Transitなどを使い、不明な場合はSTDとする。独自に推測しない。
- 用途フィールド：Daily、Work、Backup、Mediaなどを使えるが、これはローカル分類を示すだけで、ノードに特別な性能があることを意味しない。
- 番号フィールド：2桁にそろえる。名前順で並べたときも01、02、10の順序が崩れない。
結論：メモには変わりにくい属性だけを保存する
地域、提供元、用途はメモに適しています。一方、リアルタイムの遅延、残りの通信量、その日の速度は変動するため、テスト結果や購読状態の表示に任せてください。速度テストのたびに名前を修正する必要がなくなります。
特に注意したいのは、サブスクリプションの更新時に、リモート側のレコードをもとにノードが再生成される場合があることです。サーバーの表示名をローカルで変更しても、次回更新後に残るかどうかは、バージョン、グループ設定、ノードの照合結果によって異なります。重要な別名は単一ノードだけに保存せず、購読グループ名や独立した記録にも提供元の手掛かりを残してください。大量に整理する前に、5件のノードで更新を1回試し、ローカルメモが保持されるか確認すると安全です。
キーワードフィルターでサーバー一覧を絞り込む
フィルターの目的はノードを永久削除することではなく、現在の作業で確認する範囲を数百件から十数件へ絞ることです。対象の購読グループを開き、サーバー一覧のフィルターまたは検索欄に地域、用途、回線のキーワードを入力します。v2rayN 7.xは細かなバージョンによってコントロールの位置が少し異なる場合がありますが、原則は同じです。まず購読グループを限定し、次に名前をフィルターし、最後に表示された結果をテストして並べ替えます。
単一キーワードは日常の切り替えに便利です。たとえば「HK」で香港ノード、「Backup」で予備ノードを表示できます。複合条件を使う場合は、現在のバージョンが正規表現に対応しているか先に確認してください。通常のテキスト検索だけなら、「JP-BGP」のように統一メモのまとまった部分を使います。1文字だけの広すぎる検索語は、回線、用途、地域の複数フィールドに同時一致する可能性があるため避けましょう。
| 絞り込み対象 | 入力例 | 想定範囲 | 次の操作 |
|---|---|---|---|
| 特定の地域 | HK- |
香港ノード | 遅延テストを実行 |
| 地域と回線 | JP-BGP |
日本のBGPノード | 遅延の昇順で確認 |
| 仕事用途 | -Work- |
仕事用としてマークしたノード | 出口要件を確認 |
| 予備セット | -Backup- |
地域横断の予備ノード | 実際の接続をテスト |
上記の数字は絞り込みの順序を示しています。まず128件のレコードを地域で18件まで絞り、6秒以内に応答しなかったレコードを除外し、残ったノードを3ラウンド繰り返しテストします。あるノードが1回目は80ms、次は320msだった場合、最低値だけで先頭に置くべきではありません。3回の結果が集中しているか、連続タイムアウトが発生していないかを重視します。
結論：まずフィルター、次に速度テスト、最後に並べ替え
すべてのノードに完全なテストを何度も実行する必要はありません。グループと名前で候補を10〜20件に絞ってから、3ラウンドの遅延と実際の接続結果を比較すれば、操作が速くなり、異常値も見つけやすくなります。
並べ替えでは遅延、速度、安定性を分けて考える
v2rayNのサーバー一覧には、遅延、速度、テスト状態を表示できますが、それぞれが答える問いは異なります。遅延は探査の往復時間、速度テストは特定時点のデータ転送性能を示します。実際の可用性は、接続先、ルーティング、DNS、ローカルネットワークの影響も受けます。最低遅延がどの場面でも最高速度になるとは限らず、1回だけ速度が高くても夜間に安定するとは限りません。
「2回の粗い絞り込みと1回の実測」という順序がおすすめです。まず名前またはグループでフィルターし、次に遅延テストを実行して結果を昇順に並べ、連続タイムアウトや明らかな異常値を除外します。最後に上位3〜5件を1件ずつアクティブサーバーに設定し、実際に利用するサービスを開いて、コアログに接続タイムアウト、TLSハンドシェイク失敗、ルーティング拒否がないか確認します。
- サーバー一覧で購読グループを1つ選び、地域または用途のキーワードを入力する。
- 現在表示されているノードに遅延テストを実行し、一括処理が完了してから並べ替える。
- 30秒間隔で3ラウンド繰り返し、変動幅を記録する。1ラウンドだけの最低値は採用しない。
- 結果が安定したノードから3〜5件を選び、1件ずつアクティブサーバーに設定する。
- システムプロキシまたはTUNモードが現在の要件に合っていることを確認してから、実際のアクセスをテストする。
- 最終的な選択を用途メモに記録し、リアルタイムのミリ秒値はノード名に書き込まない。
並べ替えが終わっても、後ろにあるレコードをすべて削除することはおすすめしません。サブスクリプション提供元が入口や回線を変更することがあり、今日の遅延が高い予備ノードも別のネットワーク環境では使える可能性があります。一時的に使わないノードはフィルターで非表示にするか、予備グループへ移してください。明らかに無効で重複しており、更新後に再び現れないことを確認できたローカルレコードだけを削除します。
サブスクリプション更新で既存の分類を崩さない
整理結果を最も壊しやすいのは、提供元を確認せずにすべてのサブスクリプションを更新し、新しい一覧を見てすぐ一括削除する操作です。より安全なのはグループごとの更新です。更新前のノード数を記録し、1つのグループだけ更新して、追加・減少・改名を確認してからフィルターとテストを実行します。ノード数が42件から突然0件になった場合は、他の正常なグループを上書きせず、サブスクリプションURL、ネットワーク状態、更新ログを先に確認してください。
VMessとVLESSはノードのプロトコルであり、グループ分けの基準ではありません。1つのサブスクリプションに複数のプロトコルが含まれることもあり、同じ地域でも異なる通信設定が使われる場合があります。分類では提供元、地域、用途を優先し、プロトコル互換性や通信の問題を調べるときだけ、VMess、VLESS、TCP、WebSocket、TLS、REALITYなどのフィールドで具体的なノード設定を確認します。
更新後、手動で付けたメモが元の名前に戻った場合は？
まず更新によってノードレコードが再作成されたか確認します。安定した分類は購読グループの別名に置き、個々のノードには必要なメモだけを残してください。一括変更の前に、少数のノードで「名前を変更—サブスクリプションを更新—結果を確認」というテストを1回行います。
2つのサブスクリプションに同じノードがある場合、すぐ削除すべき？
まずアドレス、ポート、ユーザー識別子、通信方式、TLSパラメータを比較します。表示名が同じでも設定が同じとは限りません。すべての重要なパラメータが一致していることを確認したら、提供元が安定している一方を残し、もう一方はグループフィルターで非表示にします。
フィルター後もテスト結果が多く残るのはなぜ？
キーワードが短すぎないか、対象の購読グループを開いているか確認します。「J」を「JP-」に変更したり、「-Work-」のように区切り文字を含む完全なフィールドを使ったりすると、名前の誤一致を減らせます。
サブスクリプションの更新に失敗し、タイムアウトが表示された場合は？
まずサブスクリプションURLに引き続きアクセスできるか確認し、次に現在利用できるプロキシ経由で更新を試します。1つのグループだけが失敗している場合は、すべてのグループを何度も更新しないでください。ログのリクエスト時刻とステータスを確認し、その提供元だけを個別に対処します。
遅延順で並べた先頭のノードが必ず最良？
必ずしもそうではありません。少なくとも3ラウンド再テストし、上位3〜5件には実際のアクセスを行います。1回だけの最低ミリ秒値ではなく、変動が小さく、接続に連続して成功し、用途の要件を満たすノードを優先してください。
継続的に実行できる更新チェックリスト
- サブスクリプションURLごとに明確なグループを作り、提供元を混在させない。
- 更新前に、グループのノード数と現在のアクティブサーバーを記録する。
- 毎回1つのグループだけ更新し、確認を終えてから次のグループを処理する。
- 「地域-回線-用途-番号」のメモ形式に統一する。
- まず10〜20件までフィルターし、その後3ラウンドの遅延テストを実行する。
- ノード切り替え後に、システムプロキシ、ルーティングルール、コアログを確認する。
- 予備ノードを残し、1回のテスト結果で長期的な安定性を判断しない。
ノード数が数百件に達したとき、管理効率を左右するのは削除の徹底度ではなく、ルールの安定性です。サブスクリプショングループは提供元の追跡、統一メモは可読性、キーワードフィルターは候補範囲の絞り込み、繰り返しテストと実際のアクセスは最終選択を担います。この4ステップを固定すれば、購読内容が変化し続けても、数分で正しいグループと利用可能なノードを見つけられます。