この記事の要点

接続はできるものの、Webページの表示が遅い、またはダウンロード速度が安定しない方に向けた内容です。まず測定条件を固定して基準を取り、ノード、接続ネットワーク、転送方式、端末設定の順に比較します。v2rayNではプロキシを明示したリクエストで通信経路を確認し、v2rayNGでは同じアプリ・同じネットワークで繰り返しテストします。一度の遅延値だけでノードを変更せず、再現できる記録を残しましょう。

ページ表示の遅さ・低速・断続的な切断を切り分ける

「通信速度が遅い」には、ページを開いてから表示まで時間がかかる、ページは開くがダウンロードが遅い、最初は正常でも途中で止まる、という少なくとも3つの症状があります。それぞれ、名前解決やハンドシェイク、利用可能な帯域幅、接続の安定性が関係している可能性があります。クライアントに表示される遅延は特定の測定方法だけを反映することが多く、実際のWeb閲覧や継続的なダウンロードの代わりにはなりません。

システム更新、クラウドストレージへのアップロード、ほかのダウンロードをいったん停止します。同じ端末で、普段利用するHTTPSページと、テストに十分なサイズのファイルをダウンロードできるサイトを1つ選びます。ノード、ブラウザー、測定先を同時に変更すると、どの変更が効果をもたらしたのか判断しにくくなります。

3回
各条件で繰り返し、中央値を比較
30秒
1回の継続ダウンロードでの推奨測定時間
1項目
1回のテストで変更する条件は1つだけ

これらの数値はテスト方法の目安であり、本サイトでの実測値や性能を保証するものではありません。ファイルが小さいと測定中にダウンロードが完了し、継続的な通信速度を確認できないことがあります。通信量に制限がある場合は測定時間を短くし、各条件で統一してください。ダウンロードツールのMB/sと通信事業者が表示するMbpsは異なり、理論上は1 MB/s＝8 Mbpsですが、実際にはプロトコルのオーバーヘッドもあります。

  • ページの表示開始が遅い：名前解決、接続確立、最初の1バイトを受信するまでの時間を記録し、初回だけ遅いか確認します。
  • 継続的な転送速度が低い：安定して転送している時間帯のデータ量を確認し、開始直後のピーク値を結果として扱わないようにします。
  • 断続的に通信が切れる：切断時刻、画面がオフだったか、ネットワークが切り替わったか、その時点のカーネルログを記録します。

第1段階：ノードの負荷と出口経路を比較する

ノード名に含まれる地域名だけでは、経路の全容はわかりません。同じ地域のノードでもデータセンター、入口、出口が異なることがあり、名前の異なるノードが同じ入口を共有している場合もあります。サブスクリプションを更新しても設定が新しくなるだけで、サーバーの帯域幅が増えるわけではありません。同じネットワーク・近い時間帯・同じ測定先という条件で、利用可能な2つのノードを比較します。

v2rayNではサーバー一覧からノードを選び、右クリックメニューの速度テスト機能で候補を絞り込めます。メニュー名はバージョンによって異なります。v2rayNGではメイン画面の一覧からノードを選択して接続し直し、同じアプリでテストします。内蔵テストは測定先や同時接続数が実際の利用時と異なる場合があるため、最終的には実際の用途で再確認してください。

比較結果優先して確認する点次に行うこと
特定のノードだけ、繰り返し遅いそのノードの負荷、速度制限、出口経路別のノードを比較用に残し、時間帯を変えて測定する
複数のノードが夜間に一斉に遅くなる共有入口の混雑、または利用中の通信事業者の経路ノードを固定したまま、別の接続ネットワークで比較する
特定のダウンロードサイトだけ遅い接続先の速度制限、出口側の相互接続、コンテンツ配信先の振り分け別の独立した測定先も試し、すぐに転送方式を変更しない
内蔵速度テストは速いのに、ブラウザーでのダウンロードは遅い測定先が異なる、またはブラウザーの通信が同じ出口を通っていないルーティングとプロキシの入口を確認し、同じファイルで比較する

