ノードには接続できるものの、Webページの表示が遅い、動画が止まる、ダウンロード速度が落ちるといった場合に役立つ内容です。まずテスト条件をそろえ、ノード・接続ネットワーク・ローカルのプロキシ経路を比較します。遅延、継続的な転送速度、ログを手がかりに原因を切り分けましょう。読み終えるころには、再現可能な結果をもとに出口を変えるべきか、回線を確認すべきか、クライアントを調整すべきか判断できます。
まず確認：接続遅延・最初の応答・ダウンロード速度
ノード一覧に表示される遅延は、利用可能な帯域幅を示すものではありません。TCP接続テストで主に分かるのは接続確立までの時間です。クライアントの接続テストでは、テスト先やTLSハンドシェイク、サーバーの応答時間も影響します。表示が80 msでも、動画を安定して再生できるとは限りません。反対に、遅延が大きいノードでも継続的な転送速度が高い場合があります。
速度測定の前に、同期・システム更新・ほかのダウンロードを一時停止し、クライアントとテストを1つずつに絞ります。同じ端末、同じ対象ファイル、同じプロキシ方式を使い、1回につき変更する条件は1つだけにしてください。以下はテスト条件の目安であり、特定の回線で測定した結果ではありません。
- クリックしても長時間応答がなく、開始後はすぐに進む：まずDNS名前解決、接続確立、接続先サービスの応答を確認します。
- 開始は速いが、その後の速度が低い：ノードの出口、回線容量、接続先サイトの速度制限を優先して比較します。
- 速度が何度もゼロになったり、接続が切れたりする：Wi-Fiの電波強度、パケットロス、カーネルのエラー、端末のスリープを確認します。
- 特定のサイトだけ遅い：まず同種の別サイトで試し、すぐにすべてのノードを故障と判断しないでください。
単位にも注意してください。公称速度が100 Mbpsの場合、8 bit = 1 Byteで換算すると理論上限は12.5 MB/sです。実際にはプロトコルのオーバーヘッドやほかの通信分が差し引かれます。速度測定ツールがMbps、ダウンロード画面がMB/sで表示している場合、数値をそのまま比較することはできません。
第1段階：同じ条件で比較し、ノードの問題を絞り込む
ノードの負荷をクライアントから直接確認するのは一般に困難です。観察できるのは通信全体の結果であり、サーバーのCPU使用率や共有出口の利用率ではありません。そのため、「ノードを変えたら速くなった」ことだけでは、元のノードが過負荷だったとは断定できません。ノードを変えると、入口・出口・接続先への経路・事業者のトラフィック制御も変わる可能性があります。
- v2rayNのノード一覧でノードAを選び、右クリックメニューから「アクティブサーバーに設定」を選択します。新しいテスト接続でノードAが使われていることを確認してください。
- ダウンロード可能で十分なサイズの同じファイルを選び、30秒間速度を確認します。3回繰り返し、中央値と切断の有無を記録してください。
- ノードBに切り替え、進行中のダウンロードを終了してから接続し直します。テスト先とローカルネットワークは変えないでください。
- ピーク時間帯以外と、普段利用する夜間の両方で再測定します。接続方式、クライアントのバージョン、使用中のコアも記録してください。
| 比較した結果 | まず疑う箇所 | 次に行う確認 |
|---|---|---|
| 同じ接続先でAは遅く、Bは速い | Aの経路または出口 | 別の接続先でもAとBを比較する |
| AもBも夜間だけ遅い | 共有回線または出口のピーク時混雑 | ノードは変えず、接続ネットワークを切り替える |
| 2つのノードとも特定のサイトだけ遅い | 接続先サイト、CDN、または接続先への経路 | 別のサイトで試し、出口の地域も比較する |
| 同じノードが別の端末では正常 | 元の端末の設定または性能 | プロキシ経路とCPU使用率を確認する |
結論：変数を1つずつ切り替えてから、ノード変更を判断する
複数の接続先・時間帯でノードAだけ明らかに遅い場合に、Aの変更を優先してください。すべてのノードが同時に遅くなる場合は、まず共通の接続ネットワークとローカル環境を確認します。
VMess、VLESSはプロトコル名であり、速度のランクではありません。異なる回線の測定結果の差を、プロトコルだけの違いに結びつけることはできません。サブスクリプションに記載された地域名も、実際の入口や通信経路全体を保証するものではありません。ノードを区別するためのメモとして使い、同じ条件で測定した結果をもとに判断してください。
第2段階：ローカルの接続環境と遠隔回線の混雑を切り分ける
回線を比較するには、端末・ノード・接続先を固定し、接続ネットワークだけを切り替えるのが効果的です。たとえば、まず自宅の固定回線で試し、次にスマートフォンのテザリングを使います。テザリングはプランの速度制限や電波状況の影響を受けるため、絶対的な基準にはなりません。ただし、接続先を変えると安定して改善するなら、元のネットワークからノードの入口までの経路を詳しく確認する価値があります。
- まずローカル回線の基本状態を測る：プロキシを一時停止し、直結でアクセスできることが分かっている接続先を試します。直結でも異常がある場合は、Wi-Fiの干渉、ルーターの負荷、固定回線の障害を先に確認してください。
- まず有線接続と比較する：可能であればLANケーブルを使います。Wi-Fiの場合はルーターの近くで試し、周波数帯も切り替えて比較してください。室内の電波状況をノードの問題と取り違えないようにします。
- ゲートウェイへの応答を確認する：OSのネットワーク設定でデフォルトゲートウェイのアドレスを調べ、端末からゲートウェイ、次に応答確認が許可された外部アドレスへ順にテストします。
- 時間帯を変えて再測定する：測定した時刻を記録してください。決まったピーク時間帯だけ速度が落ちる場合、通信事業者に問い合わせる際は、一時点の測定画面だけでなく、時間帯を変えた比較結果も添えましょう。
Linuxでは、以下のコマンドでローカルゲートウェイからのICMP応答を確認できます。例にある 192.168.1.1 は実際のゲートウェイアドレスに置き換えてください。Windowsでは ping -n 30 192.168.1.1 を使用できます。これらの確認は通常、アプリケーション層のプロキシを経由しないため、プロキシトンネル内の実際の通信速度を示すものではありません。
ping -c 30 192.168.1.1端末からゲートウェイへの通信でパケットロスや大きな揺らぎがある場合は、まずローカルネットワークを調べます。一方、外部サーバーがICMPに応答しなくても、プロキシ接続が使えないとは限りません。経路上の機器が応答を制限している場合もあります。経路確認で途中の1ホップにパケットロスが見えても、その後のホップや宛先が正常なら、その機器が実際の通信データを破棄しているとは断定できません。
第3段階：システムプロキシ・ルーティング・ローカルポートを確認する
「クライアントを起動している」だけでは、使用中のアプリがそのクライアントを経由しているとは限りません。ブラウザーはシステムプロキシを使う場合があり、コマンドラインツールは環境変数だけを参照することがあります。アプリ独自のプロキシ設定が使われることもあります。速度を最適化する前に、まず通信がどの経路を通っているか確認してください。v2rayNでは、タスクトレイの右クリックメニューから「システムプロキシ」→「システムプロキシを自動設定」を選択できます。画面上の名称はバージョンやプラットフォームで異なる場合があります。Linuxのデスクトップ環境では、システムのネットワークプロキシ設定も確認してください。
- 待ち受けポートを確認する：v2rayNの「設定」→「パラメータ設定」を開き、ローカルの待ち受け設定と関連ポートを確認します。以下では
127.0.0.1:10808をSOCKS接続の例に使用しています。実際の値は現在の設定に合わせてください。 - プロキシの適用方法を一時的にシンプルにする：切り分け中はTUNをオフにし、ローカルプロキシを明示してテストします。終了後は元の設定に戻してください。システムプロキシ、TUN、アプリ独自のプロキシが互いに干渉するのを防げます。
- ルーティングルールの適用先を確認する：テスト対象のドメインが直結ルールやブロックルールに該当していないか確認します。対象をプロキシ経由にする変更は短時間の確認にとどめ、終了後は元のルーティング設定に戻してください。
- アプリの既存接続を確認する：ノードやルーティングを切り替えたら、テストを再起動してください。ブラウザーがすでに確立している接続は、新しい出口へすぐに切り替わるとは限りません。
curlを使える端末では、SOCKSの接続先を明示すると、アプリがシステムプロキシを参照しているかどうかに左右されずにテストできます。以下のリクエストはレスポンスヘッダーだけを取得するもので、ダウンロード速度の測定ではありません。socks5hを使うと、接続先ドメインの名前解決をプロキシ側に任せられるため、ローカルでの名前解決経路との比較に適しています。失敗した場合は、ログとあわせて原因を判断してください。
curl --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 10 --max-time 30 \
--head https://example.com/プロキシを明示したリクエストが正常なのにブラウザーだけ遅い場合は、ブラウザーのプロキシ拡張機能、独自のDNS設定、キャッシュされた接続を確認してください。どちらも遅い場合は、ノードと回線の比較に戻ります。「速度向上」のためにローカルの待ち受けアドレスをすべてのネットワークインターフェースに変更しないでください。待ち受け範囲を広げても出口の帯域幅は増えず、アクセス可能な範囲が変わるだけです。
DNS・リソース使用率・ログ：残る原因を確認する
DNSは、ダウンロード開始後の継続的な転送速度よりも、サイトを最初に開くときや接続を確立するときに影響しやすい要素です。ページが表示されるまで長く待たされ、その後の転送は正常な場合は、新しいドメインと再訪問時の違いを比べ、名前解決のログを確認してください。ブラウザーのセキュアDNS、システムDNS、カーネルのDNSが異なる経路を使うことがあり、どれか1つを変更しても実際のリクエスト経路が変わるとは限りません。
- 端末の負荷を確認する：ダウンロード中にタスクマネージャーやシステムモニターを確認してください。特定のCPUコアが継続してほぼ100%になっている、または端末が明らかに発熱してクロックが低下している場合は、負荷の高いバックグラウンド処理を終了してから転送速度を比べます。
- 必要なときだけログを有効にする：問題を再現する間だけログの詳細度を上げ、確認後は元に戻してください。詳細なデバッグログを常時有効にすると、ディスクへの書き込みが増えるほか、アクセス先のドメインなどが記録されることがあります。
- MTUの変更は慎重に：TUN使用時に一部のサイトが固まる、大きなリクエストだけ失敗して小さなリクエストは成功するといった根拠がある場合に限って調べます。特定のMTU値を汎用的な速度向上設定として使わないでください。
- カーネルは条件をそろえて比較する：v2rayNはクライアント、V2RayとXrayはカーネルです。切り替える前にプロトコルとトランスポート設定の互換性を確認し、カーネル・ノード・DNSを同時に変更しないでください。
以下は、カーネルや接続ログに実際に記録されることのあるエラー例です。前後の文脈や具体的な形式はプラットフォームによって異なります。障害が起きた段階を絞り込むためのものであり、「ノードの速度が遅い」ことを直接証明するものではありません。
エラー：bind: address already in use
原因：ローカルの待ち受けアドレスとポートが、別のプロセスによってすでに使用されています。
対処：重複して起動しているクライアントを終了するか、ローカルポートを変更し、アプリ側のプロキシ設定も合わせて変更します。カーネルを再起動したあと、待ち受けに成功したことを確認してください。
エラー：i/o timeout
原因：ネットワークの読み込みまたは書き込みがタイムアウトしています。名前解決・接続・データ転送のいずれかの段階で発生する可能性があります。
対処：前後のログから接続先アドレスと処理段階を確認し、同じノードでネットワークを変える比較と、同じネットワークでノードを変える比較を行います。
エラー：connection refused
原因：接続先から接続が拒否されています。ローカルのプロキシポートへの接続では、カーネルが待ち受けていないか、ポート番号が間違っている場合によく発生します。
対処：ログに記録されたアドレスがローカルか遠隔かを確認してから、ローカルの待ち受け状態、またはノードのアドレスとポート番号を調べます。
ログを共有する前に、サブスクリプションURL、ユーザー識別情報、認証情報を削除してください。障害の記録を提出する場合は、エラーの発生時刻、接続先の種類、クライアントとカーネルのバージョン、通信の適用方法、比較結果を残せば十分です。設定全体のスクリーンショットより、再現に役立つ情報になります。
よくある質問：速度測定は速いのに、実際の利用では遅いのはなぜ？
ノードの遅延は小さいのに、動画がずっとバッファリングするのはなぜ？
まずプレーヤーのバッファ状況と接続速度を確認し、同じノードで別のファイルもダウンロードしてみます。遅延の測定結果から、動画CDNへの転送速度は分かりません。そのプラットフォームだけ遅い場合は、出口の地域と接続先への経路を優先して比較してください。遅延の小さい順だけでノードを選ばないようにしましょう。
TUNを有効にするとダウンロード速度は上がりますか？
TUNは通信を取り込むための仕組みであり、帯域幅を自動的に増やすものではありません。まずプロキシを明示して基準値を測り、その後TUNを有効にして再測定してください。TUN使用時だけ問題が起きる場合は、ノードを次々に変更するのではなく、ルーティング・DNS・権限・インターフェースの設定を確認します。
同じノードなのにスマートフォンは正常で、PCだけ遅いのはなぜ？
まず両方の端末が同じ接続ネットワークを使っていることを確認し、スマートフォンがモバイルデータ通信に切り替わらないようにします。PCではcurlでプロキシを明示したテストを行い、ブラウザーと比較するとともに、バックグラウンドのダウンロードやCPU使用率も確認してください。Android版のv2rayNGは主にXrayカーネル、v2flyNGはV2Flyカーネルに対応しています。設定機能を区別せずにそのまま流用しないでください。
サブスクリプションを更新したら、以前は速かったノードが遅くなったのはなぜ？
アクティブなノードが変わっていないか、サービス提供元がアドレス・ポート・トランスポート設定を変更していないか確認してください。サブスクリプションは設定を配布するものであり、通信データを運ぶものではありません。ノードを選び直して新しい接続を確立し、同じ接続先で3回比較してください。
速度測定では帯域幅を使い切れるのに、特定のファイルだけダウンロードが遅いのはなぜ？
速度測定ツールは複数の接続を使う一方、ファイルのダウンロードは単一接続の場合があります。接続先サーバーの速度制限も考えられます。まず同じ接続先で単一接続時の速度を比べてください。むやみに同時接続数を増やすと、共有帯域を圧迫したり、サーバー側の制限にかかったりする可能性があります。
最後に：再現できる記録を残し、効果のあった変更だけを維持する
調査が終わったら、「同じ端末・同じノード・同じ接続先で、自宅の固定回線では遅く、テザリングでは正常」のように、何が変わったかを一文で説明できる状態を目指しましょう。「設定をいろいろ変えたら、なんとなく速くなった」では、次に何をすべきか判断できず、どの変更が効果をもたらしたのかも分かりません。
- 測定時刻、接続ネットワーク、ノードのメモ、クライアントとカーネルのバージョンを記録します。
- 継続的な転送速度を3回分保存し、単位・接続先・複数接続の有無を記載します。
- 一時的に変更したルーティング、ログの詳細度、通信の適用方法を元に戻し、効果を確認できた設定だけを残します。
- クライアントのバージョンを変更する場合は、先に設定をバックアップし、同じ条件で再測定してください。インストール方法と基本的なプロキシ設定は、使い方ガイドを参照できます。