V2Rayの通信速度が遅いときの切り分け：ノード、回線、ローカル設定を順に確認

再現可能な速度基準を作る

「遅い」という感覚は、まず比較できるデータに置き換える必要があります。ウェブページの表示時間はDNS、キャッシュ、ページスクリプト、接続先サイトの負荷に左右され、1回だけの遅延値も継続的なスループットを示しません。同じレジューム対応の大容量ファイルを選び、同じネットワーク、同じ端末、同じダウンロードツールで3回連続して測定する方法が、より安定しています。

測定前にクラウドストレージの同期、システム更新、ほかのダウンロードを停止します。無線ネットワークはできるだけ同じアクセスポイントに固定し、測定中に有線と無線を切り替えないでください。各回は最低60秒続け、ダウンロード開始直後の瞬間的なピークではなく、安定した区間の平均速度を記録します。

この経路のどの区間もボトルネックになる可能性があります。直結テストではローカル回線の上限を確認し、プロキシテストではノードと回線による損失を観察します。接続先サイトを変えるテストでは、特定のダウンロード元による速度制限を切り分けます。3種類のデータは分けて記録し、1つの速度測定ページだけで結論を出さないでください。

1. v2rayNのシステムプロキシを無効にし、直結でのダウンロード速度を測定して、接続回線の現在の上限を記録します。
2. システムプロキシを戻し、ノードAを選択します。接続が安定してから3回測定し、中央値を取ります。
3. ほかの条件を変えず、ノードB、ノードCの順に測定します。
4. 別のダウンロード元に切り替えて再測定し、速度低下が特定の接続先サイトだけで起きているかを確認します。
5. v2rayNのログに記録されたコアのバージョン、ローカルポート、測定時刻を控え、後から再現できるようにします。

第1段階：ノード自体の速度制限を確認する

ノード側の問題には、安定して再現するという特徴があります。同じ時間帯にノードAが3回連続でノードBを下回り、ノードを切り替えると速度がすぐ戻るなら、まずノードの負荷、サーバー帯域、接続先地域、ノード設定を確認します。この場合、ローカルDNSやシステムプロキシを繰り返し調整しても、通常は結果は変わりません。

ノードをテストするときは、同じプロトコル構成で条件の近い設定を使います。たとえば2つのVLESSノードを比較するなら、接続先地域、伝送方式、暗号化層をできるだけそろえます。遠距離のVMessノードと近距離のVLESSノードを直接比較しても、異なる2つの経路全体の性能が分かるだけで、特定のプロトコルが速いとは証明できません。

ノードBは3回とも約30 Mbpsで、安定した低速でした。帯域制限、継続的な高負荷、サーバー出口の制限が疑われます。ノードCは結果の変動が大きいため、すぐにノード側の速度制限とは判断できません。パケットロス、時間帯、経路の変化も合わせて確認します。

プロトコル名だけで判断しない

• VMessとVLESSはプロトコル構造が異なりますが、実際のスループットはサーバーCPU、回線品質、TLS設定、輻輳制御にも左右されます。
• REALITYやXTLS Visionは特定の接続・伝送要件に対応するもので、どのネットワークでもダウンロード速度が上がるとは限りません。
• ノードの遅延が低いのは往復応答が速いことを示すだけで、サーバー出口の帯域が十分とは限りません。
• サブスクリプションに記載された倍率、名称、地域タグはサービス側の説明であり、ローカルでの3回測定の代わりにはなりません。

第2段階：時間帯とパケットロスから回線混雑を見分ける

中継回線の問題は、時間帯による変化として現れやすい特徴があります。同じノードが午前中は正常なのに夜の決まった時間帯に遅くなり、深夜に戻るなら、回線混雑やネットワーク間の出口負荷が考えられます。ノードのサーバー自体が夜間に高負荷になっている可能性もあるため、複数ノードで比較してください。

• 08:00、14:00、21:30の3つの時間帯に同じノード群を測定し、各時間帯で同じ3回のダウンロードを実行します。
• 実際の接続遅延、ダウンロード速度の中央値、明らかな停止の有無を記録し、ICMP pingだけに頼らないでください。
• 異なる地域のノードを2つ選びます。すべての遠隔ノードが同じ時間帯に低下するなら、回線要因である可能性が高くなります。
• 特定のノードだけ低下し、ほかのノードが安定しているなら、引き続きノード側の問題として確認します。

