まず、接続できないのか、Webページの表示開始が遅いのか、ダウンロードが継続的に遅いのかを切り分けます。次に、テスト対象のノードとネットワークを固定し、最後に端末側のプロキシ、DNS、ルーティング、Muxを確認します。サブスクリプションを登録済みで接続はできるものの、速度が安定しないv2rayNユーザー向けの手順です。順番に結果を記録すれば原因を絞り込みやすくなり、複数の設定を同時に変更して効果が分からなくなるのを防げます。
1. 速度測定の基準を作る：遅延の数値だけで判断しない
TCP遅延が示すのは、接続確立にかかる時間の一部であり、ノードが継続してどれだけデータを転送できるかではありません。プロキシ経由のリクエストに近いのは実接続遅延ですが、テスト先やDNS、接続先サイトの応答にも左右されます。遅延が小さくても帯域が不足しているノードもあれば、遅延が大きくても安定したスループットを維持できるノードもあります。
ダウンロード、クラウドストレージの同期、システム更新をいったん停止し、アクセス権のあるHTTPSダウンロード先を1つ決めます。同じ端末、同じネットワーク、同じ時間帯で測定してください。以下の数値はテスト条件とポートの例であり、本サイトによる実測値やクライアントの性能保証ではありません。
-
現在の設定を記録する
「ヘルプ」→「バージョン情報」でクライアントのバージョンを記録します。「設定」→「パラメータ設定」で現在のコア、待ち受けポート、Muxの状態を記録し、メイン画面のルーティングモードも控えてください。設定画面の項目名や配置はバージョンによって異なる場合があります。実際の画面で確認し、この記事に合わせるためにポートを変更しないでください。
-
プロキシの入口を固定する
まずTUNを無効にし、システムプロキシで基本の切り分けを行います。トレイメニューの「システムプロキシ」→「システムプロキシを自動設定」を有効にし、システムプロキシを書き換えるほかのアプリは終了してください。その後の比較では、同じプロキシモードを維持します。
-
候補ノードを選ぶ
サーバー一覧から候補を選び、右クリックして「サーバーの実接続遅延をテスト」を実行します。テストするノードをアクティブサーバーに設定し、同じダウンロード先を1つずつ試してください。一括遅延テストの結果をダウンロード帯域の測定値と混同しないようにしましょう。
-
3種類の時間・速度を記録する
接続できるか、Webページの表示開始までの様子、継続ダウンロード速度をそれぞれ記録します。ノードを切り替えるたびにリクエストをやり直し、ブラウザーが以前の接続を再利用しないようにしてください。単位も記録します。1 MB/sは約8 Mbpsです。
2. ノードを確認する：特定ノードの混雑か接続先の速度制限か
同じネットワークのままノードを切り替え、DNS、プロトコル、ルーティングは同時に変更しないでください。出口の異なる利用可能なノードを2つ選び、同じダウンロード先で比較します。次に、一方のノードを固定して、別のダウンロード先を試します。これにより、問題がノードに起因するのか、特定の接続先だけで起きるのかを切り分けられます。
| 観察結果 | まず疑う原因 | 次に行うこと |
|---|---|---|
| 特定のノードだけ継続して遅い | そのノードの負荷、速度制限、または特定の回線 | 端末の設定は変えず、別の出口に切り替えて再測定する |
| 複数のノードが夜間だけ遅い | 共有回線の混雑、またはサーバー側のピーク時負荷 | 同じダウンロード先を異なる時間帯に測定し、結果を記録する |
| 特定のサイトからのダウンロードだけ遅い | 接続先サイトの速度制限、出口との相互接続、またはコンテンツ配信の違い | 別の接続先で試し、アカウントや単一接続の制限も確認する |
| すべてのノードが遅く、直接接続も遅い | ローカル回線、無線干渉、または帯域の占有 | まず有線接続と、LAN内のほかの端末を確認する |
サブスクリプションの更新で行われるのはサーバー設定の更新であり、ノードの帯域が自動的に増えるわけではありません。ノード名に含まれる地域名、倍率、回線の表記も、実測の代わりにはなりません。サブスクリプション提供元がアカウントごとに速度、通信量、同時接続数を制限している場合は、サービスの説明を確認してください。こうした制限はクライアントだけでは解除できません。
まとめ：比較に使える条件を維持する
ノードを切り替えるだけで速度が繰り返し回復するなら、安定しているノードを使い、比較結果を記録しておきましょう。すぐにクライアント全体をリセットする必要はありません。ノードごとの差を、特定のプロトコル名だけに結び付けないでください。
3. 回線を確認する：有線接続とテザリングで切り分ける
通信経路には、端末からルーターまで、プロバイダーのアクセス回線、異なるネットワーク間の回線、ノードの出口が含まれます。Wi-Fiの電波が最大でも、通信が安定しているとは限りません。同じアクセスポイントにつながる別の端末がアップロード帯域を使い切ると、Webリクエストが滞ることもあります。測定中はタスクマネージャーでネットワーク使用量を確認し、まず端末のバックグラウンド通信を除外してください。
- 有線に切り替える：ノードと接続先はそのままに、Wi-Fiから有線接続に切り替えます。有線で安定する場合は、Wi-Fiの干渉、周波数帯、ルーターの負荷を優先して確認してください。
- テザリングに切り替える：同じPCをスマートフォンのテザリングに接続します。明らかに改善する場合は、元のアクセス回線を引き続き確認する価値があります。ただし、一度の結果だけでプロバイダーによる制限と断定することはできません。
- 継続時の速度を見る：60秒間の変化を確認します。開始直後は速く、その後低下する場合、キャッシュ、一時的な帯域の増加、速度制限、混雑などが考えられます。瞬間的なピーク値だけを記録しないでください。
- パケットロスを確認する：Windowsで
ping -n 30 192.168.1.1を実行し、ローカルゲートウェイを確認します。実際のゲートウェイがこのアドレスの場合に限り使用し、異なる場合は端末のデフォルトゲートウェイに置き換えてください。
4. ローカルプロキシ、DNS、ルーティングを確認する：表示開始の遅さや誤った経路を調べる
Webページの表示開始まで時間がかかる一方、ダウンロード開始後の速度は正常な場合、名前解決と接続確立を優先して確認します。ダウンロードも継続して遅い場合は、回線とリソース使用量を調べてください。システムプロキシの影響を受けるのは、その設定に従うアプリだけです。ブラウザー拡張機能、アプリ独自のプロキシ、TUNによって実際の通信経路が変わることがあります。
- 「設定」→「パラメータ設定」を開き、ローカルの待ち受けポートを確認します。以下のコマンドは
127.0.0.1:10808がSOCKS接続を受け付けることを前提としています。現在のポートがHTTP接続のみを受け付ける場合、SOCKSの指定をそのまま使わないでください。 - Windowsターミナルで以下のコマンドを実行します。レスポンスヘッダーを取得してリクエスト段階を調べるもので、ダウンロード帯域の測定には使いません。接続先の例は
https://example.com/です。 - 1つ目は
socks5hを使い、接続先のドメイン名の解決をSOCKS経由でプロキシ側に任せます。2つ目はsocks5を使い、端末側で接続先のドメイン名を解決します。交互に繰り返し比較し、キャッシュやサイト側の変動をDNSの問題と誤認しないようにしてください。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/
curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/両者の差が安定している場合は、「設定」→「DNS設定」で現在のコアに対応する名前解決ポリシーを確認します。リモートでの名前解決も、コアのDNS設定やルーティング設定の影響を受けます。すべての欄に同じパブリックDNSアドレスを入力すれば解決する、とは限りません。ノードサーバーのアドレス自体にも利用可能な名前解決経路が必要です。「プロキシに接続するために、まずプロキシ経由でサーバーを名前解決する」という循環依存を避けてください。
メイン画面で現在のルーティングモードを確認し、「設定」→「ルーティング設定」でカスタムルールを確認します。問題のサイト1つに対して一時的にグローバルプロキシを適用して比較し、テスト後は元のモードに戻してください。この状態で正常になる場合は、そのサイトが誤って直接接続のルールに一致していないか、DNSの応答アドレスがIPルールの判定に影響していないかを確認します。ルールは通常、上から順に照合されるため、範囲の広い前方のルールが後続のルールに優先することがあります。
5. 通信プロトコルとMux：変更する項目は一度に1つ
VMessとVLESSはプロキシプロトコル、TCP、WebSocket、gRPCなどはトランスポート関連の設定で、TLSはさらに別のレイヤーです。サーバーから提供されたWebSocketノードを、クライアント側で任意のトランスポートに変更することはできません。パス、Host、SNI、ポート、サーバー側の待ち受け設定が一致しなければ、速度向上ではなく接続失敗につながるのが一般的です。
- まずはサブスクリプションの設定を使う：サーバーが指定したトランスポート設定を維持します。サーバー側が複数の接続先を明示的に提供している場合に限り、同じテスト条件で比較してください。
- Muxだけを比較する：「設定」→「パラメータ設定」で、現在のコアのMux設定を確認します。元の値を記録してから無効にし、コアを再起動するかアクティブサーバーを切り替えて、テスト接続を新たに確立してください。
- 用途ごとに考える：Muxは複数の論理接続で下位の接続を共有できるため、短時間の接続に伴う負荷を減らせる場合があります。長時間のダウンロードでは、効果がはっきりしないこともあります。また、信頼性のあるバイトストリームを使う一部の多重化方式では、パケットロスによる待ち時間が複数のリクエストに波及することがあります。
- 並列数をむやみに増やさない：並列数は多いほど速くなるわけではありません。ノード、コア、トランスポートの組み合わせによって対応状況は異なります。明確な効果がなければ元の値に戻し、Mux、分割転送、DNSを同時に調整しないでください。
CPUとメモリの使用状況も確認します。通信中に特定のコアが継続して高負荷になり、ネットワークやノードを切り替えてもほとんど変化がない場合は、コアのバージョン、過剰なログ出力、ほかのネットワークフィルターソフト、バックグラウンドプロセスを確認してください。クライアントやコアを更新する前に設定をバックアップし、該当バージョンのリリースノートを読んでください。速度を理由にファイアウォールを無効化したり、証明書の検証を回避したりしないでください。
6. ログのエラーを確認する：接続障害と速度低下を分けて考える
接続の再試行が繰り返されると、Webページの表示が遅くなることもあります。クライアントのログを開き、まず発生時刻を手掛かりに、連続して記録された失敗の原因を探してください。以下はログに記録されることがあるエラーの一部です。ログの前後の内容はコアやOSによって異なるため、1回のエラーだけで判断せず、前後の状況も確認してください。
エラー：context deadline exceeded
原因と対処：処理が制限時間内に完了しなかった状態です。名前解決、接続、応答待ちのいずれかで発生している可能性があります。前後のログから対象を特定し、同じノードで接続先を変える方法と、同じ接続先でノードを変える方法で切り分けてください。タイムアウト時間を延ばすだけでは解決しません。
エラー：connection refused
原因と対処：接続先または中継機器によって接続が明示的に拒否されています。ログに記録されたアドレスとポートを確認してください。ローカルのプロキシアドレスの場合は、コアが動作中か、アプリ側で正しいポートを指定しているかを確認します。サーバーアドレスの場合は、サブスクリプションの設定とサーバー側の待ち受けを確認してください。
エラー：lookup ...: no such host
原因と対処：ドメイン名の解決で有効な結果を取得できていません。解決に失敗したドメインがノードサーバーのものか、アクセス先のものかを確認し、スペル、DNS設定、名前解決の経路を見直してから、リクエストをやり直してください。
7. よくある質問：症状に合わせて設定を絞り込む
遅延は小さいのに、ダウンロードが遅いのはなぜ？
遅延とスループットは別の指標です。そのノードをアクティブサーバーに設定し、同じ接続先から60秒間ダウンロードして変化を確認します。次に、別のノードと別の接続先で試してください。特定の接続先だけ遅い場合は、まず接続先側の速度制限を確認します。複数の接続先が遅い場合は、ノードの帯域と回線を調べてください。
グローバルプロキシを有効にすると速くなります。そのまま使い続けてもよいですか？
まずはルーティングの比較テストとして扱い、そのまま最終的な解決策にしないでください。元のモードに戻し、「設定」→「ルーティング設定」で対象ドメインに適用されるルールを確認し、ログで送信先も確認します。誤った振り分けを修正したら、通常の使用モードで再テストしてください。
速度測定は速いのに、ブラウザーでWebページを開くと遅いのはなぜ？
まず、ブラウザー独自のプロキシ拡張機能を無効にし、ターミナルからローカルプロキシを明示してリクエストを比較します。ターミナルでは正常な場合、ブラウザーのセキュアDNS、キャッシュ、接続の再利用を確認してください。ターミナルでも遅い場合は、コアのDNSとルーティングを引き続き確認します。
DNSとMuxを変更しても、原因を切り分けられません。どうすればよいですか？
記録した基準設定に戻し、ノード、接続ネットワーク、DNS、Muxの順に、一度に1項目だけ変更します。各回の結果を3回分とテスト時刻をあわせて記録してください。繰り返し確認できる改善だけを採用し、たまたま出たピーク値を有効な結論とみなさないでください。