Webページの読み込み遅延、ダウンロード速度の変動、動画の頻繁なバッファリング、接続遅延の急上昇を確認したい場合に適しています。まずテスト条件をそろえ、ノード、接続回線、ローカル設定の順に確認します。各手順では変更する変数を1つに絞り、遅延、パケットロス、スループット、ログを見て次の対応を判断します。
再現可能な速度基準を先に作る
ノードを連続して切り替えるだけでは原因を特定しにくくなります。ノード、テスト時刻、対象サイト、プロキシモード、無線状態が同時に変わると、速度が戻ってもどの変更が有効だったのか分かりません。開始前にファイル同期、ソフトウェア更新、上り帯域を消費する処理を停止し、テスト端末を同じネットワーク位置に置きます。
速度は少なくとも3つの数値で判断します。接続確立までの時間、継続転送時の平均スループット、10分間の変動幅です。低遅延は往復応答が速いことを示すだけで、利用可能な帯域幅が大きいとは限りません。遅延65ミリ秒のノードが安定して8 Mbpsしか出せない一方、遅延120ミリ秒のノードが45 Mbpsを継続できる場合もあります。
同じ大容量ファイル、または同じ連続転送タスクを使い、各回60秒以上、30秒の間隔を空けて3回テストします。開始直後の数秒間に出るピーク値だけを見ないでください。ブラウザーキャッシュ、サーバーの一時的なバースト、クライアントの統計更新間隔によって、短時間の速度は高く表示されることがあります。
| 記録項目 | 推奨サンプル | 判断の目的 |
|---|---|---|
| 実接続遅延 | 5回連続で測定し、中央値を記録 | 一時的なハンドシェイクの揺らぎを除外 |
| 継続スループット | 1回60秒、合計3回 | ノード帯域幅と回線の安定性を判断 |
| パケットロス率 | プローブパケットを50～100個送信 | 接続ネットワークまたは中継回線の問題を特定 |
| テスト時間帯 | 昼間と夜間に1回ずつ測定 | 特定のピーク時間帯に混雑するか確認 |
記録のポイント：クライアントのバージョン、コアのバージョン、プロキシモード、現在のネットワークも同時に記録します。例：「v2rayN 7.x、Xrayコア、システムプロキシ、無線ネットワーク、HTTPポート10809」。バージョンを推測せず、クライアントのバージョン情報画面やログ冒頭に表示される実際の値をコピーしてください。
第1段階：特定のノードだけが原因か確認する
ノード層は最も検証しやすい部分です。同じサブスクリプショングループから、地域が近くサーバーアドレスが異なるノードを2～3個選び、ローカルネットワーク、プロトコル種別、テスト対象を固定します。v2rayNではサーバー一覧からノードを選択し、「サーバーへの実接続遅延をテスト」を実行できます。Androidでは v2rayNG または v2flyNG のノード一覧から接続テストを行います。
1つのノードだけが継続的に遅く、他のノードが3回のテストで正常なら、原因はそのノードのサーバー負荷、ポート到達性、または出口帯域にある可能性が高いです。同じ地域のノードが夜間だけ低下し昼間に戻るなら、回線混雑が疑われます。すべての地域、すべてのプロトコルで遅い場合は、接続回線とローカル設定の確認に進みます。
- サブスクリプションを1回更新し、調整済みまたは停止済みの古いノード設定を使い続けていないことを確認します。
- 「地域が近く、サーバーが異なる」という基準で、少なくとも3つのノードを選びます。
- 各ノードでまず実接続遅延を5回測定し、その後に継続転送を3回行います。
- 平均速度と最も遅かった回の速度を記録し、瞬間的な最大値だけで順位を決めないでください。
- 最も安定したノードに再接続し、もともと遅かった対象アプリを再測定します。
| テスト結果の例 | 遅延の中央値 | 3回分のスループット | 初期判断 |
|---|---|---|---|
| ノードA | 72 ms | 7、9、6 Mbps | 遅延は正常だが帯域幅が低い |
| ノードB | 89 ms | 38、41、39 Mbps | 安定しており、比較対象に適する |
| ノードC | 210 ms | 0、18、2 Mbps | 接続品質の変動が明らか |
結論：最低遅延より安定したスループットが重要
ノードBはノードAより遅延が17ミリ秒大きいものの、3回の速度差はわずか3 Mbpsで、ダウンロードや動画視聴には適しています。ノードCはピーク値が低くない一方、2回はほぼ利用できない結果だったため、まず回線のパケットロスやサーバー負荷を確認します。
ノード設定も完全に一致させる必要があります。VMessのユーザー識別子、ポート、転送方式、TLS設定はサーバー側と一致しなければなりません。VLESSでは Reality、フロー制御、サーバー名が関係する場合もあります。設定不一致は通常接続失敗を招きますが、転送層が何度も再試行すると、Webページの待ち時間が長くなり、速度が極端に低下することもあります。速度改善を目的に、サブスクリプションで配布されたプロトコル項目をむやみに変更しないでください。
エラー:context deadline exceeded
原因と対処：制限時間内に接続またはリクエストが完了していません。同じ地域の別ノードに切り替え、現在の回線でパケットロスが多発していないか確認します。
エラー:dial tcp: i/o timeout
原因と対処：サーバーアドレスまたはポートへのTCP接続がタイムアウトしています。ノードのポートを確認し、別のネットワークでも再測定して、ノードへの到達不能とローカル回線の問題を切り分けます。
エラー:connection reset by peer
原因と対処：接続がリモート側または中継機器によってリセットされました。サブスクリプションを更新して再接続し、複数のノードで同時に発生する場合は接続回線の確認に進みます。
第2段階：接続ネットワークと中継回線を確認する
複数のノードが同時に遅くなった場合は、まずクライアントの上級設定を変更しないでください。同じ端末を無線ネットワークから有線ネットワークへ切り替えるか、別の利用可能な接続回線でテストします。ノード設定をまったく変えずに速度がすぐ戻るなら、原因はクライアントより手前のローカル接続または通信事業者の回線にあり、サブスクリプション内容ではありません。
無線ネットワークでは、信号減衰、同一周波数帯の干渉、上り回線の混雑がよく影響します。速度測定サイトで下り帯域が十分でも、クラウド同期で上り帯域が埋まると、TCP確認応答やプロキシのハンドシェイクが遅延します。テスト時は端末をアクセスポイントに近づけ、5 GHz帯を優先し、他の端末による大量のアップロードを停止してください。
ping -n 50 1.1.1.1
pathping 1.1.1.1
powershell Test-NetConnection 1.1.1.1 -Port 443これらのコマンドは、ローカルから公共の対象先までの基本的な疎通を確認するためのもので、ノード速度測定の代わりにはなりません。Windowsで50回のプローブを行い、パケットロスが0%、大半の遅延が10～30ミリ秒なら、ローカル接続は通常安定しています。パケットロスが3%以上、または遅延が20ミリ秒から300ミリ秒へ頻繁に跳ねる場合は、無線干渉、ルーター負荷、接続回線を先に確認します。
- 時間帯によって遅い：3日間連続で20:00～23:00に再測定し、昼間は正常で夜間に低下するなら、通常はピーク時の混雑を示します。
- ネットワークを変えるとすぐ戻る：ノードとクライアント設定を変えていないなら、接続回線を優先的に調べます。
- 最初のゲートウェイから不安定：無線信号、LANケーブル、ルーター負荷、バックグラウンドのアップロードを重点的に確認します。
- 基本ネットワークは安定しているのにノードがタイムアウト：地域やサーバーポートの異なるノードを比較し、クライアントの再インストールを繰り返さないでください。
注意：1回のコマンド結果だけで回線を判断しないでください。速度が正常なときと異常なときに少なくとも1組ずつデータを保存し、同じネットワーク、同じ端末、同じテスト対象を使う必要があります。
第3段階：システムプロキシ、TUN、ルーティング分岐を再確認する
ノードと接続回線が正常なら、ローカル設定を確認します。最初に、対象アプリが実際にプロキシを経由しているか確認してください。v2rayNの一般的なローカルSOCKSポートは10808、HTTPポートは10809ですが、実際のポートは「設定」→「パラメータ設定」に表示される現在値を基準にします。ブラウザーがシステムプロキシを使う場合は通常HTTPポートを経由し、SOCKSを手動設定するアプリには対応するSOCKSポートを入力します。
アプリに古いポートを設定していると、接続が直接失敗することがあります。システム上の別のプログラムが同じポートを使用している場合、コアの起動に失敗したり、再試行を繰り返したりします。v2rayNのログを開き、まずインバウンドのリッスンが成功していることを確認し、次に対象リクエストが記録されているか確認します。Androidで v2rayNG または v2flyNG を使う場合は、いったん接続を停止してから再起動し、古い仮想ネットワークセッションを整理します。
エラー:bind: Only one usage of each socket address is normally permitted
原因と対処：ローカルのリッスンポートが使用中です。10808または10809を使用しているプログラムを終了するか、「設定」→「パラメータ設定」でポートを変更してコアを再起動します。
エラー:failed to find an available destination
原因と対処：アウトバウンドサーバーのアドレス解決に失敗しました。ノードアドレスが完全か確認し、DNS設定を切り替えてコアを再起動した後、再接続します。
エラー:no such host
原因と対処：ノードのドメインまたは対象ドメインを解決できません。システム時刻とDNSの利用可否を確認し、古いアドレスを除外するためサブスクリプションを更新します。
ルーティング分岐によって「一部のWebサイトだけ遅い」状態になることもあります。ルールは通常、ドメイン、IP、プロセス、インバウンドタグに基づいて、トラフィックを直接接続、プロキシ、ブロックのいずれかへ振り分けます。対象ドメインが誤って直接接続されると、アプリが待ち続けることがあります。ローカルサービスが誤ってプロキシ経由になると、不要な迂回が発生します。一時的にグローバルプロキシへ切り替えて比較すれば、ルールマッチングの問題かどうかをすばやく判断できますが、テスト後は元の分岐設定に戻してください。
- システムプロキシモードで1回テストし、Webページの初回表示時間と継続速度を記録します。
- システムプロキシを無効にしてからTUNモードだけを有効にしてテストし、2つの経路が同時に干渉しないようにします。
- ルーティングモードを一時的にグローバルプロキシへ変更します。特定のWebサイトが明らかに改善するなら、そのドメインにマッチしたルールを確認します。
- 元のルーティングモードに戻し、競合するルールの順序を変更してから再接続し、もう一度測定します。
- ログのインバウンド、ルートマッチ、アウトバウンドタグを確認し、リクエストが想定した経路を通っていることを確認します。
TUNモードは、システムプロキシ設定を読み取らないアプリも広く取り込めますが、仮想ネットワークアダプター、DNS、ルーティングテーブルという3つの確認点が増えます。ブラウザーは正常なのにゲームやコマンドラインツールだけ遅い場合は、TUNで比較できます。システムプロキシが対象アプリをカバーしているなら、速度測定だけを目的にTUNを無理に有効にする必要はありません。
プロトコル、DNS、端末リソースが速度に与える影響
VMessやVLESSはプロキシ接続の一部にすぎず、実際の性能は転送層、TLS、サーバー入口、回線品質にも左右されます。プロトコル名だけで速度を判断することはできません。同じサーバー、同じ回線、近い設定であればプロトコル間の差は小さい場合があります。一方、転送パラメータを誤ると、接続の再試行や追加のハンドシェイクによってアクセスが大幅に遅くなります。
DNSの問題は、Webページの初回表示に時間がかかる一方、接続確立後のダウンロード速度は正常という形で現れることが多いです。まずログでドメイン解決が繰り返しタイムアウトしていないか確認し、次にシステムDNS、クライアントDNS、ルーティングルールが競合していないか調べます。DNSを変更した後はコアを再起動して再接続しないと、古いキャッシュが結果に影響し続ける場合があります。
| 症状 | 優先して確認する項目 | 比較テスト |
|---|---|---|
| 初回表示は遅いが、ダウンロード後は安定 | DNS解決とハンドシェイク | DNSを変更してコアを再起動 |
| すべての通信が継続的に遅い | ノード負荷と回線帯域 | サーバーアドレスの異なるノードへ切り替え |
| 速度が周期的にゼロになる | パケットロス、無線干渉、端末負荷 | 有線ネットワークに切り替え、アップロードを停止 |
| 特定のアプリだけ遅い | プロキシの入口とルートマッチ | システムプロキシとTUNモードを比較 |
| 接続後、CPU使用率が長時間ほぼ100% | 端末リソースと同時実行タスク | 並列ダウンロードを停止して再測定 |
結論：症状に応じて確認する層を選び、プロトコルとルーティングを同時に変更しない
初回表示が遅いならまず名前解決、継続的に遅いならノードと回線、一部のアプリだけ遅いなら通信の入口を確認します。各回で変更する設定を1つに絞り、前後のデータを残すことで、その調整が本当に有効だったか判断できます。
端末リソースも基準値に含めます。システムのタスクマネージャーを開き、テスト中のCPU、メモリ、ディスク使用率を確認してください。プロキシコアの単一プロセスが長時間ほぼ100%で、同時に解凍、同期、セキュリティスキャンなどが動いている場合は、他の高負荷タスクを一時停止してから再測定します。LAN内の別端末が同じノードで40 Mbpsを出せるのに、現在の端末が8 Mbpsしか出ないなら、ノードよりもローカルリソースやネットワークアダプターを優先して確認します。
よくある速度問題への直接的な対処
遅延は60ミリ秒なのに、なぜダウンロードが遅いのですか？
遅延と帯域幅は別の指標です。同じノードで、1回60秒以上の継続転送テストを少なくとも3回実施します。常に他のノードより遅いなら、遅延の数値だけで順位を付けず、まずノードを変更してください。
昼間は正常なのに、夜になると決まって遅くなる場合は？
20:00～23:00のデータを3日間記録し、別の接続回線でも同じノードを比較します。ネットワークを変えて改善するなら、接続回線または中継回線の混雑です。すべてのネットワークで遅い場合に、ノードのピーク時負荷を検討します。
ブラウザーは速いのに、ターミナルやゲームが遅いのはなぜですか？
ブラウザーはシステムプロキシを読み取っていても、ターミナルやゲームは読み取っていない可能性があります。まずアプリがHTTPまたはSOCKSプロキシに対応しているか確認してください。システムプロキシを読み取らないアプリは、TUNモード単独でテストできます。
サブスクリプション更新後に急に遅くなりました。再インストールすべきですか？
まず更新前後でノードアドレス、ポート、プロトコル、転送方式を比較し、同じグループ内の別ノードにも切り替えます。再インストールではノード負荷や回線混雑は解消しないため、設定の比較が有効です。
グローバルプロキシは速いのに、ルーティングモードが遅い場合は？
対象ドメインにマッチした直接接続ルールとDNSグループを確認します。競合するルールの順序を調整して再接続し、ログのアウトバウンドタグが直接接続から想定したプロキシアウトバウンドへ切り替わったことを確認してください。
完全な切り分け手順は、3つのノードで条件をそろえて比較し、別のネットワークで接続回線を除外し、最後にポート、プロキシモード、DNS、ルートマッチを確認する、という一文にまとめられます。前の2段階のデータが安定している場合に限り、上級設定の変更に意味があります。
対応後は、クライアントとコアのバージョン、ノードの地域、実接続遅延、3回分のスループット、プロキシモード、テスト時刻を含む正常時の記録を残してください。次に速度が低下したとき、この基準をそのまま使えば、問題がノード、回線、ローカル設定のどこにあるかを通常10分以内に判断できます。