V2Rayが遅いときの原因と対処法｜ノード・回線・設定を順に確認

1. 初回表示の遅さ・継続的な低速・接続失敗を切り分ける

レイテンシが低くても、ダウンロードが速いとは限りません。ノード一覧の遅延テストで分かるのは、特定の方法で測った応答時間です。実際の通信速度は、サーバー負荷、事業者間の経路、接続先による速度制限、ローカル回線にも左右されます。まず遅くなる段階を特定してから、設定を見直しましょう。

v2rayNはクライアントを管理するインターフェースで、実際に接続を処理するのは選択したコアです。Project V、V2Fly、Xrayは関連プロジェクトですが、名称を性能の優劣と混同しないでください。VMessやVLESSなどのプロトコルも速度ランクを示すものではありません。速度の差は、プロトコル名よりノードの場所、トランスポートの組み合わせ、サーバーのリソースで説明できることが多くあります。

2. 再現可能なローカルテストの基準を作る

ノード、接続先、接続ネットワーク、プロキシの入口を固定します。ここではWindows版v2rayNで、127.0.0.1:10808をリッスンする混合プロキシポートを使う例を紹介します。10808は例示値です。実行前に設定画面とコアの起動ログで実際の値を確認してください。古い記事にある10809をそのまま使わないようにしましょう。

1. 環境を記録する

   「ヘルプ」→「バージョン情報」を開き、クライアントの完全なバージョンを記録します。次に、起動ログでコアの名称とバージョンを確認します。現在のノード、ルーティングモード、TUNの状態も控えておき、以降はアップデートとルール変更を同時に行わないでください。

2. プロキシの入口を確認する

   「設定」→「パラメーター設定」を開き、ローカルのリッスンポートを確認します。メニューの構成はバージョンによって異なるため、起動ログも参照してください。まずTUNを無効にし、明示的なHTTPプロキシで基準値を測定します。2種類の入口を混在させないようにしましょう。

3. テスト条件を固定する

   サブスクリプションの一括速度測定、クラウドストレージの同期、ほかのダウンロードを停止します。安定してアクセスできるHTTPSアドレスを選び、同じノードを使って以下のコマンドを3回続けて実行します。最速値ではなく中央値を採用してください。

4. 結果を記録する

   測定時刻、接続先、接続時間、最初の応答までの時間、エラーの原文を記録します。設定を一つ変更したら、もう一度3回測定してください。安定した改善が見られなければ元に戻し、基準から設定がずれていかないようにします。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

ここでのexample.comは、時間を計測するコマンドの例にすぎず、帯域を測る用途には適しません。ローカルのHTTPプロキシ経由でHTTPSに接続する場合、time_connectが主に示すのはローカルプロキシへの接続時間であり、遠隔ノードへの遅延ではありません。TLS接続や最初の応答までの時間には、プロキシ経由の経路や接続先の処理時間も含まれます。通信速度を測るには、アクセス権のある一定サイズのファイルを使い、エラーページが返されていないことも確認してください。

3. ノード負荷と回線混雑を比較テストで切り分ける

1回の速度測定だけでは、ノードの混雑と経路の混雑を区別できません。「同じネットワークでノードを変更」と「同じノードでネットワークを変更」の比較が特に有効です。接続先は変えず、できるだけ近い時間帯に測定して、接続先自体の負荷変動による影響を避けましょう。

たとえば、測定記録の例として、同じファイルをノードAで測ると昼は8 MB/s、夜は0.8 MB/sになり、同じ時間帯にノードBでは6 MB/sを維持していたとします。この結果から問題をノードAのリソースまたは経路に絞り込めますが、サーバーのCPU使用率が上限に達したとは断定できません。サーバー負荷の確認には、サーバー側のCPU、帯域、接続数、速度制限の情報が必要です。数値は判断方法を示す例であり、本サイトでの実測値ではありません。

• ノードの地理的な距離が近くても、通信事業者の実際の経路が短いとは限りません。事業者間の接続や迂回経路によって、距離の近さが相殺されることがあります。
• 通常のpingで発生するパケットロスは、ICMPの速度制限が原因の場合があります。アプリの接続状況、継続的な転送、再試行の有無もあわせて判断してください。
• 同じ入口や出口を共有する2つのノードは、完全に独立した比較対象ではありません。必要に応じて異なる回線グループを選んで比較してください。
• 速度を補うために、最初からマルチスレッドダウンロードを使わないでください。接続数と帯域の競合が増え、単一接続でのパケットロスも見えにくくなります。

4. DNSとルーティング：リクエストの経路を確認する