サーバーを管理できる場合は、同じ時間帯のCPU使用率、帯域幅の使用量、接続数も確認します。管理できない場合は「ノード側がボトルネックの可能性」と記録し、クライアントで測った速度だけでサーバーの過剰収容と断定しないでください。異なる時間帯の測定結果は手掛かりにはなりますが、同一条件での比較の代わりにはなりません。

判断の目安：利用可能な比較用ノードを1つ固定する

同じ測定先でノードAは何度試しても遅く、ノードBは安定して正常なら、まずBに戻して使い、Aの測定時刻とログを記録します。この段階でローカルDNSと転送設定を同時に変更する必要はありません。

第2段階：接続ネットワークと異なる事業者間の経路を分けて確認する

ノードと測定先を固定したまま、Androidスマートフォンの接続をWi-Fiからモバイルデータ通信に切り替え、v2rayNGに再接続してテストします。ネットワークを切り替えると既存の接続は切断されるため、以前に開いたページのキャッシュや古いダウンロードタスクを新しいネットワークの測定結果として扱わないでください。PCではスマートフォンのテザリングを比較に使えますが、テザリングの電波状況やデータ通信量の制限にも注意が必要です。

Wi-Fiだけ遅い場合は、まずルーターの近くで試し、5 GHz帯と2.4 GHz帯を比較します。距離が遠い、壁が多いといった環境では、5 GHz帯のほうが必ず安定するとは限りません。同じWi-Fiでプロキシを使わない通信も遅いなら、プロキシのカーネル設定を何度も変えるのではなく、無線干渉、ルーターの負荷、ブロードバンド回線の上り帯域の占有を先に確認してください。

  1. デフォルトゲートウェイをローカル経路の測定先にして、端末からルーターまでの接続が安定しているか確認します。
  2. Windowsでping -n 30を実行し、後ろに実際のゲートウェイアドレスを入力します。同じ方法で、測定が許可されているノードのアドレスも確認します。
  3. 継続的なパケットロスや大きな揺らぎがないか比較しながら、実際のHTTPSリクエストも実行します。測定用パケットの結果だけで判断しないでください。
  4. 同じノードでネットワークを変えると何度試しても正常に戻る場合は、接続ネットワーク、または通信事業者から入口までの経路を重点的に調べます。

夜間に遅くなり、深夜には回復する場合は、混雑の影響が考えられますが、接続先サイトの負荷が変化している可能性もあります。2つの測定先を同時に記録してください。速度テストを1回行っただけでMTUを変更するのは避けましょう。特定のネットワークでハンドシェイクは成功するものの、大きなデータ転送が繰り返し停止するなど、再現可能な症状がある場合に限り、経路MTUやトンネルのカプセル化を詳しく調べてください。

第3段階：プロトコル、転送方式、サーバー設定を確認する

VMessとVLESSはプロキシプロトコルの名称です。TCP、WebSocket、gRPCは異なるレイヤーの転送方式で、TLSは安全な通信を担います。これらをひとまとめにして速度ランキングを作ることはできません。実際の性能はサーバーの実装、ネットワーク経路、接続先サイト、端末の性能に左右され、プロトコル名だけで速度が保証されるわけではありません。

v2rayNGはXrayカーネル、v2flyNGはV2Flyカーネルを使用しており、対応する設定項目や機能が異なる場合があります。v2rayNの動作も、選択したカーネルと設定によって変わります。クライアントを変更する場合、ノードのアドレスを移すだけでは不十分です。移行先のカーネルが、サブスクリプションで配布されるプロトコルと転送方式の組み合わせに対応しているか確認してください。

  • まずノード情報を確認：アドレス、ポート、ユーザーID、TLSの有効・無効がサーバー側の設定と一致しているか確認します。ポート番号が443でも、TLSが有効とは限りません。
  • 次に転送設定を確認：WebSocketのパスとHost、gRPCのサービス名、TLSのサーバー名などは、サーバー側で指定された値を設定します。
  • 最後に比較：サーバー側で別の利用可能な入口が提供されている場合に限り、転送方式を比較します。現在のノードのWebSocketを、設定を確認せずにgRPCへ変更しないでください。
  • 元の設定を残す：変更前にエクスポートし、接続できなくなったらすぐに元へ戻します。速度向上を目的に証明書の検証を無効にしないでください。

