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

まず確認：遅延が大きい、ダウンロードが遅い、最初の表示が遅い？

クライアントに表示される遅延は、ダウンロード速度を示すものではありません。TCP接続テストで通常確認できるのは接続確立までの時間です。プロキシ経由のHTTPテストには、ハンドシェイクや接続先サイトの応答時間が含まれる場合もあります。測定方法が異なる結果を単純に比較することはできず、そのノードで動画を安定して再生できるかも判断できません。V2Rayが遅いと感じたら、まずどの操作に時間がかかるのか記録しましょう。

もう一つのよくある勘違いは、速度の単位です。インターネット回線のプランではMbps、ダウンロードツールではMB/sが使われることがあり、両者には約8倍の差があります。たとえば80Mbpsを換算すると理論上は10MB/sです。実際の転送速度はプロトコルのオーバーヘッドや回線の共有状況にも左右されます。この換算は単位をそろえるためのもので、ノードがプランの公称速度に達するという意味ではありません。

基準を作る：接続先を固定し、一度に変える条件は一つだけ

速度を測る前に、システム更新、クラウド同期、ほかの端末による大容量通信を一時停止します。接続方法、クライアントのバージョン、コアのバージョン、ノード名、測定時刻を記録してください。v2rayNはデスクトップ向けクライアントです。Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。クライアント名とコアのバージョンは別々に記録し、「V2Ray最新版」とだけ書かないようにしましょう。

上記は測定方法と単位換算の目安であり、本サイトで実測した結果ではありません。利用権限のある、十分な時間転送を続けられる固定のHTTPSファイルを選び、測定ツールと同時接続数をそろえましょう。サイズの小さなファイルでは、接続が安定する前に転送が終わることがあります。測定サイトがサーバーを自動で切り替える場合も、余計な変数が加わります。

1. ローカル回線の基準を測る：プロキシを無効にし、直接接続できる固定のリソースにアクセスして、接続ネットワーク自体に問題がないか確認します。この結果はローカル回線の参考値であり、国際通信経路の状態を示すものではありません。
2. 現在のノードを測る：元のプロキシ設定に戻し、固定のプロキシ接続先で3回測定します。1回あたり約30秒観察し、持続速度と接続切断の有無を記録してください。
3. 変える条件は一つだけ：ネットワークを固定してノードを切り替え、次にノードを固定してネットワークを切り替えます。DNS、ルーティング、通信設定を同時に変更しないでください。
4. 元の設定を記録する：テストが終わったら一時的な変更を元に戻し、トラブルシューティング用の設定をクライアントに残さないようにします。

第1段階：ノードの負荷とサーバー側の制限を確認する

同じネットワーク、同じ接続先で特定のノードだけが継続して遅い場合は、そのノードと対応する通信経路を優先して調べます。サーバーのCPUや帯域の混雑、アカウントの速度制限、出口回線の混雑、ノードから接続先サイトまでの経路などが原因として考えられます。通常、クライアントからサーバーの実際の負荷は確認できません。「ノードを変えたら直った」という結果で原因の範囲は絞れますが、それだけでサーバーの過負荷と断定することはできません。

• 違いのあるノードを比較する：名前が同じでポートだけ異なるノードは、同じサーバーや出口回線を共有している可能性があります。サービス提供元が別の地域または別回線として案内している、利用可能なノードを優先して比較しましょう。
• サービスの利用条件を確認する：アカウントの残り通信量、プランの速度制限、同時接続数の上限を確認します。制限に達している場合、ローカルのDNSを変更しても改善は期待できません。
• 時間帯を変えて測る：たとえば10時と21時に同じ条件で測定します。夜間だけ明らかに遅くなる場合は、その傾向を記録し、別のネットワークでの結果とあわせて判断してください。
• 測定中に設定を更新しない：サブスクリプションを更新すると、サーバーアドレスやパラメーターが変わることがあります。更新が必要な場合は、更新後に改めてテスト記録を取りましょう。

VMessとVLESSの選択も、この比較の代わりにはなりません。VMessの認証・暗号化方式と、VLESSで使われる通信のセキュリティ設定は異なりますが、全体の転送速度はサーバーの性能、通信方式、往復遅延、パケットロスにも左右されます。プロトコルはサーバー側の設定に合わせてください。速度向上を期待して、クライアントのプロトコル項目だけを変更してはいけません。

第2段階：ネットワークを比較して回線の混雑やパケットロスを見分ける

複数のノードが同時に遅くなる場合は、まずローカル回線を確認し、その後に上流の通信経路を調べます。Wi-Fiの電波表示が最大でも、同じ周波数帯の干渉やルーターの処理待ちが起きていることがあります。ローカルのアップロード帯域が使い切られると、確認応答や操作リクエストにも影響し、ウェブページの表示が著しく遅くなる場合があります。デスクトップでは有線接続を試し、AndroidではWi-Fiとモバイルデータ通信を切り替えて比較できますが、データ通信量に注意してください。

