「レイテンシは正常なのにダウンロードが遅い」「昼は使えるのに、夜は数Mbpsしか出ない」「同じサブスクリプションでも、PCは速いのにAndroidは遅い」――どれも速度の問題に見えますが、実際の原因はまったく異なる場合があります。クライアントに表示されるレイテンシだけでは判断できません。レイテンシは通常、短いリクエスト1回分の往復時間を示すだけで、継続的な転送性能や、ノードの出口帯域、回線のパケットロス、ローカルのルーティングが正常かどうかを直接表すものではないためです。
VMessやVLESSなどのノードには接続できるものの、ウェブページの表示、動画のバッファリング、ファイル転送が明らかに遅い方に向けた内容です。まず測定条件を固定し、ノードの容量、転送回線、クライアント設定の順に確認します。毎回1つの変数だけを変更すれば、ノードを替えるべきか、時間帯を変えるべきか、ローカル設定を修正すべきかを判断できます。
再現可能な速度測定の基準を作る
調査前に、ノードの切り替え、DNSの変更、Muxの有効化、ルーティングの調整を同時に行わないでください。一度に4つも変えると、速度が戻っても本当の原因が分かりません。まず直結速度、プロキシ経由の速度、測定時刻、ノード名、クライアントとコアのバージョンを記録し、同じ端末、同じネットワーク、同じ測定先で繰り返しテストします。
完全なリクエストは「ノード」から直接ウェブサイトへ届くわけではありません。少なくともアプリ、システムプロキシ、ローカルコア、アクセス回線、リモートノード、対象サイトを経由します。どこか1か所でキュー待ち、パケットロス、誤ったルーティングが発生すると、最終的には読み込みの遅さとして現れます。
上の数値は調査記録の例であり、速度の基準ではありません。重要なのは比較できるデータを残すことです。3回連続で測定し、明らかに異常な1回を除いたうえで、残り2回の範囲を記録することをおすすめします。1回目が92 Mbps、2回目が89 Mbps、3回目だけ8 Mbpsだった場合は、すぐにノードの速度制限と決めつけず、一時的なパケットロスや測定先の変動を疑います。
- 同期、ダウンロード、アップロード中のアプリを終了し、ほかの端末が家庭内ネットワークを使い切っていないことを確認します。
- まずシステムプロキシを無効にして直結速度を測定し、その後、同じノードを有効にしてプロキシ経由でテストします。
- 接続方式を固定します。直結テストでは有線、プロキシテストでは電波の弱い無線、といった条件の変更は避けてください。
- クライアントのレイテンシだけでなく、最初の1バイトを待つ時間、継続ダウンロード速度、夜間のピーク時の状態も記録します。
- 1回の測定で変更する設定は1つだけにし、変更後はコアを再起動するか再接続して、古い接続が再利用されないようにします。
第1段階：ノードの負荷とプロトコルのオーバーヘッドを確認する
ノード層では2つの点を確認します。リモートサーバーが混雑していないか、そして現在のノード設定が余分な負荷を生んでいないかです。レイテンシが低くても、帯域が十分とは限りません。サーバーは80ミリ秒で探測リクエストに応答できても、CPU、出口帯域、同時接続数が上限に達していれば、継続的なスループットは低くなります。
有効な比較方法は、レイテンシ測定を10回連続で行うことではありません。同じサブスクリプションから、地域が近く設定が明確な2つのノードを選び、5分以内に同じ作業をそれぞれ実施します。Aノードが75 Mbpsで安定し、Bノードが9 Mbpsしか出ない場合、同じ端末とローカルネットワークを使っているなら、Bノードの負荷または出口品質を疑うべきです。
| 確認できる現象 | 考えられる原因 | 比較テスト |
|---|---|---|
| レイテンシは90 msだが、継続速度は6 Mbpsしか出ない | ノードの出口が混雑している、またはサーバー負荷が高い | 同じ地域の別ノードに切り替え、同じ測定先で3回繰り返す |
| 小さなウェブページは正常だが、大容量ファイルの速度が周期的に低下する | 継続転送の混雑、パケットロスによる再送、接続多重化の影響 | Muxを無効にして再接続し、1分間の平均速度を比較する |
| すべてのノードがほぼ同じ速度で止まる | ローカルネットワーク、測定先、共通のルーティング規則による制限 | 直結の基準値を測定し、誤ってプロキシを経由していないか確認する |
| 特定のノードだけ夜間に大きく低下し、朝に回復する | 共有ノードの夜間ピーク時の負荷または回線混雑 | 08:00と21:30にそれぞれ1組ずつ記録を残す |
VMessとVLESSはいずれも接続設定の一部にすぎず、実際の負荷はトランスポート層、暗号化、TLS、パケットサイズ、回線品質にも左右されます。プロトコル名が「新しい」からといって、必ず速いとは考えないでください。プロトコル名だけを比較するより、設定が正しいこと、サーバーが対応していること、回線が安定していることのほうが重要です。サブスクリプションのノードは提供元の完全な設定でインポートし、安全設定を自己判断で削除したり、別ノードのポートやトランスポート設定を混在させたりしないでください。
- まずサブスクリプションを更新して完全な設定を取得し、現在選択しているノードが、古いグループに残った同名ノードではないことを確認します。
- テスト中は同じトランスポート設定を維持し、ノードだけを切り替えます。ノードの違いとプロトコルの違いを混同しないためです。
- 大容量の通信だけが遅い場合は、単一接続と複数接続のタスクを別々にテストし、単一接続のボトルネックがないか確認します。
- 接続直後は速いのに数分後に低下する場合は、コアログの時刻を記録し、サーバーが頻繁に切断と再接続を繰り返していないか確認します。
第2段階：ネットワーク間の経路と混雑時間帯を見分ける
複数のノードが同時に遅くなり、翌朝には回復する場合は、回線の問題である可能性が高いでしょう。ネットワーク間の通信は複数のルーターを経由するため、夜間のピーク時にはキュー待ち、揺らぎ、パケットロスが発生することがあります。この場合もクライアントには「接続済み」と正常に表示されます。接続自体は維持されていて、各パケットの到着に時間がかかり、失われたデータが再送されているだけだからです。
回線層の調査では、時間帯をそろえて比較することが重要です。08:00、14:00、21:30の3つの時間帯に同じノードでテストし、レイテンシ、1分間の連続ダウンロード平均速度、明らかな速度変動の有無を記録します。たとえば朝91 Mbps、午後84 Mbps、夜18 Mbpsという記録のほうが、「ノードが18 Mbpsしか出ない」という1回だけの説明より、問題を正確に示します。
地域の異なるノードが夜間にすべて低下し、低下幅だけが異なる場合は、地理的な近さだけでなく、経路が安定している地域を優先するとよいでしょう。距離は理論上のレイテンシに影響しますが、実際の経路が必ず短いとは限りません。通信事業者間の接続、ノードのアクセスネットワーク、中間ルートの変化によって、遠いノードのほうが安定したスループットを得られることもあります。
現象からレイテンシ・ジッター・パケットロスを見分ける
- レイテンシの上昇：ページの初回応答は遅くなりますが、ダウンロード開始後の速度は許容範囲に収まる場合があります。
- ジッターが大きい：速度が大きく上下し、音声通信、リアルタイムリクエスト、短時間の接続で遅延を感じやすくなります。
- パケットロスによる再送：ダウンロード速度がギザギザに変動し、ログにタイムアウト、接続リセット、コンテキストキャンセルが伴うことがあります。
- 経路の混雑：特定の時間帯に集中して発生します。同じ地域の別ノードに替えても改善せず、経路の方向を変えると改善する場合があります。
第3段階：Mux・DNS・ルーティングを確認する
同じノードが別の端末では正常な速度で動くなら、ローカル設定を重点的に確認します。v2rayN、v2rayNG、v2flyNGはいずれもアプリの通信をローカルコアに渡しますが、システムプロキシモード、VPNモード、ルーティング規則、DNSの経路は同じとは限りません。サブスクリプションをコピーしても、2台の端末の最終的な出力経路まで完全に一致するわけではありません。
まずリスニングポートを確認します。ローカル混合ポート10808を例にすると、ブラウザーまたはシステムプロキシは、現在のクライアントが実際に待ち受けているアドレスとポートを指定する必要があります。古いツールが10808を使用中だと、クライアントが別のポートへ切り替わったり、コアの起動に失敗したりすることがあります。v2rayNでは「設定」→「パラメータ設定」でローカルリスニング設定を確認し、変更後に保存してコアを再起動します。そのうえでシステムプロキシの指定先が一致していることを確認してください。
Muxを有効にすれば必ず速くなるわけではない
Muxは複数の論理リクエストで1つの接続を共有し、繰り返しのハンドシェイクを減らせる場合があります。一方、パケットロスが目立つ場合や単一接続に制限がある場合は、複数のリクエストが互いに待たされることもあります。調査では厳密な比較を行います。ノード、時刻、測定先を固定し、Muxを無効にして完全に切断してから再接続し、3回測定してください。平均速度が24 Mbpsから57 Mbpsに上がり、変動も小さくなったなら、現在の回線には元の多重化設定が適していません。差が2〜5％程度なら、主な原因とは考えないでください。
ルーティング規則が「一部のサイトだけ遅い」原因になる
ルーティングは、ドメイン、アドレス範囲、ルールセットに応じて直結とプロキシ経由の出力先を選びます。規則の順序が誤っていると、同じページでもメイン文書はプロキシ経由なのに、画像や動画のドメインだけ直結になることがあります。逆に、本来直結すべきローカルサービスがリモートノード経由になる場合もあります。トップページは開くのにリソースの読み込みだけが長い、または特定サイトだけ遅い、といった症状が出ます。
- 一時的にクライアント標準の基本プロキシモードへ切り替え、問題が消えるか記録します。
- 基本モードで速度が戻った場合は、カスタムルールをグループごとに有効化します。複雑な設定全体を一度に戻さないでください。
- ドメイン規則が、より前にある広範な規則に先に一致していないか確認します。特に、同じサービスが複数のリソースドメインを使用しているケースに注意してください。
- ルーティングを変更したら設定を再読み込みし、テストページも開き直します。以前の出力先を古い接続が引き継がないようにするためです。
DNSの遅さと転送の遅さは体感が異なる
DNSの異常は、クリック後に長時間まったく反応しない症状として現れることが多い一方、ページの読み込みが始まれば、その後の速度は十分な場合があります。継続転送のボトルネックでは、ダウンロードは始まっているのに低速のままです。テストでは初回表示と再読み込み後の差を比較し、コアログでドメイン解決、接続確立、タイムアウトの発生順を確認します。
| ローカル側の確認項目 | 確認場所・方法 | 正常な状態 |
|---|---|---|
| リスニングポート | v2rayNの「設定」→「パラメータ設定」で10808を確認 | クライアント、システムプロキシ、アプリの指定が一致している |
| Mux | 無効化後に切断・再接続し、同じ測定先で3回テストする | 有効時と無効時の平均値を明確に記録する |
| ルーティング | 一時的に基本モードへ戻し、ルールをグループごとに有効化する | 特定のルールグループを特定でき、ルーティング要因を切り分けられる |
| Androidのバックグラウンド制限 | システム設定でv2rayNGまたはv2flyNGの継続動作を許可する | 画面ロックやアプリ切り替え後も接続が中断されない |
コアログと照合して見かけ上の速度問題を切り分ける
「速度が遅い」と感じても、実際には接続の失敗と再試行を繰り返しているだけの場合があります。最終的にページが開くため、帯域不足だと思いがちですが、ログにはDNS解決失敗、ダイヤルタイムアウト、リモート側のリセット、ローカルポートの競合などが記録されていることがあります。調査ではまず測定開始時刻を正確に記録し、同じ1分間のエラー記録を確認してください。古い履歴ログに惑わされないことが重要です。
エラー：failed to dial WebSocket
原因と対処：制限時間内に転送接続を確立できませんでした。ノードに到達できない、経路が混雑している、設定が一致していないなどの可能性があります。まずサブスクリプションを更新し、アドレス、ポート、トランスポート設定を確認してから、同じ地域の別ノードと比較します。
エラー：i/o timeout
原因と対処：接続または読み書きが待機時間を超えています。回線のパケットロスや対象側の応答遅延でよく発生します。朝と夜の時間帯を比較し、夜間のピーク時に集中するなら、まず回線層を確認します。
エラー：connection reset by peer
原因と対処：相手側または中間の経路が接続を強制的にリセットしています。ノードが有効であることを確認し、Muxを無効にして比較テストを行い、特定のノードだけで発生していないか確認します。
エラー：context canceled
原因と対処：リクエストが完了前にキャンセルされました。ノード切り替え、設定の再読み込み、アプリによる中断、上流接続の失敗などが原因になります。速度測定中に頻発する場合は、自動切り替えと設定の連続更新をいったん停止します。
1件のエラーだけで帯域の問題と断定することはできません。たとえばノード切り替え時に一度だけcontext canceledが出るのは説明可能な動作です。数秒おきに繰り返し発生し、速度がゼロになる場合は、直前の接続失敗記録をさらに追跡する必要があります。ログは英語のエラーを見ただけですぐ全設定を替えるのではなく、発生頻度、対象ノードの範囲、時間的な規則性を組み合わせて判断してください。
- 1つのノードだけでタイムアウトが続く：ノード設定、状態、リモート側の負荷を優先して確認します。
- 同じネットワークですべてのノードがタイムアウトする：回線、ローカルDNS、ファイアウォール、リスニングポートを確認します。
- PCは正常なのにAndroidだけ切断を繰り返す：v2rayNGまたはv2flyNGのバックグラウンド動作制限とVPN権限の状態を確認します。
- サブスクリプション更新後に遅くなった：現在選択中のノード、ルーティンググループ、カスタム設定に古い値が残っていないか確認します。
よくある速度測定の疑問と最終判断
3段階の比較を終えれば、問題を「特定ノードの異常」「特定時間帯の回線混雑」「特定端末のローカル設定」のいずれかに分類できるはずです。それでも判断できない場合は、設定をさらに重ねず、接続を確認した1つのノード、基本ルーティング、標準DNS経路、Mux無効という最小構成に戻します。
レイテンシは80ミリ秒なのに、なぜダウンロードが遅いのですか？
レイテンシは短いリクエストの往復時間であり、継続帯域を示すものではありません。同じ測定先から少なくとも1分間ダウンロードし、同じ地域の別ノードと比較します。そのノードだけ遅いなら、まずノード負荷を疑います。
夜は遅く昼は速い場合、クライアント設定を変更すべきですか？
まず08:00と21:30に、同じノード・同じ測定先のデータを残します。直結が安定し、複数ノードが夜間に同時低下するなら、回線混雑の可能性が高く、DNSやポートを何度も変更しても通常は解決しません。
Muxを有効にすれば必ず速くなりますか？
必ずしもそうではありません。ほかの条件を固定し、Muxの有効時と無効時をそれぞれ3回測定して、平均速度と変動幅で判断します。パケットロスのある回線では、多重化接続によって複数のリクエストが同時に待たされることがあります。
サブスクリプションにノードが多い場合、1つずつ測定するのが最も確実ですか？
まず地域ごとに代表的なノードを3〜5個選び、同じ時間帯に継続転送をテストします。レイテンシ測定だけでは偶然の結果に左右されやすく、ノードの出口容量も分かりません。
PCは速いのにAndroidが遅い場合、最初に何を確認すべきですか？
両方で同じノードを選択していることを確認し、v2rayNGまたはv2flyNGのVPN権限、バックグラウンド動作制限、アプリ別プロキシ、ルーティング設定を確認します。同じ無線ネットワークと同じ測定先で再テストしてください。
実行できる最終チェックリスト
- 直結の速度測定が正常であることを確認してから、プロキシの調査を始める。
- 同じ地域で少なくとも2つのノードを比較し、1回のレイテンシ測定を継続速度の代わりにしない。
- 朝と夜の時間帯を記録し、特定時間帯に集中して低下するなら回線層に分類する。
- 特定端末だけ遅い場合は、10808など実際のリスニングポートとシステムプロキシを確認する。
- 経験則でMuxのオン・オフを決めず、無効化して完全な比較テストを1回行う。
- 基本ルーティングに戻し、迂回の原因となるルーティング規則をグループごとに特定する。
- 測定時刻に合わせてコアログを確認し、低帯域と接続の再試行を区別する。
- 毎回変更するのは1項目だけにし、コアを再起動して新しいデータを記録する。
速度問題の調査で重要なのは、「最速の設定」を探すことではなく、原因と結果の関係を作ることです。特定のノードだけが遅いならノードを確認し、複数のノードが時間帯に合わせて同時に遅くなるなら回線を観察し、1台の端末だけが遅いならポート、Mux、DNS、ルーティング、バックグラウンド設定に戻って確認します。この段階的なテストを終えてからサブスクリプションの更新、ノードの切り替え、クライアント設定の調整を判断するほうが、設定を無作為に変え続けるより早く解決できます。