サブスクリプションの追加と接続はできているものの、Webページの表示が遅い、ダウンロード速度が出ない、夜間に頻繁に途切れるといった場合に役立つ内容です。Windows版v2rayNを例に、まずテスト条件をそろえ、ノード、ネットワーク経路、ローカルプロキシを順に確認します。読み終えると、再現性のある記録をもとに、ノードを変えるべきか、接続ネットワークを変えるべきか、ローカル設定を見直すべきか判断できます。
遅延・通信速度・接続失敗を切り分ける
「速度が遅い」は単一の指標ではありません。Webページを開いてから長く表示されない場合、名前解決、接続確立、または接続先からの応答に時間がかかっている可能性があります。大容量ファイルのダウンロードが最初は速く、その後遅くなるなら、継続的な転送速度の問題が考えられます。数分おきに切断される場合は、パケットロスやネットワークの切り替わり、コアのログを確認しましょう。まず症状を具体的に記録すれば、1回の遅延テストですべての問題を説明しようとせずに済みます。
| 症状 | 優先して確認する項目 | これだけでは判断できないこと |
|---|---|---|
| Webページの初回表示が遅い | 名前解決、接続確立、最初の1バイトを受信するまでの時間 | ノードの帯域幅が低いとは限らない |
| ダウンロードが常に遅い | 継続的なダウンロード速度、接続先の速度制限、出口側の負荷 | ローカルプロキシのポート異常とは限らない |
| 夜間に特に遅くなる | 同じ時間帯に複数のノード・ネットワークで比較 | 時間帯だけでサーバーの過剰収容とは断定できない |
| 遅延テストがタイムアウトする | テスト先への接続可否、ノード設定、ログのエラー | すべての接続先Webサイトが使えないとは限らない |
v2rayNのTCP接続遅延は、主にノードのアドレスとポートへの接続状況を示します。「実接続遅延」はプロキシ経由でテスト先にアクセスするため、実際のリクエストに近い測定になりますが、大容量ファイルのダウンロード速度と同じではありません。どちらの結果も、動画サイトやダウンロードサイトでの実際の使い勝手を保証するものではありません。実接続テストに問題がなく、特定のWebサイトだけ遅い場合は、プロトコルを次々に変更するのではなく、接続先を変えて比較しましょう。
再現可能なテスト条件を整える
変更する条件は毎回1つだけにします。クラウドストレージの同期、システム更新、ほかのダウンロードを一時停止し、テストに使わないプロキシツールを終了します。同じブラウザー、同じ接続先、同じネットワーク接続方法を使ってください。以下は一般的なv2rayNのデスクトップ画面を例にしています。バージョンによってメニュー名が多少異なる場合があるため、実際の画面に表示されている項目を確認してください。
-
現在の設定を記録する
「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートを記録します。メイン画面下部に表示されるシステムプロキシの状態、ルーティングモード、TUNの状態も控えておきます。使用中のノード名、クライアントのバージョン、コアのバージョンも記録し、以降の比較では同じ条件を保ちます。
-
テストするノードを固定する
サーバー一覧でノードを選択し、右クリックして「アクティブサーバーに設定」を選びます。アクティブ表示が切り替わったことを確認してから、選択した項目で「サーバーの実接続遅延をテスト」を実行します。一覧の選択色だけで、使用中のノードを判断しないでください。
-
テストを3回繰り返す
同じノードで約10秒間隔で3回テストします。成功回数と遅延の中央値を記録し、その後、同じWebページにアクセスします。ダウンロードを測定する場合は、テストが許可されている固定ファイルを使い、約30秒間の安定した速度を確認してください。最初の数秒に出たピーク値だけで判断しないようにします。
-
比較用の記録を残す
別のノードに切り替え、同じ手順を繰り返します。時刻、接続ネットワーク、接続先、遅延、速度、エラーログを記録してください。ノードとネットワークを同時に変えると、どちらの変更で差が出たのか分からなくなります。
「20:30／自宅の固定回線／ノードA／3回成功／中央値180 ms／安定速度2.0 MB/s」のような形式で記録できます。これは記入例であり、本サイトでの実測値や合格基準ではありません。同じ環境での相対的な変化と、繰り返し測定した際に近い結果が得られるかどうかが重要です。
第1段階：ノードの負荷と接続先への出口
同じサブスクリプション内のノードでも、入口、出口、上流の帯域を共有している場合があります。名前が似たノードを何度か切り替えても、実際のボトルネックが変わるとは限りません。サービス提供者が回線や出口を明確に分けているノードを2つ選んで比較しましょう。地域名だけから物理的な場所、経路品質、利用可能な帯域を推測しないでください。
- 1つのノードだけ遅い：接続先を変えず、ほかのノードと比較します。再現性のある差が出るなら、そのノードまたは経由する経路に原因がある可能性が高まります。ただし、クライアント側の結果だけでは、CPU負荷、速度制限、共有帯域のどれが原因かまでは特定できません。
- 同じノードで特定のWebサイトだけ遅い：別の接続先Webサイトでも試します。接続先の地域別振り分け、出口IPアドレスに応じた配信サーバー、サイト側の速度制限などによって差が出ることがあります。
- すべてのノードが遅い：まずローカルネットワークにも問題がないか確認し、その後、接続ネットワークを変えてみます。複数のノードが同じ回線を共有していることもあるため、すべて遅いからといってリモート側の要因を除外はできません。
- 混雑する時間帯だけ遅い：同じノードを混雑していない時間帯にもテストし、少なくとも2つの時間帯の記録を残してから、具体的な時刻と症状をサービス提供者に伝えます。
VMessとVLESSはプロキシのプロトコル名であり、速度のランクを示すものではありません。プロトコルを変えると、サーバー、トランスポート方式、回線も同時に変わることが多く、結果をプロトコルだけの違いとして判断できません。ノードのアドレス、ポート、トランスポート、安全性に関する設定はサーバー側と一致させる必要があります。速度測定のためだけに、設定項目を適当に変更しないでください。
第2段階：ローカルネットワークとネットワーク間の経路
プロキシ経由のリクエストはいくつもの区間を通ります。どこか1か所で混雑やパケットロス、応答の遅れが起きると、アプリの動作が重く感じられることがあります。まずリクエストがどこを通るかを把握し、そのうえで比較方法を選びましょう。以下は経路を示す概念図であり、すべてのトランスポートで接続確立の順序が完全に同じという意味ではありません。
自宅のWi-Fiを使っている場合は、有線接続に切り替えるか、ルーターの近くでテストしてみてください。LAN内の通信や、プロキシを使わない通常のWeb閲覧も遅いなら、まずWi-Fiの干渉、ルーターの負荷、回線の使用状況を確認します。直接接続のテストには、もともと直接アクセスできるWebサイトを選んでください。接続先が直接アクセスできないことを、ブロードバンド回線の障害と誤認しないようにしましょう。
| 変えずに保つ条件 | 変更する条件は1つだけ | 結果から判断できる範囲 |
|---|---|---|
| ノード、接続先Webサイト | 自宅の固定回線からスマートフォンのテザリングに変更 | 改善した場合、接続ネットワークまたはその先の経路に違いがあると分かりますが、特定の区間までは断定できません |
| 接続ネットワーク、接続先Webサイト | ノードAからノードBに変更 | 改善した場合、ノードまたはそのネットワーク経路に違いがあると分かりますが、サーバーの過負荷とは限りません |
| ノード、接続ネットワーク | 接続先Aから接続先Bに変更 | 1つのWebサイトだけ遅い場合は、接続先と出口の間の経路を引き続き確認します |
Windowsのpingやtracertは、HTTPシステムプロキシを有効にしても、通常は自動的にプロキシ経由になりません。ローカルからノードまでのネットワーク状況を調べる参考にはなりますが、プロキシの出口から接続先までの経路を直接示すものではありません。途中の区間がICMPに応答しなくても、機器側で応答を制限している可能性があります。その区間で実際の通信にパケットロスが起きているとは断定できません。
第3段階：システムプロキシ、ポート、ルーティング
システムプロキシはアプリが参照するプロキシ設定であり、すべてのプログラムを強制的にプロキシ経由にするものではありません。ブラウザー拡張機能、アプリ独自のプロキシ設定、直接接続の例外リストによって、実際の通信経路が変わることがあります。TUNは別の方式で通信を取り込みます。切り分けの際は、まずTUNを無効にしてシステムプロキシで基準となるテストを行います。TUNをテストする場合は、個別に有効化して再測定し、原因を混同しないようにしてください。
-
待ち受けポートを確認する
「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートとプロトコルを確認します。バージョンによっては10808が混合ポートとして使われ、古い設定ではHTTPポートに10809が指定されている場合があります。以下のコマンドが使えるのは、HTTPプロキシを提供する10808ポートの場合だけです。SOCKSにしか対応していないポートには、そのまま適用できません。
-
システムプロキシを設定し直す
メイン画面下部の「システムプロキシ」から「システムプロキシを自動設定」を選びます。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートが現在のクライアントを指しているか確認してください。ほかのツールが設定を繰り返し上書きしていないことも確認します。
-
ルーティングルールの適用先を確認する
メイン画面下部の「ルーティング」で選択中の項目と、コアのログに表示されるインバウンド、接続先アドレス、アウトバウンドのタグを確認します。表示される内容はログレベルによって異なります。接続先が直接接続に振り分けられている場合は、該当するルールを修正するか、現在の設定で利用できるグローバルプロキシモードに一時的に切り替えて再テストします。テスト後は元のルーティング設定に戻してください。
-
プロキシを明示的に指定する
以下のコマンドでローカルHTTPプロキシを直接指定すると、ブラウザーがシステムプロキシを参照しているかどうかの影響を避けてテストできます。コマンドでは正常でブラウザーだけ異常がある場合は、すぐにノードを変更するのではなく、ブラウザー拡張機能、独自のプロキシ設定、キャッシュを確認しましょう。
netstat -ano | findstr ":10808"
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://5v2ray.com/netstatの結果は、ローカルアドレス欄と待ち受け状態を確認してください。「10808」と表示されたからといって、ポートが正常とは限りません。curl.exeの例はWindowsのターミナル向けで、測定するのは小さなページリクエストであり、帯域幅ではありません。環境変数NO_PROXYに接続先ドメインが含まれていると、プロキシを経由せずにリクエストが送られることもあるため、事前に確認してください。
ログにエラーがある場合：速度測定の前に接続を復旧する
接続失敗と転送速度不足は、分けて対処する必要があります。ログ画面を開いたまま問題を1回再現し、同じ時刻の前後に出たエラーを一連のログとして確認してください。以下はよくあるエラーの一部です。前後の文脈やコアのバージョンによって全文は異なるため、1つの単語だけを根拠にクライアントを再インストールしないでください。
エラー：connectex: No connection could be made because the target machine actively refused it.
原因と対処：接続先のポートが接続を拒否しています。ログの接続先が127.0.0.1:10808の場合は、まずコアが動作しているか、待ち受けプロトコルとポートが正しいかを確認します。接続先がリモートノードの場合は、ノードのアドレスとポート、サーバーの稼働状況を確認してください。
エラー：context deadline exceeded
原因と対処：処理が制限時間を超えています。名前解決、接続、リクエストのいずれの段階でも発生する可能性があります。前後のログで接続先アドレスを確認し、同じノードでネットワークを変える、または同じネットワークでノードを変える方法で範囲を絞り込みましょう。タイムアウト時間を延ばすだけで済ませないでください。
エラー：lookup …: no such host
原因と対処：省略記号の部分にはログに記録された実際のドメイン名が入ります。ドメイン名を解決できていません。エラーの対象がノードのドメイン名か接続先のドメイン名かを確認し、綴りと現在のDNS設定を見直します。ノードのドメイン名を解決できない場合は、まずノードのアドレスを解決できる状態に戻してから、プロキシ経由のアクセスをテストしてください。
エラー：tls: failed to verify certificate
原因と対処：TLS証明書の検証に失敗しています。システムの日付、時刻、タイムゾーンと、ノードで指定されているサーバー名および証明書の設定を確認してください。速度向上や通常の対処として、証明書検証を無効にしないでください。
DNSの変更で影響を受けるのは、関連する名前解決の経路だけです。ノードの帯域不足を解決することはできません。ブラウザーのセキュアDNS、システムDNS、コアのDNSがそれぞれ別に動作している場合もあります。名前解決の設定は一度に1つだけ変更し、該当するアプリを再起動してからテストしてください。システムDNS、ルーティングルール、ノードを同時に変更すると、改善しても原因が分からなくなります。
よくある質問と、切り分けを終える目安
遅延が80 msなのに、ダウンロードが遅いのはなぜですか？
遅延が小さいことから分かるのは、短いリクエストや接続にかかる時間が短いということだけです。同じノードで、ダウンロードが許可されている接続先を2つ試し、約30秒間の安定速度を確認してください。接続先の片方だけ遅い場合は、そのサイトの速度制限や、出口からサイトまでの経路を優先して確認します。すぐにローカルポートを変更する必要はありません。
夜だけ遅くなります。どの設定を変えればよいですか？
まずノードと接続先を固定し、日中と夜間にそれぞれ3回ずつ記録します。さらに夜間にテザリングでもテストしてください。テザリングで明らかに改善するなら、自宅の固定回線とネットワーク間の経路を引き続き確認します。別のネットワークでも同じノードが遅い場合は、記録をサービス提供者に共有してください。先に同時接続数やバッファーの設定を変更しないでください。
TUNを有効にすると速くなりました。システムプロキシに問題がありますか？
必ずしもそうとは限りません。2つのモードでは、対象となるアプリ、DNSの経路、適用されるルールが異なる場合があります。まずプロキシを明示するコマンドとブラウザーで結果を比較し、ブラウザーがシステムプロキシを参照しているか、両方のモードで同じノードとアウトバウンドルールを使っているか確認してください。
Androidでも10808ポートをそのまま使えばよいですか？
デスクトップの設定をそのまま流用しないでください。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。Androidではノードを固定して、Wi-Fiとモバイルネットワークでそれぞれテストし、アプリのVPN接続状態、アプリごとの設定、ログを確認してください。ローカルプロキシに手動で接続する場合に限り、アプリに実際に表示されているポートを設定します。
「同じノード、同じ接続先、同じ時間帯」の条件で、2種類の接続ネットワーク間の差を再現できるようになったら、ローカル設定を手当たり次第に変更し続ける必要はありません。プロキシを明示した場合とブラウザーの結果が一致し、接続エラーもログにないのに複数のダウンロード先で遅さが続く場合は、クライアントを何度も再インストールするのではなく、ノードと回線に焦点を移しましょう。
- ローカル設定の問題：修正後は元のルーティングに戻し、一時的なテストモードを終了して、普段使うアプリで再確認します。
- ノードまたは回線の問題：クライアントとコアのバージョン、テスト時刻、接続ネットワーク、比較結果、機密情報を削除した関連ログを添えて問い合わせます。
- 特定のWebサイトだけ異常：接続先のドメイン名と失敗した段階を記録し、出口を変えて比較します。サブスクリプション全体の設定は変更しないでください。
- ログを共有する場合：サブスクリプションのリンク、認証情報、個人のアドレス情報を削除し、問題の特定に必要なエラーと時刻だけを残してください。