まずテスト条件をそろえてから、ノード・ネットワーク・アプリを比較します。「接続はできるがダウンロードが遅い」「遅延は低いのに頻繁に止まる」「夜になると遅くなる」といった症状に役立つ手順です。遅延、継続的なダウンロード速度、ログを順に記録すれば、ノードを切り替えるべきか、回線の提供元に問い合わせるべきか、Windowsのプロキシ設定を見直すべきかを絞り込めます。
高遅延・低スループット・接続失敗を切り分ける
v2rayNを開き、ほかのノードの一括速度テストを停止してから、現在使用中のサーバーを選んでテストします。一般的なバージョンでは、サーバー一覧を右クリックすると「サーバーへの実際の接続遅延をテスト」と「サーバー速度をテスト」があります。バージョンによってショートカットキーが表示されたり、項目名が多少異なったりします。実接続遅延はリクエストが完了するかを確認し、速度テストはテスト用リソースの転送性能を測定します。両者は別の指標です。
V2Rayはプロキシ技術の体系を指し、v2rayNはサーバー設定の管理、コアの起動、プロキシ設定を行うデスクトップクライアントです。Webページの表示速度は、サーバーの負荷、入口までの経路、出口から接続先サイトまでの通信、ローカルアプリの影響も受けます。まず遅くなる箇所を確認し、最初からプロトコルを変更したり、何度も再インストールしたりしないようにしましょう。
| 確認できる症状 | 優先して確認する項目 | この時点では判断できないこと |
|---|---|---|
| ページの表示開始まで時間がかかるが、始まるとダウンロードは速い | DNS、接続確立、接続先サイトの応答 | 最初の画面が表示されるまでの時間だけで、帯域不足とは判断できない |
| 接続はできるが、大きなファイルのダウンロードが続けて遅い | ノード負荷、速度制限、回線の混雑 | 遅延が低いだけでは、ノードに問題がないとは判断できない |
| 特定のWebサイトやアプリだけ遅い | そのサイトへの経路、アプリのプロキシ設定、接続先への出口 | サブスクリプション全体が使えないとは判断できない |
| すべてのノードと直接接続が遅い | ローカルネットワーク、バックグラウンド通信、Wi-Fiの電波状況 | プロキシのプロトコルを最初に疑う必要はない |
テスト条件をそろえ、比較できる記録を取る
同じPC、同じダウンロード先、近い時間帯でテストします。クラウドストレージの同期、システムのダウンロード、ほかの速度テストを一時停止してください。まず有線LANを使うか、Wi-Fiの接続場所を変えずに測定します。ノードは一度に1つずつテストし、各項目を3回測定して中央値を記録します。さらに、少なくとも30秒間の継続速度を確認してください。速度テストは通信量を消費するため、データ量に上限がある場合は小規模な比較から始めましょう。
回線の公称速度はMbps、ダウンロードツールの速度表示はMB/sが一般的です。10進法で換算すると、100 Mbpsの理論値は約12.5 MB/sですが、実際にはプロトコルのオーバーヘッド分だけ低くなります。これは単位換算であり、ノードの実測値や速度の保証ではありません。比較するときは単位を明記し、8 MB/sを8 Mbpsと取り違えないようにしましょう。
-
テスト環境を記録する
v2rayNと使用中のコアのバージョン、ネットワークの接続方式、テスト日時、現在のルーティング設定を記録します。まずメイン画面のログで起動時の情報を確認してください。テスト中にクライアントとコアを同時にアップデートするのは避けましょう。
-
遅延をテストする
サーバー一覧からノードを1つ選び、右クリックして「サーバーへの実際の接続遅延をテスト」を実行します。3回連続でテストし、成功回数と結果を記録してください。1回のタイムアウトだけでノードが無効とは判断できません。
-
速度をテストする
同じノードを右クリックして「サーバー速度をテスト」を実行し、実際のダウンロードでも継続的な転送速度を確認します。内蔵テストの結果は測定先の影響を受けるため、すべてのWebサイトでの速度上限を示すものではありません。
-
比較結果を記録する
ノードA、ノードB、直接接続の順に結果を記録します。ダウンロード先、アプリ、ルーティング設定は変えず、一度に変更する項目は1つだけにしてください。どの変更が効果をもたらしたのか分からなくなるのを防げます。
第1段階：単一ノードと共通の入口の問題を切り分ける
まず同じサブスクリプション内から2～3個のノードを選んで比較します。名前の違いだけで判断せず、接続入口や地域が実際に異なるノードを優先してください。サブスクリプションは設定を配布する仕組みであり、独立したネットワーク回線ではありません。複数のノードが同じ入口、サーバー、帯域プールを共有している場合があります。名前を変えても実際の経路が変わらなければ、測定結果もほとんど変わらない可能性があります。
- ノードAだけ遅い：Bに切り替えて同じダウンロードを再度行います。速度が継続的に回復するなら、Aの負荷や速度制限、またはAの出口から接続先サイトまでの経路に原因があると考えられます。
- どのノードもほぼ同じ速度上限になる：サブスクリプションのプランに速度制限がないか確認し、ローカル回線の帯域やバックグラウンド通信も確認します。速度上限が近いことは手がかりにはなりますが、それだけで提供元による速度制限とは断定できません。
- 速度テストは正常なのに、実際のWebサイトが遅い：別の接続先サイトでも確認します。サイトによって異なるコンテンツ配信ノードを使用する場合があるため、速度テスト用サーバーの結果が動画サイトやファイル配布サイトの速度を示すとは限りません。
- 遅延はときどき非常に低いのに、ダウンロードが頻繁にゼロになる：再送や通信切断、アプリによるリトライが発生していないか確認します。最低遅延のスクリーンショット1枚より、同じ時間帯のログを残すほうが役立ちます。
第2段階：時間帯とネットワークを比較して回線を特定する
ノードを変えていないのに、日中は正常で夜間になると継続的に遅くなる場合は、接続回線や中継経路を優先して確認しましょう。同じノードとリソースで、朝と夜にそれぞれ記録を取ります。次に、同じPCをスマートフォンのテザリングに切り替えてテストします。テザリングでは接続ネットワークが変わりますが、通信事業者だけが変わるとは限りません。そのため、結果は原因を絞り込む手がかりとして使い、特定区間の障害を直接証明するものとは考えないでください。
| 比較結果 | 考えられる原因 | 次に行うこと |
|---|---|---|
| 自宅回線では遅く、テザリングでは明らかに改善する | 自宅の接続環境、ルーター、または自宅回線から入口までの経路 | 有線LANに切り替えてバックグラウンド通信を確認し、別の入口と比較する |
| どちらの接続でも夜間だけ遅い | 共有ノード、中継回線、出口のピーク時負荷 | 独立した入口に切り替え、時間帯ごとの結果を添えて問い合わせる |
| どちらのネットワークでも、特定の接続先サイトだけ遅い | 出口から接続先サイトまでの経路、または接続先サイト自体 | 出口の地域を変え、別の接続先サイトとも比較する |
| 直接接続とプロキシ接続のどちらもダウンロード速度が落ちる | ローカル回線の帯域、Wi-Fiの干渉、接続回線の混雑 | プロキシのテストを続ける前に、ローカルネットワークの問題を除外する |
サーバーアドレスへの通常のPingで分かるのはICMPの応答だけです。サーバーによってはICMPを制限または無視する場合があります。また、中継ノードの先にある経路が見えないこともあります。PingがタイムアウトしてもWebサイトを正常に閲覧できることはあり、矛盾ではありません。反対に、Pingの遅延が低くても、その先の出口に十分な帯域があるとは限りません。途中のルーターが応答しないだけで、パケットロス障害が確定したと判断しないでください。
第3段階：アプリが実際にローカルプロキシを経由しているか確認する
まずv2rayNのステータスバーまたはトレイメニューにある「システムプロキシ」で、「システムプロキシを自動設定」が有効か確認します。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、アドレスとポートを確認してください。システムプロキシは、その設定に従うアプリがクライアントに接続する方法を決めます。一方、ルーティング設定はクライアントに入った通信の出口を決めます。別々の設定であり、コマンドラインツールがWindowsのシステムプロキシを参照するとは限りません。
v2rayNの「設定」→「パラメーター設定」を開き、ローカルリスニング関連の設定を確認します。以下のコマンドは、PCのSOCKSポートが10808の場合の例です。このポートでSOCKSまたは混合リスニングが有効だと確認できた場合のみ使用してください。実際のポートが異なる場合は、先に自分の環境に合わせて変更します。ポートを推測しても問題は解決しません。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/Windows PowerShellでcurl.exeを明示して実行すると、環境によって異なるコマンドエイリアスの影響を避けられます。socks5hを使うと、接続先のホスト名の名前解決をプロキシ側に任せます。ここでのexample.comはリクエスト経路の確認用であり、大容量ファイルの速度テスト先ではありません。time_connectが記録するのは主にローカルプロキシへの接続時間で、ノードへの往復遅延を示すものではありません。最初の1バイトを受信するまでの時間には、その後のハンドシェイクと接続先サイトの応答も含まれます。
- コマンドは成功するのに、ブラウザーが遅い：ブラウザーのプロキシ拡張機能を一時的に無効にし、ブラウザーを再起動してからシステムプロキシを確認します。拡張機能のルールとシステムプロキシで、同時に通信経路を書き換えないようにしてください。
- ローカルポートへの接続が拒否される：コアが起動しているか、リスニングポートが正しいかを確認し、ログにポートの競合が記録されていないか調べます。この段階ではリクエストがまだサーバーに届いていないため、サブスクリプションを切り替える必要はありません。
- TUNを有効にしたときだけ問題が起きる：まずTUNを無効にし、システムプロキシを使った状態を基準として確認します。基準状態で正常なら、TUNの権限、DNS、ルーティング設定を1つずつ確認してください。ネットワークを制御するプログラムを複数同時に実行しないようにしましょう。
- 特定のドメインが誤った出口を使う：現在のルーティングプリセットとカスタムルールの順序を確認します。必要であれば、プロキシ出口を明示するルールを一時的に使って検証し、終了後は通常のルーティング設定に戻してください。
ログを確認し、通信切断と設定ミスを見分ける
メイン画面のログから問題が発生した時刻を探し、症状を一度再現して前後の数行を確認します。以下は表示される可能性があるエラーの例です。接頭辞はコアやバージョンによって異なります。エラー1件から分かるのは失敗した段階までです。特にタイムアウトはネットワークやリモートサービスが原因の場合もあるため、すぐに「ノードの帯域不足」と決めつけないでください。
bind: Only one usage of each socket address
原因：ローカルアドレスとポートが別のプロセスに使用されており、現在のリスナーを起動できません。
対処法：重複して起動したクライアントを終了するか、「設定」→「パラメーター設定」でリスニングポートを変更します。コアを再起動した後、アプリ側のプロキシポートも合わせて確認してください。
dial tcp: lookup
原因：ログに表示されたホスト名の名前解決に失敗しています。ノードのドメインか接続先のドメインかは、同じ行にあるアドレスで確認します。
対処法：まずドメイン名の入力と現在のDNSへの接続を確認し、該当するDNSルーティングを調べます。ノードの設定と名前解決の設定を同時に変更しないでください。
i/o timeout
原因：ネットワークの読み書きがタイムアウトしました。ローカルの接続回線、サーバー、接続先サイトの応答などが関係している可能性があります。
対処法：エラーに記載されたアドレスを確認し、別のノードと別の接続ネットワークで再テストします。同じ時間帯にだけ集中して発生するかも記録してください。
tls: failed to verify certificate
原因：TLS証明書の検証に失敗しています。システム時刻、証明書チェーン、設定に記載されたサーバー名が関係している可能性があります。
対処法：Windowsの日付と時刻を正しく設定し、提供元の設定を再確認します。速度の問題を解決するために証明書検証をスキップしないでください。
よくある質問と最終確認
遅延が50 msなのに、動画が止まるのはなぜ？
50 msは1回のリクエストに対する応答時間であり、継続的な帯域を示すものではありません。まず30秒間のダウンロード速度を確認し、同じ動画の別画質や別の出口と比較してください。その動画サイトだけで問題が起きる場合は、さらに遅延を下げようとするのではなく、サイトへのルーティングや出口を優先して確認しましょう。
サブスクリプションを更新すると速度は改善する？
提供元がノードのアドレス、ポート、設定を変更した場合は、更新によって改善する可能性があります。「サブスクリプショングループ」→「現在のサブスクリプションを更新（プロキシを使用しない）」から最新の設定を取得できます。ローカルからサブスクリプションの配布元にアクセスできない場合は、メニューのプロキシ経由で更新する項目を使ってください。更新してもプランの帯域は増えません。
DNSを変更すればダウンロード速度は上がる？
DNSが主に左右するのは名前解決の成否と返されるアドレスです。コンテンツ配信ノードの選択が変わることはありますが、回線の容量が直接増えるわけではありません。ページを開く最初の段階で遅く、ログに名前解決の失敗が記録されている場合はDNSを調べましょう。ダウンロードが安定して続くのに速度だけ遅い場合は、まずノードと経路を確認してください。
同時接続数や接続数をすべて増やすべき？
まず既定値に戻し、単一接続の基準速度を測定します。ダウンロードのスレッド数を増やすと、特定のタスクの合計速度が上がる場合がありますが、速度制限の対象になったり、リソース消費が増えたりすることもあります。混雑した回線の問題は解決できません。変更は一度に1つだけにし、変更前後の継続速度を記録してください。
最後に、結果を再現できる形で一文にまとめます。使用したノード、接続ネットワーク、時刻、接続先、継続速度、どの項目を切り替えたら改善したかを記録してください。特定のノードだけで再現する場合は、そのノードの管理元に共有します。すべてのノードで接続ネットワークに応じて変化する場合は、ローカル環境と接続回線を引き続き調べます。明示的なプロキシ経由のリクエストは正常なのに特定のアプリだけ異常な場合は、アプリのプロキシ設定とルーティング設定を見直します。ここまで確認すれば、サービスを変更すべきかを根拠をもって判断できます。