ICMP pingで分かるのは、基本的な往復時間とパケットロスの手がかりだけです。サーバーによってはICMP応答を制限していても、TCPやUDPのプロキシ接続は正常な場合があります。逆に、pingの数値が良くても、大容量転送の経路で再送が続くこともあります。pingは傾向の観察には使えますが、ノードの速度ランキングだけで判断することはできません。

第3段階：v2rayNのローカル設定を1項目ずつ切り分ける

ほかのノードが正常で、時間帯による回線差も目立たない場合にだけ、ローカル設定を確認します。ここでも一度に変更するのは1項目だけにし、変更後は現在のノードに再接続して同じテストを繰り返します。複数の項目を続けて変更すると、速度が戻っても本当の原因を特定できません。

1. 使用中のコアを確認：ログを開き、v2rayNとXrayの実際のバージョンを記録します。たとえば切り分け記録には「v2rayN 7.12.5、Xray 25.5.16」のように書き、「最新版」とだけ記載しないでください。
2. ルーティングモードを確認：「設定」→「ルーティング設定」で現在のルールを確認します。まずグローバルプロキシで比較し、グローバルモードは正常なのにルールモードだけ遅い場合は、ダウンロード先ドメインが誤って直結または制限されたアウトバウンドに振り分けられていないか確認します。
3. ローカルポートを確認：「設定」→「パラメーター設定」を開き、SOCKS、HTTP、混合ポートがほかのプログラムと競合していないことを確認します。測定ツールは画面に表示された実際のポートを指定してください。
4. Muxを無効にして比較：現在のサーバー設定を編集し、Muxの元の状態を記録してから無効にし、再接続して3回測定します。大容量ファイルの転送は多重化で必ずしも改善せず、不安定な経路では競合が増えることもあります。
5. DNS経路を確認：最初の表示だけ遅く、接続確立後の速度が正常なら、まず名前解決にかかる時間を確認します。ダウンロード全体が遅い場合、DNSが主なボトルネックであることは通常ありません。
6. 端末リソースを確認：ダウンロード中のCPU、メモリ、ネットワークアダプターの使用率を確認します。1つのコアプロセスが長時間1コアの100%近くを使っているなら、同時接続数を減らし、別の端末でも比較します。

システムプロキシとTUNモードも分けてテストします。通常のブラウザー利用ではまずシステムプロキシを使い、より多くのアプリの通信を取り込む必要がある場合にTUNを試します。2つのモードでは通信の入口とルーティング経路が異なるため、結果を同じ速度表に混在させないでください。

Android端末も比較検証に使えます。同じサブスクリプションをv2rayNGまたはv2flyNGに読み込み、同じノードを選び、同じ無線ネットワークで測定します。デスクトップだけが継続的に遅く、Androidが正常なら、ローカルポート、ルーティングモード、デスクトップ端末のリソースを優先して確認します。比較時は、v2rayNGがXrayコア、v2flyNGがv2flyコアを使用する点にも注意し、コアと設定の違いを記録してください。

よくある誤判定と具体的な対処

速度の問題は、1つの数値だけで判断すると誤りやすくなります。遅延、ハンドシェイク時間、最初のデータ到着時間、継続的なダウンロード速度は別の指標です。条件を固定し、再現可能な測定を行って初めて、結果に意味が生まれます。

サブスクリプションの更新によって、ノードアドレス、ポート、伝送パラメーターが変わることもあります。更新後に速度が急に変化した場合は、更新時刻、ノード名、コアのログを残し、3回の測定をやり直します。更新前後のデータをそのまま混ぜて平均しないでください。

結論を出す：証拠に基づいて適切な層で止める

完全な切り分けとは、すべての設定を一通り変更することではありません。安定して再現できる差が最初に現れるデータ群を見つけることです。ノードを替えるとすぐ戻るならノード層で止め、時間帯で速度が変わるなら回線層へ進み、特定の端末やプロキシモードだけに異常がある場合はローカル設定を確認します。

• ノード層の結論：同じ時間帯、同じ端末で、特定のノードが3回連続してほかのノードを大きく下回る。
• 回線層の結論：複数のノードが決まったピーク時間帯に同時に低下し、時間帯をずらすと回復する。
• ローカル層の結論：同じノードがほかの端末では正常、またはローカル設定を1項目変更すると結果が安定して回復する。
• 接続先サイトの結論：特定のドメインまたはダウンロード元だけが遅く、ほかの接続先サイトは正常。

最終記録は、測定時刻、ノード名、コアのバージョン、設定変更、3回分の中央値という5列で残すのがおすすめです。再び速度が低下したときも同じ条件をそのまま使えるため、以前の問題が再発したのか、新たな経路変化なのかをすぐ判断できます。