接続できるのに読み込みが遅い場合は、接続確立の遅さとダウンロード中の遅さを切り分け、テスト先を固定したうえでノード、接続ネットワーク、ローカル設定を順に比較します。ノードをすでに登録している v2rayN、v2rayNG、v2flyNG ユーザー向けです。手順ごとに結果を記録すれば、回線の混雑をクライアント設定の問題と取り違えずに原因を絞り込めます。
まず基準値を確認：遅延とダウンロード速度は別
TCPingの値が低い場合に分かるのは、指定したアドレスとポートへのTCP接続が速く確立できることだけです。プロキシ認証やTLSハンドシェイク、接続先サイトへのアクセスが成功するとは限りません。実接続の速度テストでは通常、プロキシ経由でテスト先にリクエストするため実際のアクセスに近いものの、テスト先やタイムアウト設定、キャッシュの影響を受けます。動画やファイルのダウンロード速度にそのまま換算することはできません。
まずクラウドストレージの同期、システム更新、ほかのダウンロードを一時停止し、同じテスト先で比較します。ネットワークの種類、ノード、テスト時刻、エラー表示を記録してください。以下の数値はテスト条件と単位換算の目安であり、本サイトで測定したノードの実測値ではありません。
ブラウザーに表示されるMB/sと、回線プランに記載されるMbpsは別の単位です。また、「最初のページ表示に時間がかかるが、表示後のダウンロードは正常」と「接続はすぐに確立するが、ダウンロード速度がずっと低い」も区別しましょう。前者は名前解決、ハンドシェイク、ルーティングを、後者は帯域、混雑、ノードの出口を優先して確認します。
- 特定のサイトだけ遅い：別の事業者が運営するサイトもテストし、接続先の速度制限、地域別の制御、CDNの違いを切り分けます。
- プロキシ経由のサイトがすべて遅い：ノードと回線を比較します。最初にDNS設定一式を変更するのは避けてください。
- 直接接続も遅い：まずローカルのWi-Fi、回線の利用状況、ルーターを確認してから、プロキシの速度を評価します。
第1段階：比較テストでノード負荷を見極める
クライアントの速度は、VMessやVLESSといったプロトコル名だけで決まるわけではありません。サーバーのCPU、出口帯域、同時接続数、サービス事業者の速度制限がボトルネックになることがあります。ノード名に含まれる地域名が、実際の接続経路を示すとも限りません。名前の異なる2つのノードが同じ入口や出口を共有している場合もあります。
-
テスト先を固定する
速度テストが許可されている、十分なサイズのHTTPSリソースを選び、同じブラウザーまたはコマンドラインツールを使います。複数のテストを同時に実行すると、同じ回線帯域を奪い合うため避けてください。
-
使用するノードを選ぶ
v2rayNのメイン画面にあるサーバー一覧からノードを選び、右クリックして「アクティブサーバーに設定」を選択します。現在のアクティブ項目が切り替わったことを確認してからアクセスしてください。一覧の行を選択しただけでは切り替わっていない場合があります。
-
実接続をテストする
サーバー一覧を右クリックし、「サーバーの実接続遅延をテスト」を選択します。画面の文言はバージョンによって多少異なることがあります。TCP接続だけのテストではなく、実接続テストを選び、タイムアウトと成功回数を記録してください。
-
ノードを切り替えて比較する
入口または回線が異なるノードに切り替え、ネットワーク、テスト先、ツールは変えずに各3回測定します。偶然の結果だけで判断しないよう、別の時間帯にも再測定してください。
同じネットワークで特定のノードだけ遅く、ほかの入口は正常なら、そのノードまたは経路に問題がある可能性が高くなります。日中は正常で夜間に全体的に速度が落ちる場合は、まず時間帯に関連した混雑を疑います。クライアント側の結果だけでは、サーバー負荷と事業者の経路のどちらが原因かは断定できません。サーバー側の監視情報や、さらに多くの回線での比較が必要です。
第2段階：接続ネットワークとリモート回線を切り分ける
ノードを変えずに接続ネットワークを切り替えるのは、手軽な確認方法です。たとえば、パソコンを自宅のWi-Fiからスマートフォンのテザリングに切り替える、またはAndroid端末でWi-Fiとモバイルネットワークを比較します。モバイルネットワークでテストするとデータ通信量を消費するため、ファイルサイズとテスト時間に注意してください。ノードとDNSを同時に変えず、ネットワークだけを一度に変更します。
| 確認結果 | 優先して疑う要因 | 次に行う確認 |
|---|---|---|
| 同じノードがテザリングでは速く、自宅のネットワークでは遅い | ローカルの接続環境、または事業者から入口までの経路 | パソコンを有線接続に切り替え、ほかの端末のダウンロードを止めて、同じノードを再テストする |
| 同じネットワークで、すべてのノードが遅い | ローカルの帯域、共通の入口、またはテスト先 | まず直接接続のリソースをテストし、その後、異なる入口とテスト先に切り替える |
| 夜間だけダウンロード速度が継続して低下する | 経路の混雑、または共有出口の帯域競合 | 同じテスト先を時間帯を変えて記録し、ほかの回線と比較する |
| 特定のテスト先だけ遅い | 接続先サービス、出口から接続先までの経路、またはCDN | 別のテスト先で再確認し、ノード全体が使えないとすぐに判断しない |
Windowsでは ping -n 20、macOSでは ping -c 20 を使ってデフォルトゲートウェイをテストできます。ゲートウェイのアドレスは現在のネットワーク情報で確認してください。ローカルゲートウェイへのパケットロスが頻繁に発生する場合は、まず無線の電波状況と端末の負荷を改善します。リモートサーバーがICMPを制限していることもあります。経路追跡で応答しないホップがあっても、そこで実際の通信が失われているとは限りません。
- Wi-Fiを使っている場合は、まずアクセスポイントに近づき、可能なら有線接続に切り替えて、無線干渉を切り分けます。
- 経路追跡は経路を推測する手がかりとして使い、実際のHTTPSリクエストの結果と合わせて判断してください。途中のホップのパケットロス率だけで結論を出さないようにします。
- 大きなページや長時間の接続だけが止まる場合は、パスMTUなどの問題も検討します。根拠がないままネットワークアダプターの設定を一括変更しないでください。
第3段階：アプリの通信が実際にプロキシを経由しているか確認する
システムプロキシの設定が反映されるのは、その設定に従うアプリだけであり、すべてのプログラムが経由するとは限りません。Tunモードは仮想ネットワークインターフェースで通信を取り込みますが、ルーティングや除外ルールの影響を受けます。トラブルシューティングでは、この2種類の接続方法を混同しないでください。まずテストで使っている方式を特定し、リクエストが実際にどのアウトバウンドに振り分けられているか確認します。
v2rayNでは「設定」→「パラメーター設定」でローカルの待ち受け設定を確認し、「設定」→「ルーティング設定」でルールをチェックできます。メニュー名はバージョンによって異なる場合があるため、現在の画面表示に従ってください。以下では、ローカルのSOCKS待ち受けを 127.0.0.1:10808 と仮定します。これはコマンドの例にすぎないため、実行前に実際のポート番号に置き換えてください。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} bytes_per_second=%{speed_download}\n" https://example.com/以下のコマンドはmacOSとLinuxのシェル向けです。Windows PowerShellでは curl.exe を使用し、/dev/null を NUL に置き換えてください。example.com はリクエストの動作確認に使う例であり、ページサイズが小さいため継続的な帯域の評価には使えません。ダウンロードテストには、アクセス権のある安定した大容量ファイルのURLを使ってください。
socks5hは接続先のドメイン名の処理をプロキシ側に任せます。curlがローカルで先に名前解決する動作とは異なります。最終的にどのDNSが使われるかは、コアの設定によって変わります。- ここでの
time_connectは主にローカルのプロキシ入口への接続時間を示すもので、リモート側とのハンドシェイク全体にかかる時間ではありません。最初の1バイトを受信するまでの時間には、接続先の処理時間も含まれます。 - 明示的なプロキシ経由のリクエストは正常なのにブラウザーだけ遅い場合は、すぐにノードを変更せず、ブラウザー独自のプロキシ設定、拡張機能、セキュアDNSを確認してください。
- 切り分けのため、クライアントにあるグローバルプロキシルーティングを一時的に使って比較しても構いません。テスト後は元のルールに戻してください。「システムプロキシを設定」と「グローバルプロキシルーティング」は別の設定です。
通信方式・Mux・DNS：一度に変更するのは1項目だけ
通信方式はサーバー側の対応が必要です。WebSocket、gRPCなど、コアが対応する通信方式に、あらゆるネットワークで通用する速度順位はありません。リバースプロキシ、接続維持の方針、経路品質によって結果は変わります。サービス提供元が用意した有効な設定同士を比較し、1つのノードで通信方式だけを切り替えて速度を測らないでください。
| 設定項目 | 考えられる影響 | 確認方法 |
|---|---|---|
| Muxによる接続の多重化 | 複数回の接続確立にかかる負荷を減らせる一方、複数のリクエストが同じ下位接続のパケットロスの影響を受けることがあります | 使用中のコアとプロトコルが対応しているか確認し、無効と有効の両方で再テストします。同時接続数をいきなり増やすのは避けてください |
| DNSと名前解決の経路 | 名前解決のタイムアウトで初回表示が遅くなったり、返されるアドレスの違いでCDNへの経路が変わったりすることがあります | ノードを変えずに初回アクセスと再アクセスを比較し、名前解決のログも確認します |
| ルーティングルールの順序 | 先に一致したルールによって、接続先が直接接続や別のアウトバウンドに振り分けられることがあります | 接続先のドメイン名、IP条件、アウトバウンドのタグを確認し、ログで実際に適用されたルールを調べます |
| ローカル端末のリソース使用率 | コア、ほかのプログラム、セキュリティソフトの負荷が高いと、処理能力が制限されることがあります | ダウンロード中のCPUとネットワーク使用率を確認し、ほかの負荷を止めて再テストします |
Muxは帯域を合算する機能ではなく、1本の回線の容量を増やすものでもありません。まずMuxを無効にした状態で基準値を取り、多数の短いリクエストと大容量ファイル1つの2種類の負荷で比較します。プロトコル、通信方式、コアの組み合わせによって多重化に固有の制約があるため、古い設定をすべてのノードにそのまま流用しないでください。
DNSが直接影響するのは、主に名前解決と初回接続です。確立済みの大容量ファイルのダウンロードが、DNS変更だけで速くなるわけではありません。ただし、名前解決の結果が変われば、実際に接続するCDNのアドレスも変わる可能性があるため、DNSを完全に無視することもできません。DNSサーバーを変更する前に現在の設定を記録し、プロキシがまだ確立していないと利用できないDNSになっていないかも確認してください。依存関係によるタイムアウトを避けられます。
ログにエラーが出る場合：まず失敗を解消してから速度を評価
以下はログに表示されることがあるエラーの一部です。ログの完全な先頭部分はシステムやコアによって異なります。エラーは原因の絞り込みに役立ちますが、それだけで特定の原因を証明できるとは限りません。発生時刻と使用中のノードを記録してください。ログを共有する前に、サブスクリプションURL、認証情報、個人のネットワーク情報を削除してください。
connection refused
原因：接続先のポートが接続を拒否しています。ローカルのコアが待ち受けていない場合も、リモートのサービスが起動していない場合もあります。対処法：まずエラーに表示されたアドレスを確認します。ローカルアドレスの場合は待ち受けポートとコアの状態を、リモートアドレスの場合はノードのポートとサービスの状態を確認してください。
i/o timeout
原因：読み書きのいずれかの段階で待ち時間を超過しています。名前解決、回線、接続先からの応答が関係している可能性があります。対処法：前後のログからタイムアウトが発生した段階を確認し、同じノードでネットワークを変える、同じネットワークでノードを変えるといった方法で比較します。タイムアウト時間を延ばしても速度改善にはなりません。
address already in use
原因：ローカルの待ち受けポートが別のプロセスに使用されています。対処法：重複して起動したインスタンスを終了するか、ポートを使用しているプログラムを確認したうえで待ち受けポートを変更します。明示的なプロキシを使うアプリのポート設定も合わせて変更してください。
x509: certificate has expired or is not yet valid
原因：システム時刻が正しくないか、サーバー証明書の有効期間が切れています。対処法：まず端末の日付とタイムゾーンを同期します。時刻が正しくてもエラーが続く場合は、証明書の検証を無効にせず、サービス提供元に証明書の状態を確認してください。
よくある質問とトラブルシューティングのまとめ
遅延が小さいのに動画が途切れるのはなぜ？
短いリクエストが成功しても、継続的な通信速度が安定しているとは限りません。画質を固定して再生バッファーを確認し、同じノードで別の接続先もテストしてください。動画サービス1つだけが遅い場合は、ノードの出口からそのサービスまでの経路を重点的に比較します。遅延だけでノードを順位付けしないでください。
Muxを有効にしたら遅くなりました。同時接続数をさらに増やすべき？
まずMuxを無効にして基準の状態に戻し、同じテスト先で3回測定します。無効にしたほうが安定して速い場合は、そのまま無効にし、現在のコアとサーバーの組み合わせが多重化に対応しているか確認してください。同時接続数を増やせば必ず改善するわけではありません。
Androidで画面をロックすると遅くなり、画面を点灯すると戻る場合は？
まずv2rayNGまたはv2flyNGの接続が維持されているか確認し、次にシステムのアプリ情報にあるバッテリー管理でバックグラウンド動作を許可します。同じノードを使い、画面点灯時とロック時の両方でテストしてください。バックグラウンド時だけ問題が起きる場合は、省電力制限やほかのVPNサービスとの競合を優先して確認します。
サブスクリプションを更新すれば速度は改善する？
サブスクリプションを更新すると、サービス提供元が変更したアドレスや設定を取得できますが、帯域が直接増えるわけではありません。更新後は現在のアクティブノードが変わったか確認し、同じ条件で比較します。ノードが置き換わっていた場合は、新しいテスト対象として記録してください。
最後に、使用したノード、ネットワークの種類、テスト先、時間帯、設定変更前後の結果を簡潔に記録しましょう。1回だけ良い測定値が出るより、安定して再現できる差のほうが役立ちます。ノード間で差がなければ回線を確認し、回線間で差がなければローカルの接続、ルーティング、名前解決を調べます。設定を1項目変更するたびに再テストし、改善しなければ元に戻してください。