V2Rayが遅いときの原因究明：ノード・回線・ローカル設定を3段階で確認

プロキシの速度が急に落ちたとき、プロトコルを変えたり、Muxを有効にしたり、クライアントを何度も再インストールしたりしても、原因究明が早まるとは限りません。ダウンロード速度は、ノードの負荷、接続回線、ネットワーク間の混雑、接続先の応答、ローカルのプロキシモード、端末性能が複合して決まります。まず再現可能なテスト条件を整え、一度に変更する項目を1つに絞りましょう。

まず速度測定の基準を作り、遅延と帯域幅を混同しない

遅延とスループットは同じ指標ではありません。遅延テストは1回の往復にかかる時間を示し、ノードが接続を確立しやすいかの判断に役立ちます。ダウンロード速度は一定時間に転送できるデータ量を示し、ノードの出口帯域、接続先サーバーの速度制限、TCP輻輳制御の影響も受けます。遅延45msのノードがスループット8Mbpsしか出ないこともあれば、遅延130msのノードが安定して120Mbps出ることもあります。

テスト前に、クラウドストレージの同期、システム更新、ブラウザのバックグラウンド動画を停止します。同じ端末、同じ接続ネットワーク、同じ対象ファイルを固定し、連続して3回測定してください。初回接続にはDNS検索やTLSハンドシェイクが含まれる場合があるため、2回目と3回目の結果を記録するのがおすすめです。3回の結果が92、95、90Mbpsならノードは比較的安定しています。88、21、76Mbpsのようにばらつく場合は、最高値だけで判断せず、負荷とパケットロスを引き続き確認します。

第1段階：ノード自体の混雑や制限を確認する

ノード側の問題には、主に3つの特徴があります。同じネットワークで一部のノードだけ遅い、終日遅く複数回の測定がほぼ同じ上限に張り付く、接続数を増やすと遅延が急上昇する、というものです。まず同じ地域にある複数のノードを横並びで比較します。ノードAが18、20、19Mbps、ノードBが86、91、88Mbpsなら、ローカルネットワークやクライアントが主なボトルネックである可能性は低いでしょう。

遅延一覧は初期選別にしか使えません。v2rayNの遅延テストはノードの応答時間を確認しますが、ダウンロード性能を直接示すものではありません。まずメイン画面でノードを選び、遅延テストを実行します。その後、遅延が近い2つのノードで実際にダウンロードしてください。遅延62ms・スループット15Mbpsのノードと、遅延75ms・スループット96Mbpsのノードなら、ダウンロードには後者を優先します。

1. テスト環境を固定する

   ほかのダウンロードを停止し、同じ有線または無線ネットワークを使います。テスト中に接続方式を切り替えないでください。各テストは少なくとも60秒続けます。

2. ノード情報を更新する

   v2rayN 7.xのメイン画面で「サブスクリプショングループ」→「すべてのサブスクリプションを更新」を開き、ノードアドレス、ポート、トランスポート設定が最新のサブスクリプション由来であることを確認します。

3. 遅延で絞り込む

   候補ノードでTCP遅延テストを実行し、タイムアウトが続くノードや変動幅が300msを超えるノードを先に除外します。最小遅延だけで結論を出さないでください。

4. スループットを実測する

   候補ノードを3つ選び、同じタスクを各3回実行します。平均速度、最低速度、読み込み開始までの時間を記録します。

5. ログを確認する

   「ヘルプ」→「ログを表示」を開き、テスト中にハンドシェイクのタイムアウト、接続リセット、接続先到達不能が集中していないか確認します。

VMess、VLESS、または異なるトランスポート方式への切り替えは、サーバー側が対応する設定を提供している場合にのみ意味があります。プロトコルはクライアント側だけで変更できる高速化スイッチではありません。プロトコルを比較する際は、できるだけ同じサーバー、同じポート、同程度のセキュリティ層を使い、端末性能、入口回線、出口帯域の差が結果に混ざらないようにします。

第2段階：回線、時間帯、接続ネットワークを比較する

回線混雑には、時間帯による明確な傾向が現れることがあります。昼間は90Mbpsで安定しているのに、夜20:00〜23:00は15Mbpsまで低下し、遅延も70msから220msに上がるなら、ピーク時の混雑が疑われます。同じ地域の複数ノードを試しても同時に遅くなる場合は、クライアントのパラメータを何度も変えるのではなく、接続回線を比較してください。

最も有効な比較方法は、同じノードを維持してローカルの接続ネットワークだけを変えることです。ノードを固定した状態で、自宅のブロードバンド回線が18Mbps、別のネットワークが82Mbpsなら、ボトルネックはローカルの通信事業者ネットワーク、ルーティング経路、家庭内機器にある可能性が高いでしょう。2つのネットワークがどちらも18Mbpsで安定するなら、ノード負荷と出口側の制限に戻って確認します。

第3段階：ポート、DNS、ルーティング、システムプロキシを確認する

同じ端末ではすべてのノードが遅いのに、同じネットワークを使う別の端末は正常なら、ローカル設定を確認します。v2rayNのローカル受信ポートは10808が一般的ですが、実際の値は「設定」→「パラメータ設定」の内容を優先してください。ブラウザ、ダウンロードツール、システムプロキシは現在の待ち受けポートを指定する必要があります。古いポートが別のプログラムに使われている場合も、接続失敗やプロキシの迂回につながります。

システムプロキシとTUNモードでは、トラフィックの入口が異なります。システムプロキシは、システムプロキシ設定に従うアプリだけを処理します。TUNモードは、より低いレイヤーでトラフィックを捕捉します。切り分けでは複数の入口を同時に重ねないでください。まずTUNを無効にし、「システムプロキシを自動設定」だけを有効にして基準値を測定します。その後、必要に応じてTUNを単独でテストすれば、差が捕捉方式によるものかノードによるものか判断できます。

