v2rayN、v2rayNG、v2flyNGで接続はできるものの、ウェブページの表示や動画の読み込み、ダウンロード速度が遅い場合に適しています。まずテスト環境を固定し、ローカルのプロキシ経路、ノード状態、ネットワーク経路の順に確認して原因を切り分けます。
再現可能な速度の基準を作る
「接続できるのに遅い」だけでは、障害の状況を正確に表せません。ページの初回表示、継続的なダウンロード、特定サイト、夜間だけ遅いケースでは原因が異なります。設定を変える前に、テスト時刻、接続方法、クライアントのバージョン、使用中のノード、プロキシモードを記録しましょう。この記事のデスクトップ版メニューは v2rayN 7.11.3を基準にしています。後続バージョンでは表示が多少異なる場合がありますが、確認の考え方は同じです。
基準テストでは、端末とネットワークを固定します。有線と無線を切り替えたり、システム更新、クラウド同期、大容量ファイルのアップロードを同時に実行したりしないでください。ブラウザーはテストページだけを開き、ダウンロードは1回30秒、合計3回行い、各回の間隔を60秒空けます。これにより、一時的なキャッシュ、接続のウォームアップ、バックグラウンド通信による誤判定を避けられます。
完全なプロキシリクエストは、アプリ、ローカルの待受ポート、ルーティングルール、プロキシノード、接続先サイトを経由します。どこかでポート競合、ルールの誤判定、パケットロス、輻輳が起きると、「速度が遅い」という症状になります。最初の確認では複数の設定を同時に変えず、記録だけを行いましょう。ノード、プロトコル、DNSを一度に変更すると、速度が戻っても本当の原因を特定できません。
現在の環境を記録する
クライアントのバージョン、コアのバージョン、ネットワーク種別、ノード名、テスト時刻を記録します。v2rayNでは「ヘルプ」→「バージョン情報」でバージョンを確認し、実行ログの冒頭で実際に読み込まれたコアを確認できます。
直接接続の基準を測る
v2rayNで「システムプロキシ」→「システムプロキシを解除」を選び、TUNモードを完全に終了してから、同じダウンロード先を3回連続でテストします。直接接続の結果から、ローカルネットワーク自体が安定しているかを判断できます。
プロキシ接続の結果を測る
元のノードとプロキシモードに戻し、同じ接続先でテストを繰り返します。ブラウザー、ダウンロード先、ネットワークを変えず、2つの結果の違いを「プロキシを経由したかどうか」だけにします。
速度の比率を計算する
プロキシ接続時の速度の中央値を、直接接続時の速度の中央値で割ります。1回だけのピーク値より参考になります。3回の結果の変動が2倍を超える場合は、まずネットワークの揺らぎを確認し、ノードの上限を議論するのは後にしましょう。
第1段階：ローカルプロキシとルール設定を確認する
すべてのノードが遅い場合は、まずローカル層を確認します。システムプロキシが実際には有効でない、ブラウザーが古いポートを使っている、TUNと別のネットワークフィルターツールが重複して通信を処理している、ルーティングルールがテスト先を誤って直接接続またはブロック側へ振り分けている、といった問題がよくあります。この場合、サブスクリプションを何度も更新しても解決しません。ノード設定自体に問題がない可能性があるためです。
v2rayNの一般的なローカル待受ポートは10808ですが、バージョン、設定の移行、手動変更によって異なる場合があります。「設定」→「パラメーター設定」に表示される実際のポートを基準にしてください。ブラウザー拡張機能や他のアプリでSOCKSアドレスを手入力している場合は、アドレスが127.0.0.1で、ポートがクライアントと一致しているか確認します。古い解説に10808や10809と書かれていても、現在の値をそのまま上書きしないでください。
- システムプロキシモード：通常のブラウザーでは、まず「システムプロキシを自動設定」を選んで確認します。「システムプロキシを変更しない」を選ぶと、手動でプロキシを指定したアプリだけがノードを経由します。
- TUNモード：システムプロキシを参照しないアプリも処理できますが、仮想ネットワークアダプターが正常に作成されているか確認が必要です。テスト中は、通信を重複して処理するネットワークツールを同時に使わないでください。
- ルーティングモード：まず短時間だけグローバルプロキシに切り替えて比較します。グローバルでは正常で分流モードだけ遅い場合は、ノードを替え続けるのではなく、ドメインとIPのルールを確認します。
- DNS設定：サイトを開く前に長く待たされる一方、接続後のダウンロードは正常な場合は、ドメイン解決、リモートDNS、分流DNSの対応関係を重点的に確認します。
ルーティングを詳しく調べるときは、v2rayNの「設定」→「ルーティング設定」を開き、現在のルールセットをコピーしてから編集します。普段の設定を直接壊さないためです。まず必要最小限のルールだけでテスト用の設定を一時的に作り、対象ドメインが確実にプロキシの出力へ進むようにします。テスト後は元のルールに戻して接続を再確立し、切り替え前の経路を使い続ける古い接続を残さないようにします。
コアの種類もノードのパラメーターと一致している必要があります。「設定」→「パラメーター設定」→「Coreタイプ」で現在の選択を確認できます。VLESSやVMessのノードが正常に動作するかは、プロトコル名だけでは決まりません。アドレス、ポート、ユーザー識別子、転送方式、TLS、サーバー名も確認してください。パラメーターが不完全だと、完全に切断されるのではなく接続を何度も再試行し、初回表示の遅さやスループットの不安定さとして現れることがあります。
ローカル層の判定結果
| 比較した症状 | 可能性の高い原因 | 次に行うこと |
|---|---|---|
| グローバルプロキシは正常だが、分流モードが遅い | ルールのマッチングまたはDNS分流 | 対象ドメインに適用されたルーティングの出力先を確認する |
| ブラウザーは正常だが、他のアプリが遅い | アプリがシステムプロキシを参照していない | アプリのプロキシ設定を確認するか、TUNをテストする |
| すべてのノードで接続確立時に停止する | ローカルDNS、ポート、コア設定 | ログを確認し、待受ポートを照合する |
| プロキシを無効にしても遅い | ローカルネットワークまたは接続先サイト | まずルーター、無線信号、上流ネットワークを確認する |
第2段階：ノードを比較して負荷の問題を見分ける
ローカルの経路が正常だと確認できたら、個別のノードが過負荷になっていないか判断します。ノード負荷には個体差があり、同じサブスクリプション内でも特定のノードだけが継続的に遅く、同じ条件では他のノードが正常ということがあります。クライアント一覧の遅延順だけで判断してはいけません。遅延テストは送信データが少なく、複数人が同時利用した際の実効帯域幅を直接反映しないためです。
少なくとも3つの異なる入口アドレス、または異なる地域のノードを選び、決めた順番でテストします。各ノードへの接続後に10秒待ってDNSキャッシュと接続状態を安定させ、その後30秒の継続ダウンロードを3回行います。瞬間的な最高値ではなく中央値を記録してください。複数の時間帯で1つのノードだけが明らかに遅いなら、そのノードの負荷またはサーバー出口がより疑わしくなります。
- ノードA、B、Cは同じクライアント、同じネットワーク、同じテスト先で使用します。
- ノードを切り替えるたびに古いテスト接続を閉じ、テストページを開き直します。
- 午前と夜間にそれぞれ1組ずつ行い、両方の時間帯で同じ方法を使います。
- あるノードが夜間だけ遅くなる場合は、具体的な時刻を記録し、すぐに転送パラメーターを変更しないでください。
- すべてのノードが同時に遅くなる場合は、回線層の確認に進み、単一ノードの問題とは判断しません。
サブスクリプションの更新も誤判定の原因になります。更新後は、同じ名前のノードでも以前と同じアドレスやポートとは限りません。比較テストの前にノードの編集情報を開き、入口ドメイン、ポート、転送方式、サーバー名に変更がないか確認します。VMessとVLESSはプロトコル設定の一部にすぎず、実際の速度はサーバー資源、出口帯域幅、輻輳制御、ネットワーク経路にも左右されます。プロトコル名だけで速さを判断することはできません。
第3段階：時間帯と経路から回線の輻輳を見分ける
回線の問題は、設定項目の入力ミスではなく、端末からノード入口まで、またはノードから接続先サイトまでの通信品質が変化して起きることが多いです。複数のノードが近い時間帯に同時に遅くなる、夜間に日中より明らかに遅い、小さなファイルは問題ないのに大容量転送を続けると速度が何度も落ちる、といった症状が典型です。異なる通信事業者間の経路、無線干渉、家庭内の上り回線の使い切りでも似た症状が出ます。
まず時間帯を比較し、次に接続方法を比較します。午前と夜間に同じテストを1組ずつ行い、各組は3回とします。可能なら同じ端末で有線と安定した無線を個別にテストしますが、切り替え後は必ずプロキシ接続を再確立してください。有線が正常で無線だけ遅いならローカル接続に近い問題です。両方が夜間に同時に低下するなら、上流回線の輻輳がより疑われます。
| 症状 | 考えられる層 | 確認方法 |
|---|---|---|
| 日中は安定しているが、夜間に複数ノードが遅い | ピーク時間帯のネットワーク経路 | ノードを固定し、2つの時間帯で各3回測定する |
| 無線は遅いが、有線は正常 | ローカル接続 | 接続機器の近くで、バックグラウンドのアップロードを止めて再測定する |
| ページの初回表示は遅いが、継続ダウンロードは正常 | DNSまたはハンドシェイク経路 | 名前解決時間と実接続遅延を比較する |
| 少量通信は正常だが、継続転送で周期的に低下する | パケットロス、輻輳、トラフィックシェーピング | 30秒以上の連続転送テストを行う |
| 特定の接続先サイトだけ遅い | 接続先サイトまたはノードの出口経路 | 同じ種類の別の接続先を2つ試して比較する |
転送方式も回線の挙動に影響しますが、比較なしに変更してはいけません。TCP、WebSocket、gRPCなどの転送方式はサーバー側の設定で決まり、クライアント側だけでは変更できません。VLESSやVMessノードの転送パラメーターはサーバー側と一致させる必要があります。ネットワーク種別、パス、ホスト名、TLS設定をむやみに変更すると、通常は接続失敗を招くだけで、実際の経路輻輳は解消できません。
Androidでも切り分けの考え方は同じです。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。まずネットワークを固定し、同じノードを時間帯ごとに比較してください。モバイル回線と無線LANは異なる接続経路なので、切り替え後の結果は接続環境の違いを判断する材料であり、クライアント性能の違いを直接示すものではありません。テスト中は省電力設定によるバックグラウンド接続への制限を解除し、画面とテストアプリをアクティブな状態に保ちます。
ログからポート・名前解決・接続エラーを特定する
速度低下に頻繁な切断、再接続、ページの長時間表示停止が伴う場合は、コアのログを確認します。ログを見ると、「接続確立に時間がかかっている」のか「接続自体が確立していない」のかを区別できます。v2rayNではメイン画面のログ欄でリアルタイム出力を確認できます。設定を変更した後は古いログを消去してから問題を再現し、数時間前のエラーを現在の原因と取り違えないようにします。
単発のエラーだけでは、継続的な障害とは限りません。たとえば接続先サイトが接続を切断した場合にも、読み込み失敗が表示されることがあります。同じエラーが短時間に繰り返されているか、当時アクセスしたドメイン、ノード、プロキシモードと合わせて判断してください。次の種類のログは、具体的な確認へ進む手がかりになります。
エラー: failed to find an available destination
原因と対処：出力先のアドレスを解決できない、または利用可能な宛先がない状態です。ノードのドメイン名を確認し、DNS設定を見直してからコアを再起動し、同じエラーが続くか確認します。
エラー: failed to listen TCP on 127.0.0.1:10808
原因と対処：ローカルの待受ポートが別のプロセスに使用されています。「設定」→「パラメーター設定」でローカルポートを確認し、ポートを使用している古いプロセスを終了します。または未使用のポートに変更し、アプリ側のプロキシ設定も同じ値に更新してください。
エラー: transport/internet/tcp: failed to dial
原因と対処：コアがノード入口へのTCP接続を確立できません。サーバーアドレスとポートを確認し、別のノードでも比較します。複数のノードが同じ時間帯に失敗する場合は、ローカルネットワークと上流回線を確認してください。
エラー: context deadline exceeded
原因と対処：処理が制限時間内に完了しませんでした。前後のログから、DNS、ノード接続、接続先へのアクセスのどの段階で発生したかを確認し、ノードとテスト先を変えて範囲を絞ります。
ポート競合を解消した後は、プロキシを使うアプリ側も同時に更新されたか確認します。たとえばローカルSOCKSポートを10808から10818に変更しても、ブラウザーやダウンロードツールが10808を指したままだと、まったく接続できない、または繰り返しフォールバックする状態になります。システムプロキシを使うアプリは通常クライアント設定に追従しますが、プロキシアドレスを手入力したアプリは個別に変更が必要です。
ログに接続終了のメッセージが sporadic に出るだけで、継続ダウンロードが安定しているなら、すべての通知を速度障害とみなす必要はありません。同じエラーが高頻度で繰り返され、毎回明らかな停止を伴う場合や、コアが再起動を続ける場合に対処します。確認が終わったら通常のログレベルに戻し、デバッグ情報を長期間記録して読みづらくしたり、ディスクを圧迫したりしないようにします。
変数を混同しない再テスト手順を作る
切り分けの基本は、一度に1つの変数だけを変えることです。日付、時刻、クライアントとコアのバージョン、接続ネットワーク、ノード、プロキシモード、テスト先、3回分の結果、ログの概要を簡単に記録しましょう。複雑なグラフは不要ですが、「何を変えたか」と「結果を再現できるか」が分かる必要があります。
テスト先を固定する
安定して継続転送できる同じリソースを選び、各回でブラウザー、ダウンロード方法、測定時間を統一します。テスト中に接続先を切り替えないでください。
ローカル要因を除外する
まずバックグラウンドのアップロードとシステム更新を停止し、「システムプロキシ」→「システムプロキシを自動設定」で基本テストを行います。その後、必要に応じてTUNを個別に確認します。
3つのノードを比較する
分流ルールは変えず、ノードだけを切り替えます。各ノードで10秒待ってから3回測定し、中央値で比較します。一時的な瞬間最大値は無視してください。
2つの時間帯を比較する
午前と夜間に同じ手順を繰り返します。複数のノードが夜間だけ同時に低下するなら、ネットワーク経路とピーク時間帯の輻輳を重点的に調べます。
普段の設定に戻す
確認後は元のルーティングルール、DNS、プロキシモードに戻し、コアを再起動します。普段使う接続先にアクセスして、テスト用の設定が残っていないことを確認してください。
ノードを変更してすぐ速度が戻り、システムプロキシ、ルーティング、テスト先を変えていないなら、ノード側の問題が疑われます。グローバルプロキシに切り替えて改善し、ノードは同じなら、まず分流ルールとDNSを確認します。プロキシを無効にしても遅い場合は、ローカルネットワークまたは接続先サイトを先に確認してください。V2Rayのパラメーターを調整し続けても有効な結論は得られません。
断続的な問題は、少なくとも2つの時間帯にまたがって再テストします。短時間で戻ったとしても、ノードのメンテナンス終了、ネットワーク経路の変化、接続先サイトの負荷低下が原因かもしれず、直前に変更した無関係な設定が効いたとは限りません。変更前後の設定とテスト記録を残すことで、同じ試行錯誤を繰り返さずに済みます。
速度低下の切り分けでよくある質問
遅延が最も小さいノードでもダウンロードが遅いのはなぜ？
遅延テストはデータ量が少なく、主に接続確立時間を示すため、継続的な帯域幅は分かりません。候補ノードごとに30秒の連続ダウンロードを3回行い、中央値を比較してください。
すべてのノードが突然同時に遅くなった場合は？
まずシステムプロキシを解除して直接接続をテストし、バックグラウンドでアップロードしているものがないか確認します。直接接続が正常なら、午前と夜間に3つのノードを再測定し、回線が同時に変動しているか判断します。
グローバルプロキシに切り替えて速度が戻る場合、何を意味する？
ノード自体は通常動作しており、ルーティングルールまたはDNS分流に問題がある可能性が高いです。「設定」→「ルーティング設定」で、テストドメインに実際に適用されたルールと出力先を確認します。
サブスクリプションを更新すれば速度問題は解決する？
サブスクリプション内のノードアドレスやパラメーターが変更された場合に限り、改善する可能性があります。更新前後でアドレス、ポート、転送方式、サーバー名を照合し、更新を万能な修復手段と考えないでください。
プロトコルや転送方式を頻繁に変更する必要はある？
必要ありません。VMessとVLESSの転送パラメーターはサーバー側と一致している必要があり、クライアント側だけでTCP、WebSocket、gRPCの設定を変えると不一致になります。まずノードと時間帯の比較で、問題がどの層にあるか確認してください。
最終的な結論は具体的な層に落とし込みます。ローカル層ではプロキシの適用、ポート、DNS、ルーティングを確認し、ノード層では同じ条件で特定ノードだけが継続的に遅いかを見ます。回線層では複数ノードが時間帯に応じて同時に変動するかを確認します。この順序で進めれば無駄な変更を減らせ、後から状況を共有するときも再現可能なテスト条件を示せます。