v2rayNやv2rayNGで接続はできるものの、ページの初回表示が遅い、ダウンロード速度が出ない、混雑する時間帯に途切れる場合に役立つ手順です。まず測定条件をそろえ、ノード・ネットワーク・ローカルのプロキシ設定を順に比較して原因を絞ります。一度に変更する設定は一つにし、所要時間やエラー、改善状況を記録しましょう。DNSの応答待ち、ノードの混雑、アプリがプロキシを経由していない状態を混同せずに確認できます。
初回表示の遅さ・低速・頻繁な切断を見分ける
クライアントに表示される遅延は、実際に使える帯域幅を示すものではありません。TCP接続テストでわかるのは、通常、ポートに接続できるかと接続にかかる時間です。「実際の接続遅延」には、テスト先のURLやハンドシェイク、応答時間も影響します。遅延の小さいノードでも、共有帯域が不足していればダウンロードは遅くなります。反対に、遠距離の回線で遅延が大きくても、大容量ファイルを安定してダウンロードできることがあります。
| 症状 | 優先して確認する項目 | 比較方法 |
|---|---|---|
| 初回の表示に時間がかかり、次からは正常 | DNS、ハンドシェイク、接続の再利用 | 同じページを繰り返し読み込み、初回と2回目以降の所要時間を比較する |
| ダウンロードがずっと遅い | ノードの出口、回線容量、接続先の速度制限 | 同じ配布元のファイルを使い、2つのノードを個別にテストする |
| しばらくすると停止する | 無線の干渉、パケットロス、接続タイムアウト | ノードはそのままに、接続するネットワークを変える |
| 特定のアプリだけ遅い | アプリのプロキシ設定、ルーティング、アプリ側のサービス | 明示的にプロキシを指定したリクエストとアプリの動作を比較する |
「どのサイトも遅い」と判断する前に、実際に比較してみましょう。少なくとも異なる2つのサイトを試し、ページ表示、小さなファイル、継続的なダウンロードを分けて確認します。特定の接続先だけ遅い場合は、ノードを変える前に、接続先の稼働状況や地域別の入口、ルーティングルールの適用状況を確認してください。
再現可能な速度測定の基準を作る
測定前に、システム更新やクラウドストレージの同期、ほかのダウンロードを一時停止します。クライアントとコアのバージョン、ノード名、接続ネットワーク、ルーティングモード、測定時刻を記録してください。v2rayNのバージョンは「ヘルプ」→「バージョン情報」で確認できます。コアのバージョンは起動ログを確認してください。画面の種類によってメニューの位置が異なる場合があるため、表示されている項目名も記録しておきましょう。
ここにある数値はテスト用の設定であり、速度を保証するものではありません。まずv2rayNの「設定」→「パラメータ設定」でローカルの待ち受けポートを確認し、現在の接続口がSOCKSに対応していることを確かめてください。以下ではWindowsのcurl.exeを使用します。ポートが10808でない場合は、実際のポート番号に変更してください。
curl.exe --proxy socks5h://127.0.0.1:10808 "https://v2ray-group.com/zh-CN/index.html" --output NUL --silent --show-error --connect-timeout 10 --max-time 20 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n"socks5hを使うと、接続先のドメイン名の解決をSOCKSプロキシ側に任せられます。ただし、ノードサーバー自体のドメイン名までローカルでの名前解決が不要になるわけではありません。このコマンドは小さなリクエストが安定して完了するかを確認するもので、帯域幅の測定には適していません。SOCKS経由のリクエストでは、time_connectが主に示すのはローカルのプロキシ接続口への接続時間です。クライアントからノードまでのネットワーク遅延とは異なります。最初の1バイトを受信するまでの時間には、プロキシとのネゴシエーション、接続先への接続、サイト側の処理も含まれます。
第1層：ノードの負荷と出口側の制限
ノードを確認する際は、「同じネットワークから接続したとき、ノードによって安定した速度差があるか」を調べます。出口やサービス回線の異なるノードを2つ選び、接続先・時間帯・測定方法をそろえて個別にテストしてください。ノード名が異なるだけでは、実際の回線も異なるとは限りません。同じ事業者の複数の接続口で、出口帯域を共有していることもあります。
接続先を固定する
テストするURL、ファイル、ルーティングモードをそろえます。まず対象のリクエストがプロキシ経由になっていることを確認してください。一方のノードではプロキシ経由、もう一方では直接接続のルールが適用されていた、という事態を防げます。
1つずつ測定する
v2rayNのメイン画面でノードを選び、右クリックメニューから「アクティブサーバーに設定」を選択します。コアの再読み込みが完了してからリクエストを送ってください。複数のノードを同時に測定するのは避けましょう。
時間帯を記録する
ノードごとに3回測定し、中央値と失敗回数を記録します。日中と夜間にそれぞれ測定し、特定の時間帯だけ速度が大きく低下するか確認してください。
利用枠を確認する
サービス提供元のアカウントページで、残りの通信量、有効期限、速度制限のルールを確認してください。サブスクリプションを更新しても設定が更新されるだけで、ノードの容量が増えたり、アカウントの速度制限が解除されたりするわけではありません。
複数の接続先でノードAだけ遅く、ノードBは同じ時間帯に正常なら、ローカルのDNSをすぐ変更するのではなく、まずノードAまたは対応する回線を疑います。AとBの両方が特定のダウンロードサイトだけ遅い場合は、接続先の速度制限、ノードの出口IPアドレスに対する制限、そのサイトまでの経路も考慮してください。
第2層：接続ネットワークと通信経路
ノードと接続先を固定し、まず有線と無線、次に自宅の固定回線とスマートフォンのテザリングを比較します。テザリングでは通信事業者、IPアドレスの種類、ルーティング経路が同時に変わります。そのため、結果からわかるのは「接続経路に関係がある」ことまでで、特定の中継地点でパケットロスが起きているとは断定できません。Androidでテストする場合は、バックグラウンド更新を停止し、通信量に余裕があることも確認してください。
- 無線の確認：ルーターの近くで試した後、有線接続と比較します。有線では安定し、無線で変動する場合は、電波状況やチャンネルの混雑、ほかの機器との競合を確認してください。
- 時間帯の確認：同じノードで夜間に遅くなり、混雑していない時間帯には回復する場合、回線の混雑が考えられます。ただし、ほかのノードやネットワークでも比較して確認しましょう。
- 経路の確認：ローカルゲートウェイに30回連続でプローブを送り、LANの安定性を確認できます。ゲートウェイに問題がなくても、インターネット上の経路が正常とは限りません。中継ルーターがプローブに応答しないことも、通常の通信でパケットロスが起きている証拠にはなりません。
- アドレスファミリーの確認：ノードのドメイン名が実際にどのIPv4・IPv6アドレスへ解決されるか確認します。特定のアドレスファミリーに問題がある証拠がある場合に限り、一つの条件だけを変えて比較してください。システム全体で一方のアドレスファミリーを無効にするのは避けましょう。
VMessやVLESSはプロキシプロトコルの名称であり、回線品質のランクではありません。通信方式を変更する場合も、サーバー側の設定と一致させる必要があります。ポート、TLS、SNI、通信経路をむやみに変更すると、接続できていたノードのハンドシェイクに失敗するだけで、物理回線の容量不足は解消できません。
第3層：ローカルの接続口・ルーティング・DNS
SOCKSを明示したリクエストは正常なのにブラウザーが遅い場合は、まずアプリが想定した接続口を使っているか確認します。v2rayN画面下部の「システムプロキシ」→「システムプロキシを自動設定」は、システムプロキシ設定を使うアプリに影響します。ルーティングモードは、コアに取り込まれた通信の経路を決めます。この2つは別々の設定です。システムプロキシを有効にしても、すべてのソフトが利用するとは限りません。
| 確認箇所 | 操作 | 確認する結果 |
|---|---|---|
| v2rayNのシステムプロキシ | 画面下部の「システムプロキシ」→「システムプロキシを自動設定」 | ブラウザーとシステムの設定が現在のクライアントの接続口を参照している |
| ローカルの待ち受けポート | 「設定」→「パラメータ設定」でポートを確認し、アプリのプロキシ設定と比較する | アプリが古いポートや別のプロキシプロセスに接続していない |
| ルーティングモード | 現在のモードを記録し、一時的に「グローバル」にして比較した後、元のモードに戻す | 元のルールによる直接接続が、対象リクエストの結果に影響していないか |
| v2rayNGでのアプリ対象範囲 | サイドメニューの「設定」→「アプリごとのプロキシ」で、スイッチ、モード、アプリ一覧を確認する | テスト対象のアプリが、想定したプロキシの対象に含まれている |
v2rayNのTUNモードとシステムプロキシは同時に有効になっている場合がありますが、調査中にほかのVPNやプロキシソフトを重ねて使わないでください。まず現在の設定を保存し、通信を処理する方法を一つずつ検証します。リモートワーク用のトンネルを利用している場合は、先に会社のネットワーク要件を確認してください。テストのために既存のネットワーク設定を削除してはいけません。
DNSも層ごとに確認しましょう。ノードのアドレス解決はサーバーに接続できるかどうかに影響し、接続先ドメインの解決はリクエストの行き先に影響します。ルーティングのdomainStrategyは、ルールの判定時に解決結果をどう使うかを決めます。それぞれ別の設定です。ブラウザーの初回表示だけが遅い場合は、「セキュアDNS」の設定を比較し、変更前の値を記録してください。システム、クライアント、ブラウザーのDNSを同時に変更するのは避けましょう。
- まずログで、対象への接続が想定どおりのアウトバウンドを通っているか確認してから、ルーティングの変更が必要か判断します。カスタムルールの
outboundTagは、定義済みのアウトバウンドタグに対応している必要があります。 - 通信中にPCのCPU使用率がほぼ100%の状態で続く場合は、高負荷のアプリを停止して再測定します。コアプロセスの使用率も記録し、端末側のボトルネックをノードの問題と取り違えないようにしてください。
- Android端末で画面ロック後に切断される場合は、「設定」→「アプリ」→「v2rayNG」で、バッテリー設定とバックグラウンド実行の権限を確認します。バックグラウンド制限は接続の継続性に影響しますが、画面表示中のダウンロード速度不足とは別の問題です。
ログで応答の遅れと接続失敗を見分ける
クライアントのログを開いて同じテストを一度実行し、時刻を手掛かりに該当する記録を探します。短時間の調査ではログレベルをinfoに設定してください。通常のログで原因を特定できない場合に限り、一時的にdebugを使い、調査後は元に戻します。詳細ログには接続先アドレスや接続情報が含まれる場合があります。共有する前に、サブスクリプションURL、UUID、アカウント情報を伏せてください。
context deadline exceeded
原因：処理がタイムアウトしています。このログ1行だけでは、ノード、DNS、接続先サイトのどれに問題があるか判断できません。
対処：前後のログから失敗した段階を確認し、同じノードで接続先を変える方法と、同じ接続先でネットワークを変える方法を比較します。
connection refused
原因：接続が明示的に拒否されています。ローカルの接続口が待ち受けていない場合と、接続先のポートでサービスが動作していない場合があります。
対処：エラーに表示されたアドレスを確認します。127.0.0.1:10808の場合は、実際のローカルポートとコアの状態を確認してください。ノードのアドレスの場合は、サーバー側のポートを確認します。
address already in use
原因：この表現のエラーを使うシステムでは、通常、待ち受けアドレスまたはポートがほかのプロセスに使用されています。
対処：重複して起動しているクライアントを終了するか、パラメータ設定で未使用のポートに変更し、アプリのプロキシ設定も更新してください。
ログのEOFや接続終了を、サーバーの速度制限とすぐに結びつけてはいけません。正常終了、接続先による早期切断、中継ネットワークの切断などでも発生します。同じ接続先・同じ処理段階で繰り返し再現し、失敗したリクエストの時刻とも一致する場合に限り、そのログを詳しく調べましょう。
よくある質問と再テストのまとめ
遅延が数十ミリ秒なのに、ダウンロードが遅いのはなぜ？
遅延が示すのは往復時間やリクエストの応答時間であり、帯域幅ではありません。ダウンロードする権限のある大容量ファイルを一つ選び、2つのノードをそれぞれ3回テストしてください。一方のノードだけが継続的に低速なら、出口、アカウントの速度制限、ピーク時の負荷を確認します。
グローバルモードにすると速くなります。このまま使ってもよいですか？
まずはルーティングの比較結果として捉えましょう。元のモードで対象が直接接続されていないか確認し、該当するルールを修正してから元のモードに戻します。常用する前に、LANや業務システム、ローカルサービスへのアクセスに支障がないかも確認してください。
サブスクリプションの更新やコアの変更で速度は改善しますか？
サブスクリプションの更新は、アドレスや設定の変更に対応するためのものです。現在の回線容量を増やすことはできません。特定のコアバージョンとの互換性に問題があると確認できた場合に限り、元の設定を保存してバージョンを比較してください。コアを変更する際は、ノードのプロトコルと通信パラメータがサポートされているか確認します。
Androidでは正常なのにPCだけ遅い場合、次に何を確認すればよいですか？
2台の端末を同じWi-Fi、同じノード、同じ接続先で使います。まずPCからSOCKSを明示したリクエストを送り、システムプロキシやブラウザーによる違いを切り分けます。その後、PCのバックグラウンド通信、コアのログ、CPU使用率を確認してください。
最終的な記録には、「ノードを変えたら直った」だけでなく、再現時の条件を残しましょう。たとえば「自宅の固定回線で同じ接続先をテスト。夜間、ノードAは3回ともタイムアウトし、ノードBは正常。スマートフォンのテザリングではAも回復」のように記録します。ノードAと特定の接続経路の組み合わせに原因を絞り込みやすくなり、サービス提供元にも調査を依頼しやすくなります。
- 記録する：測定時刻、クライアントとコアのバージョン、接続ネットワーク、ノード名、接続先、所要時間。
- 元に戻す：一時的なグローバルモード、詳細ログ、テスト用のDNS設定とインターフェース設定。
- 再テストする：普段の設定に戻してから、遅くなっていたアプリを使い、テスト用コマンドだけでなく実際の利用でも改善したか確認します。