多重化も、どの環境でも効果がある高速化スイッチではありません。短い接続が多い場合、接続を繰り返し確立するコストを抑えられることがあります。一方、パケットロスがある環境や大容量データの長時間転送では、複数のリクエストが1つの接続を共有することで互いに影響する場合があります。現在のカーネルとプロトコルが対応している場合は、有効・無効の2条件で比較し、同時に並列数や転送方式を変更しないでください。

判断の目安：設定の不一致を直してから、安定性の問題を調整する

ハンドシェイクの失敗、接続のリセット、経路エラーが頻発する場合は、まずサーバー側の設定を確認します。接続が安定し、比較条件もそろっている場合に限り、転送方式ごとの速度差を評価してください。

第4段階：ローカルプロキシ、DNS、ルーティング設定を確認する

Windowsのシステムプロキシ設定を、すべてのプログラムが使うとは限りません。v2rayNではトレイメニューの「システムプロキシ」から自動設定できますが、ターミナルは直接接続する場合があります。ブラウザー拡張機能がシステム設定を上書きすることもあります。まず「設定」→「パラメータ設定」でローカルリスナーの設定を確認してください。バージョンによっては「基本設定」やインバウンド関連の画面にあります。実際の表示に従ってください。

以下ではWindows PowerShellでHTTPプロキシの入口を明示し、「アプリがシステムプロキシを使っていない」という要因を切り分けます。まずローカルリスナーのポートが10809であることを確認してから、コマンドをコピーしてください。実際のポートが異なる場合は、先にコマンドを変更します。10809は例であり、すべてのv2rayN環境での既定値ではありません。

curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} speed=%{speed_download}B/s\n" https://v2rayultra.com/

このコマンドはプロキシの入口を確認し、リクエストの各段階を観察するためのもので、継続的な転送速度の測定には使えません。time_connectは主にローカルプロキシへの接続時間を示します。time_starttransferには、その後のトンネル接続、ハンドシェイク、接続先の応答待ちも含まれるため、「ノードの遅延」とは言えません。大きなファイルをテストする場合は、自分にアクセス権のある固定ダウンロードURLに置き換えてください。30秒の上限に達するとリクエストが途中で終了することがあります。これをノードの切断と誤解しないでください。

  • ルーティングを確認：システムプロキシは通信をカーネルに渡すだけで、その後ルールにより直接接続へ振り分けられる場合があります。アクセスログでテスト先の実際のアウトバウンドを確認してください。「グローバル接続」が「すべての通信をプロキシ経由にする」という意味だとは限りません。
  • DNSを確認：初回アクセスが遅く、再アクセスが速い場合は、名前解決のタイムアウトがないか確認します。すべてのDNSアドレスを一度に変更しないでください。Androidの「プライベートDNS」とクライアントのDNS設定は分けて確認し、1つずつ変更して再テストします。
  • Androidのアプリ別設定を確認：v2rayNGの「設定」→「アプリごとのプロキシ」で、テスト対象のアプリがプロキシ対象になっているか確認します。表示名はバージョンによって異なる場合があります。また、選択中のリストがプロキシ対象リストか除外リストかも確認してください。
  • バックグラウンド制限を確認：Androidの「設定」→「アプリ」→「v2rayNG」→「バッテリー」で、バックグラウンドの制限を確認します。画面ロック後にだけ通信が切れる場合は、一時的にバックグラウンド実行を許可して検証し、その後バッテリー消費との兼ね合いを判断してください。
  • 端末の負荷を確認：PCではタスクマネージャー、Androidでは発熱や性能低下に注意します。TUNモード、ほかのVPNサービス、プロキシツールを同時に何度も切り替えると、ルーティングの変化で原因がわかりにくくなるため避けてください。

ログのタイムアウトやリセットを通信速度の低下と結び付けて考える

詳細ログは短時間の調査にだけ使用します。リクエストが発生した時刻を記録し、同じ時間帯・同じ接続先のログを確認してください。1件のエラーは、バックグラウンドアプリのリクエスト失敗にすぎないこともあります。ログレベルを長期間細かく設定すると、保存容量や処理負荷が増えるため、調査後は通常のレベルに戻します。ログを共有する前に、サブスクリプションURL、ユーザーID、サーバー情報を伏せてください。