1. コアを確認する

   「設定」→「パラメータ設定」→「Coreの種類」を開き、選択中のコアが現在のサブスクリプションに含まれるVMess、VLESS、トランスポート設定を処理できることを確認してから、コアを再起動します。

2. ポートを確認する

   「設定」→「パラメータ設定」でローカル待ち受けポートを確認します。10808の場合、ブラウザやダウンロードツールも127.0.0.1:10808を使用します。

3. プロキシモードを統一する

   ステータスバーの「システムプロキシ」→「システムプロキシを自動設定」からテスト環境を作ります。システムプロキシを変更するほかのプログラムは一時的に終了してください。

4. ルーティングを簡素化する

   「設定」→「ルーティング設定」を開き、判断しやすい基本ルールを一時的に使用します。対象リクエストがプロキシ、直接接続、ブロックのどれで処理されているか確認してください。

5. DNSを再テストする

   システムのDNSキャッシュを消去し、コアを再起動します。ログで名前解決の待ち時間が長い場合は、ローカルDNSとプロキシ側の名前解決をそれぞれテストし、安定した方を採用します。

テスト条件：Windows 11 24H2、v2rayN 7.x
ローカルアドレス：127.0.0.1
ローカルポート：10808
1回の測定時間：60秒
測定回数：3回
記録項目：TCP遅延、最初のレスポンスまでの時間、平均Mbps、最低Mbps、エラーログ

ルーティングは実際の通信経路を直接変えます。ダウンロード用ドメインが誤って直接接続と判定されると、測定結果はプロキシノードではなくローカルネットワークの速度になります。本来直接接続すべきローカルネットワークや中国本土向けサービスをすべて遠隔ノードへ送ると、迂回によって遅くなることもあります。ルールを確認するときは、まず適用順を見てください。通常は前のルールが先にアウトバウンドを決めるため、すでに一致したリクエストを後続ルールが引き継ぐことはありません。

Muxとプロトコルの切り替えが有効になる条件

Muxは複数の論理接続を少数の下位接続に多重化します。複数の小さなウェブリソースを同時に開く場合など、多数の短い接続を確立するコストを減らせる可能性があります。ただし、単一の大容量ファイルのダウンロードが速くなるとは限りません。下位接続でパケットロスが起きると、複数の論理ストリームが同時に待たされ、高帯域でもパケットロスの多い回線では速度の変動がかえって大きくなる場合があります。

Muxが現在の環境に適しているかは、同じノードで無効・有効を切り替え、ページの初回表示と大容量ファイルのダウンロードを比較して判断します。無効時の平均が94Mbps、有効時が61Mbpsで、ウェブページの体感差も小さいなら無効のままにします。多数の短い接続で初回表示が2.8秒から1.7秒に短縮され、大容量ファイルのスループットが大きく低下しないなら、有効のままでもよいでしょう。

• 単一ファイルのダウンロードが遅い：Muxを無効にして比較し、開始数秒のピーク値だけでなく、持続的なスループットを確認します。
• ウェブページに小さなリソースが多い：読み込み完了までの時間を記録し、有効化前後で最初のレスポンスと合計時間を比較します。
• 回線のパケットロスが目立つ：まずノードまたは経路の問題を解決してください。多重化しても失われた帯域は取り戻せません。
• プロトコルを切り替える場合：サブスクリプションが提供し、サーバー側と一致するVMess、VLESS設定だけを使用します。クライアント側だけで認証やトランスポートパラメータを変更しないでください。
• REALITY設定：サーバー名、公開鍵、短いID、フロー制御パラメータは相互に一致している必要があります。接続できたからといって、回線が必ず速いとは限りません。

決めた順序で最終的な切り分けを行う

目的は一時的に最速の数値を見つけることではなく、ボトルネックがどの層にあるかを特定することです。ノード層では横並びの差、回線層では時間帯とネットワークの比較、ローカル層では端末間の差と設定の適用状況を確認します。この3段階を終えれば、「接続はできるが遅い」問題の大半を検証可能な範囲まで絞り込めます。

1. 元の測定結果を記録する

   現在のノードについて3回分の遅延とスループットを保存し、日付、時間帯、接続ネットワーク、プロキシモードを明記します。曖昧な体感だけに頼らないようにしましょう。

2. ノードを横に比較する

   同じネットワークで少なくとも3つのノードをテストします。一部のノードだけ遅いなら、ノード負荷、出口、設定の問題に分類します。

3. 時間帯を縦に比較する

   同じノードを非ピーク時間帯と20:00〜23:00にそれぞれテストします。複数ノードが同時に低下するなら、回線混雑を重点的に確認します。

4. 接続ネットワークを変える

   ノードと端末を固定し、ネットワークだけを切り替えます。速度がネットワークによって大きく変わるなら、元の接続回線とルーティング機器を優先して確認します。

5. ローカル設定を元に戻す

   10808などの実際のポートを確認し、ルーティングを簡素化します。システムプロキシとTUNを個別にテストし、Muxは無効にして比較します。

6. 安定した設定を残す

   3回連続で変動が小さい組み合わせを選びます。平均80Mbpsで安定する設定の方が、ピーク140Mbpsでも最低12Mbpsまで落ちる設定より、日常利用には適しています。

Android端末でも同じ方法を使えます。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。まずサブスクリプションのノードと接続ネットワークをそろえ、次にルーティングモード、DNS、ログをそれぞれ確認してください。コアによって対応する設定項目が異なる場合があるため、インポートに成功した後も、プロトコルとトランスポートパラメータが正しく認識されていることを確認します。