接続はできるものの、Webページの表示開始が遅い、動画が止まる、ダウンロード速度が落ちる場合に向けた内容です。まず測定対象と条件をそろえ、ノード・接続回線・クライアント設定を比較します。一度に変更するのは1項目だけ。読み終えるころには、ノードの出口混雑、経路品質の低下、端末でプロキシが適用されていない状態を切り分けられます。低遅延を高い通信速度と混同したり、比較記録を残さずプロトコルを何度も変更したりするのを防ぎます。
まず「遅い」の内容を整理：接続待ち・最初の応答・継続的なダウンロード
最初に設定を変更するのは避けましょう。Webページの表示まで時間がかかるものの、開いた後は快適なケースと、ダウンロード開始は速いのに速度がずっと低いケースでは、原因が異なります。前者では名前解決、プロキシのハンドシェイク、接続先の応答を確認します。後者では継続的な転送速度、混雑、端末負荷を比べます。特定のサイトだけ遅い場合は、接続先による速度制限、アカウントの利用条件、コンテンツ配信先の違いも確認してください。
| 症状 | 優先して確認する項目 | 最初に試すこと |
|---|---|---|
| ページが開くまで時間がかかる | 名前解決、ハンドシェイク、最初の応答までの時間 | 同じノードから同じURLへ繰り返しアクセスし、初回と2回目以降を比較する |
| ダウンロード速度がずっと低い | ノードの帯域、経路の混雑、接続先の速度制限 | ファイルと同時接続数を固定し、別のノードで再測定する |
| 速くなったり止まったりする | Wi-Fi干渉、パケットロス、バックグラウンドでの切断 | ノードを固定し、有線接続またはスマートフォンのテザリングに切り替える |
| 特定のアプリだけ遅い | プロキシの入口、アプリごとの設定、アプリ独自の通信方式 | そのアプリの通信が実際にプロキシのコアを経由しているか確認する |
単位をそろえて比較しましょう。回線速度はMbpsで表されることが多く、ダウンロードツールではMB/sと表示される場合があります。理論上、100 Mbpsは約12.5 MB/sですが、実際にはプロトコルのオーバーヘッド分だけ低くなります。遅延の単位はミリ秒で、待ち時間を表すものであり、1秒あたりの転送量を示すものではありません。ノード一覧で数十ミリ秒と表示されても、サーバーの出口に十分な帯域があるとは限りません。
比較条件をそろえる：同じ接続先・単一タスクで3回測定
テストが許可されている、十分なサイズのファイルを1つ選び、同期ストレージ、更新ダウンロード、ほかの速度測定を停止します。クライアントのバージョン、使用中のコアのバージョン、ノードの識別名、接続回線、測定時刻を記録してください。ノード名は手元での記録にのみ使用し、サブスクリプションURL、ユーザー識別情報、接続情報一式を公開の問い合わせに貼り付けないでください。
これらは測定手順の例であり、本サイトで実測した結果ではありません。次の4パターンを記録します。元のノードと元の回線、別のノードと元の回線、元のノードと別の回線、可能であれば別の端末。測定対象とダウンロードの同時接続数は統一してください。ブラウザーの単一接続ダウンロードと、複数スレッドの測定ツールの合計速度をそのまま比較しないでください。
- 同じ時間帯の中でノードAとノードBを交互に測定し、時間による負荷変動をノード間の差と取り違えないようにします。
- 同じ端末を別の回線に接続し、ノードAを測定します。スマートフォンのテザリングでは通信事業者と無線環境も変わるため、結果は接続経路全体を切り替えた場合のものです。
- 元の回線で端末を変更し、可能な限り同じノードとコア設定を使って、問題が端末についてくるか確認します。
- 夜間は遅く昼間は正常な場合も、時間帯を変えて同じ手順で測定します。1回の結果だけでサーバーの速度制限と判断しないでください。
第1段階：ノード負荷と出口の速度制限
ローカル回線を固定したまま、まずノードを切り替えます。プロトコルをすぐ変更する必要はありません。同じ時間帯に複数の接続先でノードAの速度が低く、ノードBでは改善するなら、Aに対応するサーバー、出口、または経路の影響が考えられます。クライアントからサーバーの実際のCPU使用率、共有帯域、ユーザーごとの速度制限は通常確認できません。「ノード負荷が高い」という判断は検証が必要で、測定結果から直接分かるものではありません。
- 出口の異なるノードを比較：同じ地域のノードでも、サーバーや上流回線を共有している場合があります。共通のボトルネックを避けるため、出口が異なると分かっているノードを優先してください。
- 接続先を変えて比較：同じノードから異なる2つのサービスに接続して両方遅い場合は、ノードや経路を確認する必要があります。1つの接続先だけ遅い場合は、接続先側の制限も考慮してください。
- 利用量とプランを確認：サービス提供元のアカウントページで、データ容量、利用期限、速度制限の条件を確認します。クライアントに接続済みと表示されていても、アカウントの速度制限が適用されていないとは限りません。
- 単一接続と複数接続を比較：複数接続で合計速度が大きく上がっても、同時接続数によって結果が変わったことしか分かりません。単一接続の制限、往復遅延、パケットロスが関係している可能性もあります。
VMessとVLESSはプロキシプロトコルであり、帯域のランクを表すものではありません。プロトコルの切り替えと同時にサーバー、通信方式、TLS設定が変わることが多いため、速度差のすべてをプロトコルの違いに結びつけることはできません。ノードで特定の通信方式やセキュリティ設定が必要な場合は、サーバー側の設定に従ってください。測定のために証明書検証を無効にしたり、通信方式の項目を変更したりしないでください。
結論：ノードを切り替え、ローカル設定は維持する
同じ回線、同じ接続先で別のノードを3回連続して測定し、速度が正常な水準に戻るなら、まず使えるノードを確保して比較記録を添えて問い合わせましょう。この場合、DNS、ルーティング、システムのネットワーク設定を同時に変更する必要はありません。
第2段階：接続回線・パケットロス・ネットワーク間の経路
同じノードで回線を変えると明らかに改善する場合、接続回線またはノードまでの経路が関係しています。ただし、家庭内Wi-Fiの干渉、ブロードバンド回線の上り帯域の圧迫、通信事業者間の接続混雑のどれかは、まだ特定できません。まず有線接続にするか、ルーターの近くで電波が安定したWi-Fiを使い、アップロードのバックアップを一時停止して再測定します。上り帯域が埋まると通信待ちが発生し、Web閲覧とダウンロードの両方が遅くなることがあります。
Windows PowerShellでは、サーバーのポートにTCP接続できるか確認できます。以下はコマンドの構造例です。example.comは例示用のドメイン名なので、実際のノードのサーバーアドレスに置き換えてください。443もノードで使用している実際のポートに置き換えます。TLSでよく使われるポートを、すべてのノード共通の固定ポートとして扱わないでください。
Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel DetailedTcpTestSucceededがTrueでも、今回のTCP接続に成功したという意味に限られます。プロキシ認証、TLS、通信経路、接続先へのアクセスが成功したことを示すものではありません。このコマンドは端末からサーバーのポートを直接確認するため、UDPだけを使用するサービスの判断にも適していません。CDN経由で接続するドメインでは、エッジノードまでの接続結果だけを反映している場合もあります。
- ポート接続が断続的に失敗する：まず実際のアドレスとポート、端末のファイアウォール通知を確認してから、別の回線で比較してください。すぐにサーバー障害と決めつけないでください。
- pingはタイムアウトするがプロキシは正常：サーバーや中継機器がICMPに応答しない場合があります。ICMPのパケットロスとプロキシのTCP通信におけるパケットロスを、同じものとみなすことはできません。
- 経路確認で中継点にパケットロスが表示される：後続の各ホップや最終接続先が正常なら、中継機器が測定への応答を制限している可能性があります。それだけでは転送時のパケットロスを証明できません。
- ピーク時間帯だけ速度が落ちる：同じ接続先・同じノードで時間帯ごとの結果を記録してください。クライアントを何度も再インストールするより、経路の異なるノードに切り替えて比較しましょう。
第3段階：システムプロキシ・ルーティング・DNSの適用状況
システムプロキシが影響するのは、その設定に従うアプリだけです。端末のすべての通信がコアを経由するわけではありません。v2rayNでは、まず「システムプロキシ」→「システムプロキシを自動設定」を確認し、次に「設定」→「パラメーター設定」でローカルの待受ポートを確認します。バージョンによって項目名や場所が異なる場合があるため、現在の画面に表示される待受設定を基準にしてください。TUNモードとシステムプロキシは別の接続方式です。原因を調べる間は、どちらか一方の入口に絞ってください。
ローカルでSOCKSの受信待受が127.0.0.1:10808で有効だと確認できた場合は、Windowsターミナルから以下の明示的なプロキシリクエストを実行できます。このポートは例示用です。待受方式を確認せずにそのまま使わないでください。HTTPプロキシ専用のポートをSOCKSポートとして使うことはできません。このサンプルページは小さなリクエストの検証用で、大容量ファイルの転送速度測定には使えません。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/socks5hでは、接続先のドメイン名をSOCKSプロキシ側で処理します。最終的にどこで名前解決されるかは、コアのルーティング、DNS、出方向の設定によって異なります。ここでのtime_connectが主に示すのは、ローカルのプロキシ入口への接続時間であり、クライアントからリモートノードまでの実際の遅延ではありません。最初の応答までの時間には、プロキシのネゴシエーション、接続先への接続、接続先からの応答も含まれるため、DNSの所要時間だけを示すものではありません。
| 設定項目 | 確認方法 | 結果の見方 |
|---|---|---|
| プロキシの入口 | 明示的なSOCKSリクエストとブラウザーでのアクセスを比較 | 前者は正常で後者が遅い場合、ブラウザーのプロキシ設定や拡張機能を確認 |
| ルーティングの振り分け | クライアントのルーティング設定で、適用ルールと対応する出方向を確認 | コアに入った後でも、ルールによって直接接続や別の出方向に振り分けられることがあります |
| DNS | 現在のDNS設定を記録し、名前解決の工程を1つだけ変更して再測定 | 名前解決は最初の表示や接続先アドレスの選択に影響しますが、出口の速度制限を解除するものではありません |
| 端末の負荷 | タスクマネージャーでCPU、ネットワーク、バックグラウンドのアップロードを確認 | 1つのCPUコアがほぼフル稼働でも、CPU全体の使用率は高く表示されない場合があります |
Android版v2rayNGでは、「設定」→「アプリごとのプロキシ」で対象アプリが想定したプロキシ対象に含まれているか、システムのVPN許可が有効かも確認します。画面を消した後にだけ速度が落ちたり切断されたりする場合は、システムの「設定」→「アプリ」→「v2rayNG」→「バッテリー」でバックグラウンド動作を許可してください。メーカーによってメニュー名が異なる場合があります。画面点灯中も速度が低い場合は、原因をすべて省電力設定に求めないでください。
ログで切り分ける：ハンドシェイク失敗と低速通信
ログはリクエストがどの段階で失敗したかを確認するためのもので、帯域を測るメーターではありません。再現した時刻を記録し、その前後の関連行だけを確認します。v2rayNはクライアントの画面であり、実際のエラーは稼働中のコアから出ています。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用するため、ログの表現は異なる場合があります。調査後は通常使うログレベルに戻し、詳細ログの長期記録によるディスク書き込みを避けてください。
エラー：context deadline exceeded
原因：処理が制限時間を超過しています。名前解決、接続、ハンドシェイクのいずれかで発生する可能性があり、この行だけでは特定できません。対処法：前後のログで接続先と処理の種類を確認し、まずアドレスとポートを点検してから、同じノードで回線を変えて再現するか試します。
エラー：connection refused
原因：接続先から明示的に拒否されています。ポートで待ち受けていない、または誤ったポートに接続している場合によく発生します。対処法：ログのアドレスがローカルの受信待受かリモートサーバーかを確認し、それぞれクライアントの待受設定またはノードのポートを点検します。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在時刻が一致していません。システム時刻の誤り、またはサーバー証明書の問題が考えられます。対処法：システムの自動時刻合わせを有効にして再試行します。それでも解決しない場合はサービス提供元に証明書の対応を依頼し、検証を無効にしないでください。
ログ上でリクエストが正常に確立されていて、ダウンロード速度だけが低い場合は、ノードと経路の比較に戻りましょう。関係のない警告がたまに出ただけで設定を何度も変更しないでください。ログを共有する前に、サブスクリプションURL、アクセス認証情報、ユーザー識別情報、不要なサーバー情報を隠し、時刻、エラーの種類、情報を伏せた出方向のラベルだけを残してください。
結論：問題がついてくる項目に対応する層から確認
ノードを変えると問題が解消する場合は出口とサーバー、回線を変えると解消する場合は接続と経路、端末やアプリを変えると解消する場合はプロキシの入口、振り分け、バックグラウンド制限を優先して確認します。比較結果で範囲を絞ることはできますが、サーバー側の監視に代わるものではありません。
よくある質問：低遅延、速度測定の違い、更新後の速度低下
ノードの遅延が50ミリ秒なのに、ダウンロードが遅いのはなぜ？
50ミリ秒は、特定の測定で待ち時間がどれくらいだったかを示すだけです。測定がTCP接続の確立時間なのか、実際の通信を測ったものなのかを確認し、同じファイルを3回連続してダウンロードします。遅延が安定しているのに転送速度が低い場合は、遅延だけでノードを選ばず、ノードの出口、接続先の速度制限、同時接続数を比較してください。
速度測定は速いのにブラウザーでWebページを開くのが遅い場合、何から確認すればよい？
まず速度測定を停止し、同じブラウザーで同じURLを繰り返し開きます。ブラウザーがシステムプロキシに従っているか、拡張機能がプロキシ設定を上書きしていないかを確認し、明示的なSOCKSリクエストとも比較してください。速度測定サーバーとWebページの接続先では経路全体が異なるため、測定が速くてもWebページのDNS、ハンドシェイク、サーバー応答が速いとは限りません。
サブスクリプション更新後に遅くなったら、すぐに再インストールすべき？
まず更新前後のサーバーアドレス、ポート、通信方式、セキュリティ設定を確認し、想定していたノードが選択されているか確かめます。サブスクリプションで更新されるのは主にサーバー設定で、ルーティングは通常別に管理されています。現在のバージョンと設定を記録し、別のノードで再測定してください。クライアントのバージョン変更に問題が明確に追従する場合にのみ、バージョン間の比較を進めます。
Androidで画面点灯中は正常なのに、画面ロック後に速度が落ちるときは？
同じノードを使い、画面点灯中とロック中の両方で再現するか確認します。v2rayNGのVPN接続状態を確認し、システムのアプリ別バッテリー設定でバックグラウンド動作を許可してください。モバイルデータ通信中だけ発生する場合は、データセーバーやバックグラウンドデータの許可も確認します。設定を1つ変更するたびに再測定してください。
DNSを変えるとダウンロード速度は2倍になる？
どの環境でも効果があるわけではありません。DNSによって名前解決の待ち時間やコンテンツ配信先のアドレスが変わることはありますが、確立済みの接続帯域が直接向上するわけではありません。元の設定を記録し、同じノードで初回アクセスと継続的なダウンロードを比較します。ページの表示開始だけが改善した場合は、その範囲に限った結果として記録し、出口の帯域が向上したと判断しないでください。