エラー：context deadline exceeded

原因：処理が期限内に完了しなかったことを示します。名前解決、接続、その他のリクエスト段階で発生する可能性があり、この表示だけでサーバーの過負荷とは判断できません。

対処：前後のログから接続先と処理段階を確認します。ノードを固定して接続ネットワークを変更し、次にネットワークを固定してノードを変更して、どの条件でタイムアウトが発生するか比較してください。

エラー：connection refused

原因：接続先から明示的に拒否されています。アドレスがローカルループバックの場合は、リスナーポートの誤りやカーネルの未起動がよくある原因です。

対処：拒否されているのがローカルの入口かリモートのサーバーかを切り分けます。v2rayNのリスナーポートとカーネルの実行状態を確認し、リモート側で拒否される場合はノードのアドレスとサーバーの待受設定を確認してください。

エラー：connection reset by peer

原因：接続相手、または経路上の機器によって接続がリセットされています。サーバー、ネットワーク機器、転送設定のいずれが関係している可能性もあります。

対処：ハンドシェイク中とデータ転送中のどちらでリセットされたかを記録し、TLSと転送設定を確認してから、別のネットワークで再テストします。このメッセージだけでプロトコルを変更しないでください。

エラーの正確な文言は、OSやカーネルのバージョンによって変わることがあります。ログに該当するリクエストがまったく見つからない場合は、リモートノードの設定を変更するのではなく、アプリがプロキシを経由しているかを先に確認してください。想定したアウトバウンドを通っているのに転送が繰り返し止まる場合は、ログと前段のノード・ネットワーク比較記録を合わせて分析します。

よくある質問と調査を終える目安

遅延が最も小さいノードなのに、ダウンロードが遅いのはなぜ？

短いリクエストの遅延と、利用できる帯域幅は別の指標です。同じファイル・同じネットワークで各3回測定し、継続的なダウンロード速度を比較します。速度測定とダウンロードの通信が、同じノード・同じアウトバウンドを通っているかも確認してください。

サブスクリプションを更新しても遅い場合、毎日更新すべき？

サブスクリプションの更新で同期されるのは、提供元が公開した設定だけです。まず現在のノードが有効かを確認し、ノードとネットワークをそれぞれ比較して原因を絞り込みます。夜間だけ遅い場合、何度更新してもその経路の混雑は通常改善しません。

TUNを有効にすれば、すべてのアプリが速くなる？

TUNは主に通信を取り込む方式を変更する機能で、サーバーの帯域幅を増やすものではありません。通常のプロキシでテスト対象のアプリをカバーできるなら、まず現在のモードを維持してください。アプリがプロキシを経由していない場合に限り、クライアントの説明に従ってTUNとルーティング設定を確認します。

v2rayNGは画面点灯中は正常なのに、画面ロック後に遅くなる場合は？

ネットワークを固定して、画面点灯中とロック中のダウンロード速度やリクエストログを比較します。バックグラウンドでだけ問題が起きる場合は、システムのバッテリー制限、バックグラウンドデータの権限、省電力モードを確認してください。ノードの転送設定を先に変更する必要はありません。

再現可能な安定した差が見つかったら、調査を終えてかまいません。「時刻、接続ネットワーク、ノード、測定先、プロキシモード、3回分の結果、ログの抜粋」を記録すれば十分です。見た目の遅延値をさらに下げることだけを追い続ける必要はありません。追加のサポートを依頼する場合も、「どのノードも遅い」という一言より、この記録のほうが原因を特定しやすくなります。

  1. プロキシを使わない通信も遅い：接続ネットワークと端末の負荷を先に確認する。
  2. 特定のノードだけ遅い：利用可能なノードを使い続け、比較記録をサービス提供元に伝える。
  3. ネットワークを変えると回復する：無線接続、通信事業者の経路、共有入口を重点的に確認する。
  4. 明示したプロキシ経由では正常で、アプリでは異常：システムプロキシ、アプリ別プロキシ、ルーティングルールを確認する。
  5. 特定の転送設定だけ失敗する：性能を検討する前に、サーバー設定とカーネルの互換性を確認する。