DNSは主に、名前解決の待ち時間、接続先IPの選択、IPベースのルール判定に影響します。ノードの帯域を増やす機能ではありません。ノードのドメインを誰が解決するのか、接続先のドメインを誰が解決するのか、ルール判定のために名前解決が実行されているのかを切り分けましょう。ブラウザーのセキュアDNS設定は、システムやコアのDNS経路と異なる場合もあります。

• ノードのアドレスを解決できない：プロキシが接続する前にノードのドメイン名を解決する必要があります。まだ接続できていないプロキシだけに、この処理を依存させることはできません。
• 接続先の名前解決が遅い：遅いのが初回アクセスだけかを確認します。接続先を次々に変えるのではなく、同じ接続先への初回と再アクセスを比較してください。
• 名前解決の結果と出口の位置が合わない：CDNの中には、名前解決元に応じてIPアドレスを割り当てるものがあります。遠隔出口とIPアドレスの位置が合わないと、遠回りの経路になる場合があります。
• ルーティングルールの判定が想定と異なる：ログの接続先とアウトバウンドタグを確認し、意図せず直接接続していないか、ローカルサービスが遠隔経由になっていないかを調べます。

以下はルールの順序を説明するための、V2Ray/Xray形式のroutingの抜粋です。完全な設定ではありません。まずプライベートアドレスをdirectに送り、その後、残りのTCP・UDPリクエストをproxyに送ります。使用前に同名のアウトバウンドが存在し、geoipデータが用意されていることを確認してください。v2rayNでは先にバックアップを取り、画面から生成されたルールと重複して追加されないようにします。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIsは、ルーティング段階でドメイン名を積極的にIPアドレスへ解決して照合しないことを示します。そのため、ドメイン名のリクエストはIP条件に一致しない場合がありますが、最終的な接続には名前解決が必要になることがあります。「DNSを無効にする」という意味ではありません。IPIfNonMatchやIPOnDemandでは名前解決を行うタイミングが異なるため、実際のコアとルールに合わせて理解してください。各フィールドの詳細はJSON設定ガイドを参照してください。

5. スニッフィングとMTU：症状に合う場合だけ調整する

スニッフィングは、通信からドメイン名やプロトコルを判別し、ルーティングを補助する機能です。汎用的な高速化スイッチではありません。有効にするとドメインルールの判定結果が変わることがあり、無効にするとドメインベースの振り分けが機能しなくなる場合があります。同じノードと接続先で比較し、アウトバウンドの変化も確認してください。たまたま一度ページが速く表示されたかどうかだけで判断しないようにしましょう。

MTUは、インターフェースが一度に送信できる最大データ単位です。経路MTUの検出が妨げられると、ハンドシェイクは成功しても大きなデータの転送が止まることがあります。TUNモードでのみ再現する場合は、実際にTUNのMTU項目がある設定画面または設定ファイルで、1500から1400に一時変更し、続けて1380でも比較できます。これらは問題の切り分けに使う候補値であり、最適値を保証するものではありません。テストのためにすべての物理ネットワークアダプターを変更しないでください。

6. 実際のログで原因を切り分け、エラーをすべて低速のせいにしない

まずエラーが発生した時刻を記録し、該当する接続の接続先、アウトバウンド、前後のログを確認します。ログの接頭辞や周辺情報はコアによって異なります。以下はよくあるエラーの一部です。これらは調査範囲の手がかりであり、発生箇所を確認せずに原因を断定することはできません。一時的にログレベルを上げる場合は、一度再現したら通常のレベルに戻し、ログの書き込みが継続して調査に影響しないようにしてください。

7. よくある質問とトラブルシューティングの完了条件

同じ接続先で3回続けて測定し、許容できる速度に戻り、通常の利用中に通信が切れなくなったら、「最適化設定」を重ねるのはやめましょう。異常が続く場合は、クライアントとコアのバージョン、時間帯、ノードのグループ、接続ネットワーク、最初の応答までの時間、エラー内容をまとめます。ログを共有する前に、サブスクリプションURL、認証情報、個人のアクセス履歴を削除してください。接続情報を漏らさず、問題を再現できるだけの情報を残しましょう。

• ノード側に原因を絞り込めた：同じネットワークで特定のノードだけ異常なら、サーバーリソースと経路を確認します。
• 回線側に原因を絞り込めた：同じノードで接続ネットワークを変えると回復する場合は、時間帯と通信事業者の比較データを保存します。
• ローカル側に原因を絞り込めた：明示的なプロキシは正常で、特定のアプリまたはTUNだけ異常なら、該当する入口を調整します。
• 原因を特定できていない：基準の設定に戻し、別の接続先と2つ目の接続ネットワークを追加して比較します。DNS、MTU、ルーティングを一度に変更しないでください。