接続はできるものの、ウェブページの表示が遅い、またはダウンロード速度が安定しない場合に役立つ内容です。測定対象とローカルプロキシの入口を固定し、ノードの比較、ネットワークの切り替え、ログの確認を通じて、原因をノードの出口、接続回線、端末の設定に絞り込みます。最後にDNS、ルーティング、Muxを個別に検証し、一度に複数の設定を変えて原因が分からなくなるのを防ぎます。
1. ページ表示の遅さ・ダウンロードの遅さ・断続的な切断を見分ける
「遅延は80ミリ秒なのに、なぜダウンロードが遅いのか」と疑問に思うかもしれませんが、両者は矛盾しません。クライアントの遅延テストは通常、特定の接続やリクエストだけを測るもので、継続的な通信速度を示すものではありません。ノード一覧に表示される速度も、測定先や測定時間、同時接続数によって変わります。まず症状を確認してから測定項目を決めるほうが、遅延順に並べて何度も切り替えるより効果的です。
| 症状 | 優先して確認する項目 | 最初に行う比較 |
|---|---|---|
| 初回表示まで数秒かかるが、再読み込みすると明らかに速い | ドメインの名前解決、接続の確立、接続先からの応答 | 同じドメインに連続してアクセスし、最初の1バイトが届くまでの時間を記録する |
| ページは表示できるが、大容量ファイルのダウンロードがずっと遅い | ノード出口の容量、回線の実効速度、速度制限 | ローカル設定は変えず、同じファイルを別のノードでダウンロードする |
| 夜は遅いが、日中は改善する | 共有ノードの負荷、接続ネットワークの混雑 | 同じノード・同じ測定先で時間帯を変えて再測定する |
| すべてのノードで接続が途切れる | 無線LAN、ルーター、ほかのトンネル型ソフトウェア | 有線LANまたは別の接続ネットワークに切り替える |
測定前にクラウドストレージの同期、システム更新、ほかのダウンロードを一時停止し、ブラウザーに追加したプロキシ拡張機能も無効にします。普段使うウェブページと、ダウンロード可能な大きめのファイルを1つずつ選んでください。対象ファイルはできるだけ同じURLから取得します。ウェブサイトごとにサーバー、キャッシュ、速度制限の方針が異なるため、別々のサイトの速度をそのまま比べることはできません。
これらの数値は切り分けのための測定目安であり、ノードの実測性能や合格基準ではありません。単位もそろえてください。ダウンロードソフトに表示される10 MB/sは、十進法で換算すると約80 Mbpsです。回線の公称速度はリンクの上限であり、実際のファイル転送速度はプロトコルのオーバーヘッド、無線信号、接続先サービスの制限にも左右されます。
2. ノードを確認する：負荷と出口を比較し、プロトコル名だけで判断しない
まず同じサブスクリプション内から、出口の異なるノードを2つ選びます。ルーティングモード、測定対象、測定時間帯はできるだけそろえてください。1つのノードだけが遅い場合は、そのノードの出口帯域、共有負荷、測定先までの経路に原因がある可能性があります。両方が遅い場合は、別の提供元の利用可能なノードでも比較し、同じ上流回線の問題をすべてのノードの問題と取り違えないようにします。
- 現在の状態を記録：ノード名、プロトコル、トランスポート方式、測定時間帯、ダウンロード速度の中央値を記録します。記録を共有する際は、サーバーアドレス、ユーザーID、サブスクリプションURLを削除してください。
- 測定対象を固定：v2rayNで使用中のサーバーを切り替えたら、ダウンロードを最初からやり直します。以前の長時間接続は使い続けず、必要に応じてブラウザーを完全に終了してから再起動してください。
- 別の接続先でも確認：同じノードで、互いに異なる2つのウェブサイトを測定します。一方だけが遅い場合は、ノードの出口からそのサイトまでの接続経路、またはサイト側の制限が考えられます。
- 端末の負荷を確認：タスクマネージャーまたはアクティビティモニタを確認します。コアプロセスがCPUを継続的に大量消費している場合は、まず端末の性能がボトルネックになっていないか調べます。すぐにリモートサーバーの問題と決めつけないでください。
VMessとVLESSはプロキシプロトコルの名称です。TCP、WebSocket、gRPCなどはトランスポート関連の設定であり、TLSは通信の一部を保護します。これらは互いに置き換えられる「高速化モード」ではありません。同じプロトコルでも、入口や出口が異なれば速度は大きく変わることがあります。トランスポート方式、パス、TLSパラメーターを変更する場合はサーバー側と一致させる必要があり、ローカル側だけで任意に切り替えてはいけません。
ポイント：まず「遅いのは1つのノードだけか」を確認する
同じ端末、同じネットワーク、同じ測定先で、出口を切り替えた後に3回続けて明らかに改善した場合は、速いノードをそのまま使い、測定時刻と対象を添えて提供元に連絡します。DNS、Mux、システムのネットワーク設定をすぐに変更する必要はありません。
3. 回線を確認する：接続ネットワークを切り替えて混雑箇所を特定する
ノードに接続できても、ノードまでの回線が安定しているとは限りません。無線干渉、家庭用ルーターの負荷、通信事業者間の接続、夜間の混雑などにより、再送が増えて通信速度が低下することがあります。最も有効なのは、同じパソコン・同じノードのまま接続ネットワークを切り替えて比較することです。たとえば、家庭の固定回線からスマートフォンのテザリングに切り替えます。ノードとネットワークを同時に変更するより、結果を判断しやすくなります。
- まずローカルネットワークを確認：Windowsでは
ipconfigでデフォルトゲートウェイを確認します。macOSでは「システム設定」→「ネットワーク」で、接続中のルーターのアドレスを確認できます。そのアドレスへの接続をテストし、ローカルの無線LANが安定しているか調べてください。 - 次にノードの入口を確認：プローブが許可されているノードアドレスに対して疎通テストを行います。ノードがICMPに応答しなくても、プロキシ接続の失敗を意味するとは限りません。実際のTCP接続とクライアントログもあわせて確認してください。
- 最後に接続ネットワークを切り替える：使用中のほかのトンネル接続を終了してから、テザリングに切り替えて再測定します。テザリングと固定回線では同じノード、同じダウンロードURLを使用し、接続が再確立されたかどうかも記録してください。
# Windows：以下のアドレスを実際のデフォルトゲートウェイに置き換える
ping -n 30 192.168.1.1
# macOS：以下のアドレスを実際のデフォルトゲートウェイに置き換える
ping -c 30 192.168.1.1ここに示した192.168.1.1はよく使われるゲートウェイアドレスの一例です。必ず端末に実際に表示される値を使ってください。ゲートウェイへの接続も繰り返しタイムアウトする場合は、ルーターに近づくか有線LANに切り替えます。ゲートウェイが安定していて外部への接続だけがすべて遅い場合は、外部経路を確認します。一度のタイムアウトや、途中にある1台のルーターでの高いパケットロスだけを根拠に回線障害と判断しないでください。一部の機器は測定用パケットへの応答優先度を下げています。
ポイント：同じノードでネットワークを切り替えて改善したら、まず接続経路を確認する
家庭の固定回線では遅く、テザリングでは正常な場合は、ノード設定を変えずに無線環境と通信事業者の経路を確認してください。どちらの接続ネットワークでも特定のノードだけが遅い場合は、原因はそのノードにある可能性が高く、端末のネットワーク設定を何度もリセットする必要はありません。
4. ローカルの入口を確認する：測定リクエストが本当にプロキシを経由しているか
ブラウザー、コマンドライン、システムアプリが同じプロキシ設定を使うとは限りません。v2rayNのシステムプロキシが影響するのは、主にシステムプロキシ設定を参照するアプリです。TUNモードは別のトラフィック転送方式です。切り分けでは、まず入口を1つに決めてください。ブラウザー拡張機能のプロキシ、システムプロキシ、別のトンネルルールを同時に重ねないようにします。
- v2rayNの「設定」→「パラメーター設定」を開き、ローカルのリスニングアドレス、ポート、インバウンドの種類を確認します。バージョンによっては関連項目が基本設定にあるため、現在の画面に表示される項目名を確認してください。
- 以下のコマンドでは、
127.0.0.1:10808をSOCKSが有効なローカル入口として想定しています。実際のポートが異なる場合は、先にコマンドを修正してください。HTTPのみを提供する入口では、このSOCKS用コマンドは使えません。 - 使用中のノードを選び、測定対象への接続記録がログに出るか確認します。リクエストを1回実行した後、ブラウザーでアクセスした結果と比較してください。
# Windows PowerShell
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} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/
# macOS ターミナル
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/example.comは、ここでは小さなページへのリクエスト例として使っているだけで、帯域測定用のサーバーではありません。socks5hを使うと、curlがローカルで名前解決するのではなく、接続先のホスト名をSOCKSプロキシに渡して処理します。ただし、これだけで最終的にカーネルが使用するDNSサーバーが決まるわけではありません。ローカルプロキシ経由の場合、time_connectが主に示すのはローカルプロキシ入口への接続時間であり、ノードまでの往復遅延ではありません。time_starttransferには、その後のプロキシネゴシエーション、リモート接続、サービスからの応答などにかかる時間も含まれます。
curl: (7) Failed to connect
原因：ローカルのリスニングが開始されていない、アドレスまたはポートが誤っている場合によく見られます。詳細なログで接続先を確認できます。対処：まずカーネルが起動していることを確認し、パラメーター設定に表示されたポートを入力して、インバウンドのプロトコルも確認してください。
curl: (28) Operation timed out
原因：設定された時間内にリクエストが完了していません。ノードへの接続、名前解決、接続先からの応答などが関係している可能性があり、この1行だけでは原因を特定できません。対処：同じ時刻のカーネルログと照らし合わせ、測定先、ノードの順に変更して確認します。タイムアウト値を大きくするだけで済ませないでください。
dial tcp: lookup
原因：Go系カーネルの名前解決失敗ログによく見られる断片です。原因特定には、後に続くドメイン名とエラー情報が必要です。対処：まず解決に失敗したのがノードのサーバー名かアクセス先のドメイン名かを確認し、該当するDNS経路とネットワークへの到達性を調べてください。
5. DNSとルーティングを確認する：DNS設定を変える前に、通信経路を把握する
ウェブページの初回表示が遅い場合はDNSも確認する価値がありますが、速度低下の原因がすべてDNSとは限りません。連続ダウンロードが始まった後でDNSだけを変更しても、通常は同じ接続の通信速度は直接上がりません。名前解決の結果が変わることで、後続の接続先アドレスが変わる場合は別の影響です。まず「名前解決に時間がかかる」のか「接続後の転送が遅い」のかを切り分けます。
| 確認する箇所 | 確認すべき内容 | よくある誤解 |
|---|---|---|
| ノードのサーバーアドレス | プロキシ接続前に、サーバーのドメイン名を利用可能な経路で名前解決できるか | ノード自体の名前解決も、まだ確立していないプロキシ経由に設定する |
| 接続先ドメインの名前解決 | アプリ、ローカルシステム、カーネルのどれが処理するか、想定どおりか | システムDNSだけを変更し、プロキシ側で名前解決した結果と比較する |
| ルール設定 | 接続先に適用されるルールと、実際に使われるアウトバウンドタグ | システムプロキシを有効にすれば、すべてのリクエストが同じ出口を使うと思い込む |
| ブラウザーのセキュアDNS | ブラウザーが別途、暗号化された名前解決リクエストを送信しているか | ブラウザーとコマンドラインで名前解決の挙動が異なることを、ランダムな障害だと考える |
v2rayNの「設定」→「ルーティング設定」で、現在有効なルールセットを確認します。バージョンによって画面の場所が変わる場合は、「ルーティング設定」という項目名を探してください。V2Ray/Xrayのルーティングルールは通常、上から順に照合されます。outboundTagは、定義済みのアウトバウンドタグに対応している必要があります。ログ上で接続先が直接接続のアウトバウンドに送られている場合は、プロキシノードを何度も切り替えるのではなく、まずルールを確認してください。
- 現在のルールを先にバックアップします。一時的に調整する場合は、テスト対象のドメインを1つだけ指定し、確認後に元に戻してください。ルーティング全体を変更すると、結果の判断が難しくなります。
- DNSサーバー自体に到達できるか確認します。暗号化DNSを設定する場合は、そのサーバーのドメイン名を初回にどう解決するか、接続を直接行うかプロキシ経由にするかも確認してください。
- Windowsの
ipconfig /flushdnsで消去できるのはシステムのDNSキャッシュだけです。ブラウザーやカーネルのキャッシュも同時に消去されるとは限りません。必要に応じてブラウザーを終了し、カーネルを再起動してからリクエストをやり直してください。
6. Muxを確認する：まず無効にして基準を測り、必要性を判断する
Muxは接続を多重化する機能であり、ノードの帯域を増やすものではありません。短時間の接続を大量に確立する際のコストを減らす可能性がある一方、複数の論理接続が基盤となる通信のブロッキングの影響を共有することもあります。大容量ファイルの連続ダウンロードで効果があるとは限りません。実際の効果はカーネルの実装、ノードのプロトコル、トランスポート設定にも左右されるため、特定の同時接続数を万能の最適値と考えないでください。
- 現在の設定を記録：クライアント、カーネル、ノードそれぞれのMuxの状態を記録します。クライアントのバージョンとカーネルのバージョンは別の情報です。問い合わせ時にはそれぞれ記録してください。
- 無効にして再測定：v2rayNの「設定」→「パラメーター設定」でMux関連の項目を探します。項目が見当たらない場合は、設定フィールドを推測で追加せず、現在のカーネルと設定形式が対応しているか確認してください。
- 変更の反映を確認：保存後にカーネルを再起動し、テスト接続を新しく確立します。サブスクリプションのノード、個別ノードの設定、カスタム設定では、変更が反映される範囲が異なる場合があります。実際に生成された設定とログを確認してください。
- 用途ごとに比較：同じ条件で3回繰り返し、短いページの読み込みと連続ダウンロードをそれぞれ記録します。無効にした後に切断が減り、普段の利用も改善するなら、そのまま無効にしておきましょう。設定を複雑にするためだけに再び有効にする必要はありません。
7. よくある質問と確認のまとめ
遅延が最も低いノードほどダウンロードが遅い場合、どれを選べばよいですか？
用途に合わせて選びます。動画視聴や大容量ファイルのダウンロードでは、持続的な通信速度と切断の有無を優先します。対話的な操作では応答時間も重要です。同じファイルを固定して各ノードで3回測定し、1回の遅延結果だけで総合順位を決めないでください。
速度測定では十分な速度が出るのに、ブラウザーでの表示だけ遅い場合は？
まずブラウザーのプロキシ拡張機能、セキュアDNS、接続の再利用を確認します。ブラウザーを完全に終了してから再試行し、ローカルプロキシを明示的に指定したcurlのリクエストと比較してください。特定のウェブサイトだけが遅い場合は、そのサイトとノード出口の間の経路を確認します。
Androidのスマートフォンでも遅い場合、パソコンの設定をそのまま使えますか？
切り分けの順序は共通ですが、ローカルポートやトラフィックの転送方式をそのまま流用しないでください。v2rayNGはXrayカーネルを、v2flyNGはv2flyカーネルを使用します。まず同じWi-Fiで、同等のノードと測定先を使って比較し、ほかのトンネルや省電力制限が重なっていないか確認してください。
夜だけ遅い場合、MuxやDNSの設定で解決できますか？
まず同じノードで日中と夜間を比較し、次に夜間に接続ネットワークまたは別の提供元のノードを変えて確認します。時間帯や経路によって遅くなる場合は、混雑や共有帯域が原因として考えられます。初回表示時の名前解決だけが異常に遅い場合に限り、DNSを個別に検証してください。
切り分けが終わったら、発生時刻、クライアントとカーネルのバージョン、接続ネットワーク、ノード名、接続先ドメイン、3回分の測定結果、実際のアウトバウンド、エラー部分を簡潔に記録しておきます。提供元に送る前に、サブスクリプションURL、ユーザーID、サーバーの機密情報を隠してください。「同じノードでテザリングに切り替えたら改善した」「同じネットワークで出口を変えたら改善した」と説明すると、「速度が遅い」とだけ伝えるより原因を特定しやすくなります。
- ノードによって差がある：使える出口を維持し、遅いノードの時間帯と測定先を伝える。
- 回線によって差がある：無線ネットワークまたは接続経路を見直し、プロトコルをむやみに変更しない。
- ローカル設定によって差がある：関係のない変更は元に戻し、繰り返しの測定で効果を確認できた設定だけを残す。