接続はできるものの、Webページの表示開始が遅い、ダウンロード速度が出ない、通信が途中で切れるといった場合に役立ちます。テスト先とプロキシ経路を固定してから、ノード・接続ネットワーク・ローカル設定を比較しましょう。テストの繰り返し、接続ログ、条件を一つずつ変えた比較を通じて、ノード・ネットワークの変更が必要か、DNS・ルーティング・バックグラウンド制限の見直しが必要かを判断できます。
表示開始の遅さ・転送速度の低さ・接続切れを切り分ける
「遅延は小さいのにダウンロードが遅い」という状況は矛盾ではありません。ノード一覧の遅延テストは、TCP接続の確立だけを確認する場合も、指定URLへのアクセスを測る場合もあり、テスト機能によって異なります。継続的なダウンロード速度や、あらゆるWebサイトへの接続品質を示すものではありません。まず症状を具体的に整理し、原因をすべてノードのせいにしないようにしましょう。
リクエストは上記の各段階を経由します。ブラウザーが長時間読み込み中になってから表示を始める場合は、名前解決・接続確立・ハンドシェイクを確認します。ダウンロード開始後も速度が低い場合は、帯域幅・混雑・パケットロスを確認しましょう。画面を消した後に切断される場合は、まずモバイル端末のバックグラウンド動作条件を確認します。ノード、DNS、プロキシモードを同時に変更すると、改善してもどの変更が効いたのか分からなくなります。
| 症状 | 優先して確認する項目 | 比較方法 |
|---|---|---|
| 初回の表示は遅いが、再読み込みは速い | DNS、初回接続、TLSハンドシェイク | 初回と2回目以降の所要時間を記録し、名前解決とハンドシェイクのログを確認する |
| 大容量ファイルのダウンロードが遅い | ノードの出口、回線の実効速度、接続先の速度制限 | ノードを固定して接続先を変える、接続先を固定してノードを変える |
| 夜は遅いが、昼は問題ない | 共有出口の混雑、または通信事業者のピーク時混雑 | 設定を変えずに時間帯を変えて繰り返し測定する |
| 特定のアプリだけ遅い | アプリごとの振り分け設定、アプリ独自のプロキシ、接続先サービス | そのアプリの接続が実際にどのアウトバウンドへ振り分けられたか確認する |
| 画面を消すと接続が切れる | 省電力設定、プロセスの維持、ネットワークの切り替わり | 画面点灯中と消灯中の状態をそれぞれ確認する |
基準を作る：接続先とテスト条件を固定する
システム更新、クラウドストレージの同期など、大容量通信を行うタスクをいったん停止します。デスクトップではできるだけ有線接続を使い、モバイル端末は同じ場所でテストしてください。安定して表示できるWebページで初回表示を確認し、速度測定が許可されている同じダウンロード用リソースで継続速度を測ります。以下は推奨するテスト方法であり、本サイトの実測値やクライアントの初期設定値ではありません。
-
設定を記録する
v2rayNの「ヘルプ」→「バージョン情報」でクライアントのバージョンを記録します。使用中のコア名とバージョン、ノード名、ルーティングモード、TUNの有効・無効も記録してください。メニューの場所は画面のバージョンによって異なる場合があるため、実際の画面で確認します。
-
受け入れポートを確認する
「設定」→「パラメータ設定」を開き、ローカルのSOCKSまたは混合プロキシの待ち受けポートを確認します。以下のコマンド例では
10808を使用しています。現在のポートでSOCKS接続を受け付けている場合に限り、そのまま使ってください。そうでない場合は実際のポートに置き換えます。 -
経路を固定する
メイン画面下部で「システムプロキシ」と「ルーティング」の選択状態を確認します。ブラウザーでテストする場合はシステムプロキシが有効か確認してください。コマンドラインのテストでは、アプリがシステムプロキシを参照するかどうかに左右されないよう、プロキシを明示します。
-
記録を残す
各テストの時刻、接続ネットワーク、ノード、接続先、最初のデータを受信するまでの時間、平均速度を記録します。まずノードA、次にノードB、最後にノードAを再テストすると、接続先の一時的な変動による誤判定を減らせます。
単位の換算に注意してください。理論上、8 Mbps は約 1 MB/s です。実効速度はプロトコルのオーバーヘッド分だけ低くなります。通信事業者が表示するMbpsと、ダウンロード画面のMB/sをそのまま比較しないでください。また、容量の小さなWebページだけで回線の最大帯域幅を判断するのも避けましょう。
第1段階：ノードの出口と接続先との相性を確認する
ノードに接続できても、認証と通信経路が基本的に機能していることしか分かりません。共有出口の混雑、サーバー側のリソース不足、ノードから接続先までの相互接続品質によって、実際の通信が遅くなることがあります。まず出口や回線の異なるノードを比較しましょう。同じサービス提供元のノードでも、名前が異なるだけで出口を共有している場合があります。名前だけで独立したテストだと判断しないでください。
- 接続先を固定してノードを変更：ローカルネットワーク、接続先のリソース、テスト時間帯を固定し、利用可能な2つのノードを比較します。一方のノードだけ継続して遅い場合は、そのノードの出口、利用枠、サーバー負荷を優先して確認してください。
- ノードを固定して接続先を変更：Webページは正常でも特定のダウンロードサイトだけ遅い場合、サイト側の速度制限や、サイトとノードの出口間の相互接続が原因かもしれません。クライアントの異常とは限りません。
- 帯域幅と遅延を分けて考える：近隣地域のノードは応答が速くても、出口の帯域幅が大きいとは限りません。遠方のノードは遅延が大きくても、継続的な転送速度が安定している場合があります。
- 設定の整合性を確認：サーバーポート、トランスポート方式、TLS、
serverName、トランスポートパスが提供元の指定と一致しているか確認します。「速度向上」を目的に、これらの項目をむやみに変更しないでください。
v2rayNはデスクトップクライアントで、実際の接続処理は選択したコアが担当します。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。互換性を調べる際は、現在のコアが設定項目に対応しているか確認してください。同じサーバー設定が両方のコアに確実に対応している場合に限り、コアを切り替えた比較に意味があります。コアの切り替えを万能な速度改善策と考えないでください。
第2段階：ローカルの接続環境と通信回線を切り分ける
同じノードでも自宅の固定回線では遅く、モバイルのテザリングでは速い場合、接続ネットワークからノードまでの区間に問題がある可能性があります。ただし、すぐに通信事業者が原因だとは断定できません。テザリングと自宅のネットワークでは、Wi-Fi環境、出口、通信経路も同時に変わります。まず有線LANでWi-Fiの影響を除き、その後、同じ端末で接続ネットワークを切り替えると、原因をより明確にできます。
| 変更する条件 | 確認された結果 | 次に行うこと |
|---|---|---|
| Wi-Fiから有線LANに変更 | 速度が改善し、変動も減った | Wi-Fiのチャンネル、電波強度、ルーターの負荷を確認する |
| 自宅の固定回線からテザリングに変更 | 同じノードで明らかに改善した | 時間帯を変えて比較し、通信経路の違いをネットワークまたはノードの提供元に伝える |
| 夜間から混雑していない時間帯に変更 | 複数の接続先で同時に改善した | ピーク時の混雑を優先して調べ、別の回線でも比較する |
| 接続先のリソースを変更 | 特定の接続先だけ継続して遅い | 接続先の制限、出口の地域、相互接続状況を確認する |
パケットロスがあるとTCPの再送が発生し、転送速度が低下します。遅延の揺れも操作感に影響します。ただし、pingが通らなくても、プロキシのポートに接続できないとは限りません。途中の機器がICMPを制限している場合があります。経路トレースで特定のホップから応答がなくても、そのホップが実際の通信を破棄しているとは断定できません。最終接続先への到達性、アプリの動作、繰り返しのテスト結果を合わせて判断してください。
第3段階：DNS・ルーティング・ローカルリソースを確認する
システムプロキシは、対応アプリからローカルクライアントへ通信を渡す設定です。ルーティングルールは、通信が取り込まれた後にどのアウトバウンドを使うかを選びます。両者は別の層です。ルーティングをグローバルにしても、システムプロキシを無視するアプリを強制的に接続させることはできません。テストでは「どのインバウンドに入ったか」と「どのアウトバウンドが選ばれたか」の両方を確認してください。
- DNS：初回アクセスが遅い場合は、ログで名前解決のタイムアウトが繰り返されていないか確認します。v2rayNの「設定」→「DNS設定」で現在の設定を確認し、ノードのドメイン名と接続先のドメイン名の解決を分けて考えましょう。システムDNSを変更しただけで、コア側の名前解決も変わったと判断しないでください。
- ルーティング：カスタムルールの順序と、ログに記録されたアウトバウンドのタグを確認します。接続先が誤って直接接続になっている場合、プロキシノードを変更しても改善しません。本来直接接続できるローカルサービスが遠方のノード経由になっていると、待ち時間が増える場合もあります。
- TUN：まずアプリでプロキシを明示して基本経路を確認し、その後TUNを個別にテストします。デフォルトルートや仮想ネットワークアダプターを奪い合うネットワークツールを複数同時に実行しないでください。
- リソース：タスクマネージャーでコアのプロセスが使用するCPU、メモリ、ネットワークの転送量を確認します。速度低下中にCPUのボトルネックが継続している場合に限り、端末の性能や設定による負荷を検討する根拠になります。
- ログ：原因を特定する間だけログレベルを一時的に上げ、作業後は通常のレベルに戻します。デバッグログを大量に出し続けると、ディスクへの書き込みが増えるうえ、重要な異常を見つけにくくなります。
以下のWindowsコマンドは、接続と最初のデータ受信までの時間を比較するためのもので、最大ダウンロード速度の測定には使いません。例では本サイトのトップページにSOCKSプロキシ経由でアクセスし、接続先のドメイン名をプロキシ側で解決します。ブラウザーのローカルDNS経路は検証できません。127.0.0.1:10808でSOCKS接続を受け付けていることを確認してください。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://v2rayhost.com/macOSまたはLinuxでcurlを使う場合は、NULを/dev/nullに置き換えてください。各時間はリクエスト開始からの累積値なので、単純に足し合わせることはできません。time_connectが主に示すのはローカルプロキシへの接続時間であり、ノードの遅延ではありません。同じコマンド、同じ接続先で複数回テストし、結果を比較してください。決まった「合格秒数」を当てはめる必要はありません。
ログから接続失敗と待ち時間の原因を探る
速度低下にはリトライが絡むことがよくあります。最初のリクエストが数回失敗してから成功すると、ユーザーには「読み込みが遅い」と見えます。ログの表記はコアやOSによって異なりますが、以下に代表的なメッセージを挙げます。エラーがローカルのインバウンド、ノードのアドレス、最終接続先のどれに対応するかを確認してから、修正箇所を判断してください。
エラー：connection refused
原因：接続先のポートに拒否されています。接続先がローカルアドレスの場合、コアが起動していない、またはポートの指定が誤っている可能性があります。対処：エラーに表示されたアドレスとポートを確認し、まずローカルで待ち受けているか調べます。ノードを指している場合は、サーバーポートとサービスの稼働状態を確認してください。
エラー：i/o timeout
原因：ネットワークの読み込みまたは書き込みがタイムアウトしています。このメッセージだけでは、回線の停滞、サーバーの無応答、名前解決の待ち時間のどれかを特定できません。対処：前後のログと発生時刻を保存し、ノードまたはネットワークを一つずつ変更してテストします。どの段階でタイムアウトしたかを確認してください。
エラー：TLS handshake timeout
原因：制限時間内にTLSハンドシェイクが完了しませんでした。通信経路の品質、サーバーからの応答、接続先に関係している可能性があります。対処：まずどの区間のTLS接続で発生したかを特定し、サーバーポートとserverNameを確認します。証明書の検証を無効にして、原因調査の代わりにしないでください。
ログを共有する前に、サブスクリプションURL、ユーザー識別情報、認証情報などの機密パラメーターを削除してください。問い合わせには、発生時刻、クライアントとコアのバージョン、ネットワークの種類、エラー周辺のログ、比較テストの結果を添えると、速度低下のスクリーンショットだけを送るより原因を特定しやすくなります。
よくある質問と確認のまとめ
遅延が数十ミリ秒しかないのに、動画が止まるのはなぜですか？
遅延テストでは、動画の分割データを継続して受信できる速度までは分かりません。まず画質を固定し、再生バッファが減り続けていないか確認します。次に同じノードで別の接続先を試し、同じ接続先でノードを切り替えて、ノードの出口と動画配信サービスまでの経路を切り分けてください。
グローバルモードに変えたら速くなりました。ルール設定に問題がありますか？
まず接続先に適用されたルールとアウトバウンドを確認します。グローバルモードにしたことで、これまで直接接続していた接続先がプロキシ経由になった可能性があります。関連する名前解決の経路が変わった場合もあります。誤って適用されたルールを見つけて個別に修正するほうが、すべての通信経路を長期的に変えるより管理しやすくなります。
v2rayNGが画面消灯後に遅くなり、画面を点けると戻ります。どうすればよいですか？
Androidの「設定」→「アプリ」→「v2rayNG」→「バッテリー」を開き、端末で選べる項目に従ってバックグラウンド動作を許可します。バックグラウンドデータの権限も確認してください。次にv2rayNGの「設定」→「アプリごとのプロキシ」で、対象アプリのリストモードを確認します。バッテリー設定の名称は端末によって異なる場合があります。
サブスクリプションを更新すると、速度は自動的に改善しますか？
提供元がノードのアドレスやポート、利用可能な設定を変更した場合に限り、更新によって直接改善する可能性があります。更新前に現在利用できるノードの情報を保存してください。同じネットワークで複数のノードが遅い場合は、接続ネットワークとローカルの通信経路を引き続き確認し、原因調査の代わりにサブスクリプションの更新を繰り返さないでください。
原因の確認が終わったら、一時的な変更を元に戻します。不要なグローバルルーティングを解除し、ログレベルを戻し、テスト用ルールを削除して、安定して使える設定を保存してください。用語を確認したい場合は使い方ガイドのプロキシ、ルーティング、DNSの説明を参照してください。設定について詳しく知りたい場合はよくある質問をご覧ください。
- 特定のノードだけ遅い：ノードの出口、利用枠、接続先までの相互接続を優先して確認します。
- 接続ネットワークを変えると改善する：ローカルの無線環境、接続ネットワークの出口、通信回線を優先して確認します。
- プロキシを明示すると速いが、ブラウザーでは遅い：システムプロキシ、ブラウザーの設定、名前解決の経路を優先して確認します。
- 画面点灯中は正常だが、バックグラウンドで切断される：省電力制限、プロセスの状態、ネットワークの切り替わりを優先して確認します。