まず押さえるポイント

選択を自動化する前に、実際のタスクを確実に完了するノードを選択してください。単一の低遅延結果は 1 つのプローブを表します。ビデオの再生、ダウンロード、サインイン、または長時間存続するセッションは検証されません。

1. 四つの測定で何を確認するか

緑色の数字は、その数字を生み出した原因がわかっている場合にのみ役に立ちます。宛先、プロトコル、時刻によってノードのランキングが変わる可能性があります。次の測定値は、交換可能なスコアではなく、補足的な証拠として扱います。

観察する項目 確認できること これだけでは確認できないこと
TCP 接続遅延 サーバーポートにすぐに到達できるかどうか プロキシ認証の成功、TLS およびターゲット アクセス
実際の接続テスト 構成がコアを介してテスト ターゲットに到達するかどうか すべてのサイト、UDP、または長時間セッションのパフォーマンス
ダウンロードのスループット テスト期間中の 1 つのパスの容量 ピーク時のパフォーマンス、低ジッターまたは会議品質
実際のアプリケーション タスク 実際のワークフローが成功するかどうか すべてのネットワークとデバイスで同じ結果

タイムアウトは診断ではありません。ノード、テスト宛先、一時コア、またはローカル ポートの競合が原因である可能性があります。多数の無関係なノードで同時に障害が発生した場合は、サブスクリプションを削除する前に、それらの共有テスト環境を調査してください。

2. 候補ノードを整理する

サブスクリプションの提供元ごとに分かりやすい名前のグループを作り、ノード数と更新日時を記録します。更新後は、使用中のノードが残っていることと、そのプロトコルが選択したコアに対応していることを確認します。公式の画面説明によると、サブスクリプションを更新すると遅延と速度の測定値は消去されます。更新前のスクリーンショットを現在の測定結果として扱わないでください。[1]

サブスクリプション URL にはアカウント用のトークンが含まれることがあります。スクリーンショット、共有表、オンライン変換サービスに URL 全体を渡すのではなく、提供元名・応答ステータス・エラーの種類を記録してください。変換は、形式の不一致を確認したうえで信頼できるサービスを使う場合に限って検討します。取り込みに失敗するたびに変換へ進む必要はありません。

実際に使う地域や経路をカバーする候補を 3〜5 個に絞って始めます。数百のノードを同時に測定すると、回線、CPU、測定先の処理能力を使い切り、普段の利用を反映しない結果になることがあります。

3. 条件をそろえて繰り返し測定する

  1. テスト条件を固定します。 クライアントとコアのバージョン、ネットワーク タイプ、テスト URL と時間を記録します。大規模な転送を一時停止します。比較中にルーティング、DNS、TUN の設定を変更しないでください。
  2. 1 つのノードを検証します。 手動で選択し、コアが起動することを確認して、実際の接続テストを実行します。ログ内のコア起動の失敗とリクエストのタイムアウトを区別します。
  3. 測定を繰り返します。 同じ宛先で 5 回確認し、成功回数、各回の所要時間、中央値を記録します。これは候補を絞るための初期確認であり、長期的な安定性を統計的に証明するものではありません。
  4. 実際のタスクで確認します。 このノードは、約 10 分間のブラウジング、ダウンロード、または独自のワークフローに使用します。停止、再接続、障害に注意してください。これは推奨される受け入れ期間であり、パフォーマンスを約束するものではありません。
  5. 別の時間帯にも再測定します。 自動グループに属するノードを決定する前に、通常使用するビジー期間を含めてください。

この表には架空の測定結果を載せていません。自分の接続環境で観察した結果を記入してください。

ノードのエイリアス 成功したチェック数 / 5 所要時間の中央値 タスクと結果 再測定日時
候補 A 未測定 未測定 要記録 要記録
候補 B 未測定 未測定 要記録 要記録
候補 C 未測定 未測定 要記録 要記録

4. 用途に合うポリシーを選ぶ

出口を頻繁に切り替えると、ログイン、ダウンロード、持続的な接続に影響することがあります。接続の継続性が大切な用途では、動作確認済みのノードを固定します。出口の変更を許容できる用途で、自動の低遅延ポリシーを検討してください。出口を切り替えても、既存の接続が途切れずに移行するとは限りません。対象アプリで動作を確認します。

利用可能な戦略はコアとバージョンによって異なります。現在の公式 UI ガイドには、最低遅延、安定性、負荷分散、ランダム選択など、いくつかの Xray ポリシーがリストされていますが、sing-box には別のサポートされているセットがあります。すべてのメンバーはグループのコアと互換性がなければなりません。[1] 1 つのビデオのドロップダウンがすべてのビルドで保証されるわけではありません。

サブスクリプション ノードの場合は、サブスクリプション グループと慎重にチェックされた名前フィルターから派生したメンバーシップを優先します。アップデート後にメンバーシップを再確認してください。公式ガイドでは、フィルターされたメンバーシップはサブスクリプションの変更に従う一方、手動で選択したサブスクリプション ノードは更新中に削除できると説明しています。[1] 自動ポリシーは、候補セットが空になっているか互換性がなくなった場合には機能しません。

5. よくある三つの誤解を解く

スコアは低いですが、ページが遅いです。 プローブと実際の Web サイトでは異なるパスが使用される場合があります。ページには追加のドメインも読み込まれる場合があります。 1 つのノードを固定し、遅いリクエストを特定し、そのルーティング決定を検査します。より良い数値を取得するためにプローブ URL のみを変更しても、ワークロードは修復されません。

サブスクリプション更新後にグループが動かない。 まず、フィルター、名前変更されたノード、およびプロトコルのサポートを確認してください。空のグループと広範な接続障害を区別できるように、手動で検証したフォールバック構成を保持してください。

自動選択は常に変化します。 使用中のバージョンに許容差や測定間隔の設定があれば、一項目だけ変更して観察します。設定がなければ、候補を減らすかノードを固定します。候補の状態が大きく変動する環境では、自動選択も安定しにくくなります。

6. 運用開始の判断と保守

候補ノードが対象のタスクを繰り返し完了でき、グループ全体が選択したコアに対応し、更新後も有効なメンバーが残り、確認済みの単一ノードへ戻せれば運用を始められます。過去の良い遅延値を集めるより、最近のテスト記録を残す方が役立ちます。

常にテストする必要がありますか? いいえ。プローブは帯域幅とリソースを消費するため、エンドポイントのレート制限に遭遇する可能性があります。接続が実際に変更される頻度を反映する再テストの頻度を設定します。

遅延が少ないとゲームの質が向上しますか? いいえ。UDP のサポート、ルーティング、パケット損失、サーバーの場所も重要です。 v2rayN プローブは、ゲーム内の遅延について保証するものではありません。

参考にした YouTube 動画

公開されている動画タイトル・説明・チャプター索引を、テーマ選びと画面操作の参考にしました。本文は独自に作成したガイドで、動画の書き起こしではありません。技術的な内容は以下の公式資料で確認しています。

公式資料と適用範囲

資料確認日:2026-10-26。メニュー名や機能はクライアント、コア、OS のバージョンによって異なります。本文のチェックリストは推奨する検証手順であり、実測済みの性能データではありません。

  1. 公式 v2rayN UI および設定ガイド
  2. 公式 v2rayN 購読ガイド
  3. 公式 v2rayN がサポートするコア

シリーズの関連記事