ノードには接続できるものの、Webページの初回表示が遅い、ダウンロード速度が出ない、夜間に頻繁に途切れる場合に役立ちます。条件を固定して基準値を取り、ノードと接続回線をそれぞれ入れ替えて比較したうえで、端末のプロキシ、DNS、Muxを確認します。一度に変更する条件は一つだけにし、元の設定と測定結果を記録しておきましょう。回線の混雑をクライアント設定の問題と取り違えにくくなります。
1. 初回表示の遅さ・ダウンロードの遅さ・接続切れを見分ける
「速度が遅い」には、少なくとも3つの異なる問題があります。名前解決や接続確立に時間がかかる、データ転送が続かない、接続が断続的に失敗する、の3つです。Webページの初回表示だけ止まり、再読み込みすると正常なら、まずDNSとハンドシェイクを確認します。ダウンロード開始直後は速いのに、その後ずっと低速なら、帯域や混雑が疑われます。動画が頻繁に再接続する場合は、パケットロスやタイムアウト、ネットワーク切り替えも確認してください。
この経路のどこか一つでも、アクセスが遅くなる原因になり得ます。v2rayNはデスクトップ用クライアントで、実際の通信転送は選択したコアが行います。Android版のv2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。クライアント画面に表示される遅延は、特定の測定先と方法による結果にすぎません。動画再生や大容量ファイルのダウンロード速度をそのまま示すものではありません。
| 症状 | まず確認する項目 | 比較方法 |
|---|---|---|
| 初回表示は遅いが、その後は正常 | DNS、TLSハンドシェイク、接続の再利用 | 同じURLに連続してアクセスし、初回と2回目以降を分けて記録する |
| Webページは正常だが、大容量ファイルのダウンロードが遅い | ノードの出口、回線帯域、接続先の速度制限 | ノードは変えず、別の配布元からファイルをダウンロードする |
| 夜間は遅いが、それ以外の時間帯は正常 | 共有出口の負荷、接続回線の混雑 | 同じ条件で時間帯を変えて測定する |
| 特定のアプリだけ遅い | アプリのプロキシ設定、UDP、接続先サービス | ログを確認し、そのアプリが想定した出口を経由しているか確かめる |
2. 繰り返し測定できる基準値を取る
クラウド同期、システム更新、ほかのダウンロードを一時停止し、同じ端末でURLと十分なサイズのテストファイルを決めます。複数の速度測定を同時に実行したり、ノードを切り替えながら結果を記録したりしないでください。以下は推奨する測定条件であり、ノードの性能を保証するものでも、本サイトで測定した結果でもありません。
現在の状態を記録
クライアントとコアのバージョン、ノード名、接続回線、プロキシモード、測定日時を記録します。現在の設定をバックアップし、画面を撮影する場合はサブスクリプションURL、ユーザー識別情報、鍵を隠してください。
接続先を確認
v2rayNの「設定」→「パラメータ設定」でローカルの待ち受けポートを確認し、SOCKSと混合プロキシのどちらが提供されているか確かめます。項目の配置はバージョンによって異なる場合があるため、現在の画面に表示される待ち受けプロトコルとポート番号を確認してください。
条件を固定して測定
同じノードを選び、同じURLで3回続けて測定します。まずページの接続時間を記録し、次に同じ配布元からファイルをダウンロードして、30秒間の安定した速度を確認します。開始直後の瞬間的な最高速度を結果とみなさないでください。
一つずつ比較
まずノードだけを変更し、次に元のノードに戻してネットワークだけを変更します。最後に端末設定を調整してください。測定ごとに結果を書き留め、残す必要のない変更は終了後に元へ戻します。
Windowsでは、以下のコマンドでSOCKSの接続先を明示すると、ブラウザー拡張機能やシステムプロキシの状態による影響を抑えられます。例ではローカルSOCKSの待ち受け先を127.0.0.1:10808としていますが、共通の既定値ではありません。実行前に実際の待ち受けポートに置き換えてください。この例のURLはリクエストの所要時間を確認するためのもので、大容量ファイルの転送速度測定には適しません。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/3. ノード側：共有負荷と接続先の速度制限を見分ける
同じノードでも、接続を受け付ける部分と、接続先Webサイトまでの出口回線があります。遅延が低いのにダウンロードが遅いことはあり得ます。小さなデータの応答が速くても、連続転送に十分な帯域があるとは限りません。地理的に近いノードでも、相互接続の経路が遠回りすると遅くなる場合があります。地域名だけで選ばないようにしましょう。
- ノードだけを変更：端末、ネットワーク、URL、測定時間帯を同じに保ちます。別のノードが3回の測定すべてで明らかに安定しているなら、元のノードか、その接続・出口経路に問題がある可能性が高まります。ただし、この比較だけでサーバー負荷が原因だと断定することはできません。
- 接続先だけを変更：同じノードから、異なる2つの配布元にアクセスします。一方だけ遅い場合は、接続先サイトの単一接続あたりの速度制限、アカウント制限、地域別の振り分けを確認してください。すぐにクライアントを再インストールする必要はありません。
- 時間帯を変えて再測定：夜間と混雑していない時間帯の両方で測定結果を記録します。時間帯による差が繰り返し現れる場合は、回線の混雑や共有リソースの競合が考えられます。ネットワークを切り替えた結果も合わせて判断してください。
- 単位を確認：速度測定ツールではMbps、ダウンロードツールではMB/sがよく使われます。10進法で換算すると8 Mbpsは約1 MB/sです。実際の転送速度はプロトコルのオーバーヘッドによってさらに低くなる場合があります。
利用できるノードの接続先アドレスが異なっても、実際には同じ出口を共有している場合があります。その場合、切り替えても改善しないことがあります。ノードの提供元に問い合わせる際は、「遅い」とだけ伝えるより、測定日時、接続事業者、ノード名、接続先ドメイン、複数回の測定結果を添えると確認しやすくなります。サブスクリプションURL全体や、機密情報を隠していない設定ファイルは送らないでください。
4. 回線側：ネットワークを切り替えて混雑箇所を特定する
元のノードに戻し、まず自宅のネットワークで測定した後、スマートフォンのテザリングでも同じリクエストを試します。テザリングでは通信事業者、無線品質、接続経路が変わるため、絶対的な基準ではなく比較材料として使ってください。大容量ファイルの測定はデータ通信量を消費します。契約プランを確認し、測定時間を抑えましょう。
| 比較結果 | 考えられる原因 | 次に試すこと |
|---|---|---|
| 同じノードがテザリングでは正常だが、自宅では遅い | Wi-Fi、ルーター、または接続回線 | 有線LANで再測定し、ルーターで帯域を使用するタスクを一時停止する |
| 同じネットワークで特定のノードだけ遅い | そのノード、またはノードまでの特定の回線 | 別のノードと比較し、時間帯と接続先アドレスを記録する |
| 2つのネットワークで、すべてのノードが遅い | 端末の設定、または共通の接続先サービス | 別の接続先サービスを試し、別の端末でも比較する |
| Wi-Fiでは遅いが、有線LANなら正常 | Wi-Fiの干渉、または電波状態 | アクセスポイントの近くで測定し、周波数帯と無線の再送状況を確認する |
通常のpingでのパケットロスを、プロキシ経由の通信におけるパケットロスと同一視しないでください。接続先がICMPを制限している場合があり、実際の通信とは経路が異なることもあります。小さなリクエストは成功するのに大きな応答が頻繁に止まる場合は、MTU、経路MTU探索、TUNの設定を確認します。比較結果がないまま「汎用MTU」を設定すると、断片化や互換性の問題を招くおそれがあります。
5. 端末側：プロキシモード、DNS、通信方式を確認する
システムプロキシが影響するのは、システムのプロキシ設定に従うアプリだけです。TUNは仮想ネットワークインターフェースを通じて、条件に一致する通信を取り込みます。通信を取り込む範囲が異なるため、ブラウザーでWebページを開けるだけでは、ゲーム、ダウンロードアプリ、すべてのUDP通信がプロキシ経由だとは限りません。速度を比較する前に、ログで接続先ドメインと出力タグを確認してください。
- v2rayNのメイン画面で「システムプロキシ」→「システムプロキシを自動設定」を選び、ブラウザーでアクセスを試します。システムプロキシのみの比較では、先にTUNを無効にし、ブラウザー側で別のプロキシを指定していないことも確認してください。
- TUNを試す場合は、まず現在の状態を記録します。「システムプロキシ」→「システムプロキシを解除」を選んでからTUNを有効にし、ルーティングとログを確認してください。モードを分けると原因を特定しやすくなりますが、両方を同時に有効にすると必ずプロキシループになるわけではありません。
- Androidでは、システムのVPN許可とアプリごとの振り分け範囲を確認します。v2rayNGやv2flyNGで測定対象のアプリが除外されている場合、その結果をノードの性能評価に使うことはできません。対象アプリの範囲を変更したら、接続し直してください。
- ドメインへの初回リクエストと、キャッシュ後のリクエストを比較します。ノードサーバーのドメイン自体が名前解決できることに加え、接続先ドメインを端末、コア、リモート側のどこで解決しているかも確認してください。それぞれ異なる段階の処理であり、DNSアドレスを一つ変えるだけですべて解決するとは限りません。
ルーティングのdomainStrategyは、IPルールとの照合時にドメインを名前解決するかどうかを決める設定で、「高速化スイッチ」ではありません。たとえばIPIfNonMatchは、ドメインルールに一致しない場合に名前解決を試み、IPルールの判定に使用します。この名前解決経路に問題があると、待ち時間が増えることがあります。この項目はroutingに属し、個別のrulesルール内には記述できません。変更前に、直結とプロキシの出力タグ、DNSルーティング、地理データファイルが利用可能か確認してください。
端末のリソース使用状況も確認してください。同じダウンロード中にCPU使用率が高止まりし、ネットワークを変えても改善しない場合に限り、端末の処理能力や他のプログラムとの競合を検討します。追加のトラフィック解析を終了し、ログレベルを通常に戻してください。既存のセキュリティ検証設定は維持し、速度を上げるために証明書の検証を無効にしてはいけません。
6. Muxの比較とログエラーへの対処
Muxは、複数の論理接続を少数の基盤接続に多重化します。接続を頻繁に確立するコストを減らせる一方、複数のリクエストが同じ基盤接続の混雑の影響を受けることもあります。帯域を倍増させる機能ではありません。大容量ファイルの転送、パケットロスがある回線、通信方式の組み合わせによって結果は異なるため、遅延測定だけでなく実際の利用状況で比較してください。
- まず無効状態を測定：現在のMux設定を記録し、無効にしてから接続し直します。その後、Webページの初回表示と単一ファイルのダウンロードを測定してください。接続を作り直していない場合、以前の設定の影響が残る可能性があります。
- 次に有効状態を測定：現在のコア、出力プロトコル、通信方式の組み合わせが対応している場合に限り有効にし、それ以外の条件は変えません。クライアントに適合した設定を使い、別のコア向けのMux設定項目をそのまま流用しないでください。
- 有効な結果を記録：有効にするとWebページは速くなる一方、ダウンロードが遅くなる場合は、主な用途に応じて選んでください。互換性に関する警告が出たら、まず無効状態に戻します。問題を隠すために同時接続数を増やし続けないでください。
速度低下にエラーが伴う場合は、まずログから失敗した段階を特定します。以下はよくあるエラー例です。ログの完全な先頭部分は、コア、OS、呼び出し箇所によって異なります。エラーに含まれるアドレス、ポート、前後の状況を確認し、一つの語句だけを見て設定をすべて変更しないでください。
エラー：connection refused
原因：接続先のポートが接続を拒否しています。アドレスがローカルのループバックアドレスなら、ノードの帯域より先にローカルの待ち受け状態を確認してください。
対処：ログにあるアドレスとポートを確認し、コアが動作しているか確かめます。リモートサーバーの場合は、ノードのポートとサーバー側の待ち受け状態も確認してください。
エラー：context deadline exceeded
原因：処理が制限時間内に完了しませんでした。名前解決、接続、ハンドシェイク、応答待ちのいずれが原因かは、このメッセージだけでは判断できません。
対処：前後のログを確認して失敗した段階を特定します。同じノードでネットワークを変える比較と、同じネットワークでノードを変える比較を行い、タイムアウト時間を延ばすだけで済ませないでください。
エラー：no such host
原因：照会したホスト名を有効なアドレスに解決できませんでした。名前の誤り、または現在の名前解決経路の問題が考えられます。
対処：エラーの対象がノードのドメインか接続先のドメインかを確認し、綴りとDNSへの接続性を調べます。修正後に再接続し、ページの初回表示時間を確認してください。
7. 速度低下のよくある質問
遅延は数十ミリ秒なのに、ダウンロードが遅いのはなぜ？
遅延はリクエストの往復にかかる時間、スループットは継続的なデータ転送能力を示します。ノードは変えずに2つの配布元からダウンロードし、それぞれ30秒間観察します。その後、ノードを変えて同じ測定を行ってください。一方の配布元だけ遅いなら、遅延の数値をさらに下げるより、まず接続先の速度制限を確認しましょう。
DNSを変更すれば、動画が必ず止まらなくなる？
DNSが主に影響するのは名前解決と接続先アドレスの選択です。混雑した回線の帯域を増やすことはできません。動画の再生開始までの待ち時間と、再生開始後の継続的な読み込み状況を分けて確認します。再生はすぐ始まるのに何度もバッファリングする場合は、ノードと回線を比較し、実際の接続に使われた出力タグも確認してください。
TUNを有効にすると、システムプロキシより遅くなるのはなぜ？
TUNではバックグラウンド通信をより多く取り込む場合があり、DNSやルーティング経路が変わることもあります。まずバックグラウンドのダウンロードを一時停止し、「システムプロキシのみ」と「TUNのみ」をそれぞれ測定してください。TUNだけに問題がある場合は、サブスクリプションをすぐに変更するのではなく、アプリの振り分け、DNS経路、仮想ネットワークアダプターの設定を確認します。
コアを変更すれば、速度低下の問題をすべて解決できる？
いいえ。まずノードで必要なプロトコルや機能が、選択したコアに対応しているか確認し、設定を保存したうえで比較してください。サーバーがREALITYや特定のXTLS動作を要求する場合、Xrayの設定をそのままV2Flyに渡すことはできません。回線の混雑やノードの出口制限は、クライアント名を変えても自動的には解消しません。
確認後は、「特定のノードが複数のネットワークで遅い」「特定の接続回線では複数のノードが遅い」「特定の端末モードだけ遅い」など、再現可能な結論まで原因を絞り込めているはずです。元の記録と有効な設定を残し、テスト中に追加した一時ルールは削除してください。問い合わせが必要な場合は、個人情報を伏せたログと比較条件を添え、次の確認を証拠に基づいて進められるようにします。