この流れは、アクセス時に通過する各区間を示したもので、すべての接続に個別の中継地点があるという意味ではありません。ノードと接続先を固定したままネットワークを変えて改善するなら、接続ネットワークまたはその先の経路に差があると考えられます。ネットワークを変えても改善せず、ノードを変えると直る場合は、そのノードのサーバーや回線に原因がある可能性が高まります。どちらの変更でも改善する場合は、引き続き組み合わせを変えて確認し、原因を一つに決めつけないでください。

• ローカルゲートウェイを確認する：診断が許可されているネットワークで、実際に使われているデフォルトゲートウェイの遅延を短時間測定します。有線では安定し、Wi-Fiで大きく変動する場合は、まず無線接続を確認しましょう。
• ICMPの結果は慎重に判断する：ゲートウェイやサーバーがICMP応答を制限している場合があります。pingのパケットロスが実際の通信のパケットロスを意味するとは限らず、応答がなくてもプロキシのポートに接続できないとは限りません。
• 経路の調査結果は手がかりとして扱う：途中のルーターで一時的にパケットロスが見えても、その後の区間では正常な場合、調査用パケットが制限されていることがあります。その区間を直ちに障害箇所と判断しないでください。
• 帯域を使う通信を一時停止する：アップロードを止めると遅延が改善する場合は、コアの設定をすぐに変えるのではなく、ローカル回線の共有状況やルーターのキューを確認しましょう。

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

ローカル環境を調べるときは、リクエストが実際にどこを通っているかをまず確認します。システムプロキシはアプリがプロキシ設定を参照する仕組みで、TUNは仮想ネットワークインターフェースを通じて対象の通信を処理します。どちらも、画面に「起動中」と表示されているだけでは、通信を正しく処理できているとは限りません。ログを開いたら、接続先へのアクセスを一度だけ再現し、受信、ルールの一致、送信先を確認します。ほかのバックグラウンド通信にログが埋もれないようにしましょう。

1. プロキシの入口を確認する：デスクトップ版では、v2rayNのメイン画面で「システムプロキシ」と現在のルーティング設定を確認します。Androidでは、v2rayNGまたはv2flyNGのVPNサービスが確立していることを確認し、アプリごとのプロキシ対象も調べてください。画面上の項目名はバージョンによって異なる場合があります。
2. 待ち受けポートを確認する：クライアント画面に表示される実際のローカルポートを確認します。アプリに127.0.0.1:10808を手動で設定している場合は、クライアントがそのアドレスとポートで、指定されたプロキシプロトコルを使って待ち受けていることを確認してください。10808は例であり、バージョンを問わず使われる固定の既定値ではありません。
3. 通信の経路を単純にする：ほかのプロキシやVPNツールを一時的に終了し、経路を一つに絞って再測定します。システムプロキシとTUNを同時に使うことが必ず問題になるわけではありませんが、切り分け中は余分な転送やループによる影響を避けましょう。
4. ルーティングルールの適用先を確認する：遅いサイトへの通信が意図せず直接接続になっていないか、逆に直接接続するはずのローカルリソースがリモートプロキシを経由していないか確認します。必要であれば、プロキシ経由にする一時的なテストルールと現在のルールを比較し、測定後に元へ戻してください。
5. 次にDNSを確認する：ノードのサーバーアドレスの名前解決と、接続先ドメインの名前解決を分けて考えます。ノードのアドレスを解決できないと接続を確立できず、接続先ドメインの名前解決が遅い場合は、初回アクセス時の待ち時間に表れやすくなります。ログで該当箇所を確認し、DNSの設定を一度にすべて置き換えないでください。

DNSの調整で変わるのは主に名前解決の時間や応答されるアドレス、その後の経路選択です。サーバーの帯域が増えるわけではありません。特定のドメインだけ遅い場合は、応答されたCDNのアドレスが現在の出口回線に適しているかも確認しましょう。最終設定としてドメインをIPアドレスに置き換えるのは避けてください。HTTPSの証明書検証、SNI、ウェブサイトの仮想ホストが元のドメインに依存していることがあり、IPアドレスへの直接アクセスで別のエラーが発生する可能性があります。

ログを確認する：「遅い」症状と接続エラーを分けて考える

大量の再試行によって、実際は接続に失敗しているのに、ウェブページの読み込みが遅いだけに見えることがあります。以下はログによく現れるエラーの原文です。前後の文言はコア、OS、バージョンによって異なります。接続先のアドレスとポート、エラーが発生した段階もあわせて確認してください。同じタイムアウトのメッセージでも、DNS、ノードへの接続、接続先への接続のいずれかで発生する可能性があります。

トラブルシューティングが終わったら、ログのレベルを通常に戻してください。ログを共有する前に、認証情報、サブスクリプションURL、個人のアクセス履歴を隠し、時刻、エラーの前後関係、必要なネットワーク情報だけを残します。v2rayNの日常的な確認やメンテナンスについては、ノードの速度測定とメンテナンスの手順も参照できます。

よくある質問：速度テストは正常なのに、実際の通信が遅いのはなぜ？