Clashのノード遅延測定の仕組み｜測定値と実際の通信速度が異なる理由

ノード一覧のミリ秒表示が測っているのは、1回のリクエスト

Clashクライアントでいう「遅延テスト」とは、通常、指定したノード経由でカーネルがテスト用URLにアクセスし、その応答にかかった時間をミリ秒で表示するものです。大容量ファイルを継続してダウンロードする帯域幅テストではなく、小規模なHTTPリクエストの応答時間を測っています。ノードの横に「80 ms」と表示されても、わかるのはそのテストが短時間で完了したことだけで、1秒あたり何MBダウンロードできるかは判断できません。

ボタンや一覧、結果表示を担当するのはクライアントで、実際の接続を行うのはClashまたはClash Meta（現在は一般にmihomoと呼ばれます）のカーネルです。クライアントやカーネルのバージョンによって、テストの実装、計測範囲、結果のキャッシュ方法が異なる場合があり、画面に表示された数値を単純に比較できるとは限りません。まずテストURLと測定方法が同じか確認してから、ノードの速度を比べましょう。

一般的な遅延テストの流れ

1. ユーザーがノードの遅延テストを実行するか、プロキシグループが定期チェックを開始すると、カーネルにテストタスクが渡されます。
2. カーネルは指定されたプロキシノードへの接続を開始します。ノードのホスト名を先に名前解決したり、プロキシプロトコルのハンドシェイクを行ったりする場合もあります。
3. プロキシサーバー経由でテストサイトにアクセスします。HTTPSの場合は、接続先サイトとのTLSネゴシエーションも必要です。
4. カーネルは実装に応じて応答の有効性を判定し、所要時間または失敗ステータスをクライアントに返します。

これらの処理が毎回すべて実行されるとは限りません。DNSキャッシュや接続の再利用、プロトコルセッションの再利用によって、2回目以降のテスト時間が短くなる場合があります。また、実装によっては複数回リクエストすることもあります。そのため、画面上の「遅延」は単一のネットワークパケットが往復する時間と厳密に同じではなく、システムのpingコマンドの結果とも異なります。

テストURL・タイムアウト・自動選択が結果に与える影響

テストURLで「どこまで測るか」が決まる

よく使われるのは、少量のデータを返すページやHTTP 204を返すURLです。例としてhttps://www.gstatic.com/generate_204があります。レスポンスが小さいため、データのダウンロード自体が所要時間に与える影響を抑えられます。ただし測定結果が示すのは、そのノードからテストサービスのネットワークまでの通信状況であり、あらゆるサイトへのアクセス速度ではありません。

ノードの出口からテストサービスまでは経路が良好でも、動画サイトや業務プラットフォームへの経路は異なる場合があります。また、CDNは出口の場所やDNSの応答、負荷に応じて別のエッジサーバーを割り当てることがあります。テストURLをHTTPSからHTTPに変えれば接続手順も変わるため、条件の異なる結果を並べて最小値だけで選ぶのは避けましょう。

タイムアウトはテストが期限内に完了しなかったという意味で、ノードが恒久的に使えないとは限らない

たとえばタイムアウトが5000 msに設定されている場合、制限時間内に有効な応答を得られないと、カーネルは失敗を返すことがあります。原因はプロキシへの接続失敗、接続先サイトへの到達不能、TLSエラー、その時点でのネットワーク混雑などさまざまで、「ノードがオフライン」とは限りません。タイムアウトを10000 msに延ばしても待ち時間が長くなるだけで、回線自体が速くなるわけではありません。

画面に表示されるTimeout、Error、空欄、0 msは、クライアントによって失敗や未測定状態の表し方が異なる場合があります。こうした表示が出たら接続ログで具体的なエラーを確認し、すべての異常をパケットロスと決めつけないようにしましょう。

url-testが選ぶのは低遅延ノードであり、最大帯域幅ではない

以下はmihomo形式のプロキシグループの例です。香港 01と日本 01は、現在の設定に定義済みのノード名に置き換えてください。これは設定の一部であり、そのままインポートできる完全なサブスクリプションではありません。

proxy-groups:
  - name: 低遅延自動選択
    type: url-test
    proxies:
      - 香港 01
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300：チェック間隔は秒単位で、ここでは5分です。Webページを開くたびに測定するわけではありません。
• tolerance: 50：切り替えの許容幅はミリ秒単位です。わずかな差による頻繁な切り替えを抑えるための設定で、帯域幅のしきい値ではありません。
• lazy: true：グループが使われていない間は定期チェックを省略できます。そのため、一覧の測定結果が直近のものとは限りません。

「すべて測定」の手動テスト、プロキシグループの自動チェック、プロキシセットのヘルスチェックでは、それぞれ測定方法やパラメーターが異なる場合があります。特定のグループのurlを変更しても、クライアントの手動テストで使うURLまで変わるとは限りません。各フィールドの対応状況は、使用中のカーネルで確認してください。関連する概念はプロトコルと設定ガイドも参照してください。

低遅延ノードなのにダウンロードが遅い・動画が止まる理由

小さなレスポンスの取得に必要なスループットはごくわずかです。回線の持続帯域が5 Mbpsしかなくても、数十〜数百バイトの応答ならすぐに返ることがあります。高ビットレートの動画や大容量のインストーラーをダウンロードすると、帯域の制限が表面化します。ノードの遅延が低いのにダウンロードが遅いことに矛盾はありません。

パケットロスは問題をさらに見えにくくします。単発のテストがたまたま成功すれば、測定値は良好に見えることがあります。一方、継続的な通信ではTCPの再送や輻輳制御によって実効速度が低下します。QUICを使うサービスではUDP経路も関係するため、TCPベースのHTTPSテストが1回成功しても、ノードがUDPに対応していることやUDPの品質まではわかりません。

再現性のあるノード測定の手順

ステップ1：通信が実際に測定対象のノードを経由しているか確認する

まずクライアントで測定したいノードを選び、「接続」または「Connections」画面で接続先ドメインの履歴を確認します。適用されたルールとプロキシチェーンを確認してください。画面名はクライアントによって異なりますが、確認する内容は同じで、最終的にどの出口を使ったかを調べます。測定中は自動切り替えグループを使わないでください。大容量ファイルのダウンロード中と次のWebリクエストで、別のノードが使われる可能性があります。

システムプロキシの設定が適用されるのは、その設定に従うアプリだけです。コマンドラインやゲーム、一部のダウンロードツールはシステムプロキシを参照しないことがあります。TUNモードなら対象を広げられますが、ルーティングや除外設定、実際の接続履歴の確認は必要です。TUNを有効にしても通信が速くなるわけではなく、帯域の狭い回線が高速になることもありません。

ステップ2：条件を固定し、1回の結果ではなく複数回測定する

1. ほかの大容量通信を止め、同じネットワーク、テストURL、タイムアウト設定を使います。
2. 各ノードで10回測定します。間隔は約5秒とし、成功時の所要時間と失敗回数を記録してください。
3. 典型的な待ち時間の比較には中央値を使い、最大値も記録して、一度だけ出た低い値に変動が隠れないようにします。
4. 普段よく使う時間帯、たとえば20:00〜22:00にも再度測定し、混雑時の変化を確認します。

10回中2回失敗した場合、正確には「今回のアプリケーション層のテスト失敗率は20%」と表現します。「ネットワークのパケットロス率が20%」とは言えません。1回のリクエストに複数のパケットが含まれることがあり、DNSやTLS、接続先サービスの問題で失敗する場合もあります。10回連続で成功しても、長時間の接続が安定している証明にはなりません。

ステップ3：実際の利用状況で帯域幅と安定性を確認する

アクセス権のあるサイズ既知のファイル、または同じ動画を選び、配信元を固定してノードを比較します。ダウンロードでは、接続開始から速度が上がるまでの約10秒と、その後30〜60秒の持続速度を確認します。動画の場合は、バッファリングの回数と時間、プレーヤーに表示される接続速度に注目してください。どちらもノード一覧の数値だけを見るより、日常の使い心地を反映します。

単位もそろえて比較しましょう。十進法換算では8 Mbpsは約1 MB/s、80 Mbpsは約10 MB/sです。実際の速度はプロトコルのオーバーヘッドによって低下します。ツールがMiB/sで表示する場合は二進単位のため、数値に少し差が出ます。継続的な帯域テストはサブスクリプションの通信量を消費するので、特にモバイル回線では測定回数を抑えてください。

curlで接続時間と最初の1バイトまでの時間を分けて測る

所要時間がどの段階で発生しているか詳しく調べるには、curlでローカルHTTPプロキシを明示し、各段階の時間を出力します。以下ではクライアントのHTTPまたは混合リスニングポートを7890としています。よくある設定例ですが、すべてのクライアントで既定値とは限りません。実行前にクライアントのポート設定を確認してください。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  --output /dev/null \
  --silent --show-error \
  --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

このコマンドはmacOSやLinuxなど、一般的なシェルで使えます。Windows PowerShellではcurl.exeを実行し、コマンドを1行にまとめて、--output /dev/nullを--output NULに変更してください。プロキシを明示することで、コマンドラインがシステムプロキシを参照するか推測せずに済みます。ただし、クライアントで現在選択されている出口は事前に確認してください。

• time_connect：このローカルHTTPプロキシの例では、主に127.0.0.1:7890への接続時間を示します。リモートノードまでの遅延として扱うことはできません。
• time_appconnect：HTTPSのTLSハンドシェイクが完了するまでの時間です。HTTPプロキシ経由の場合は、それ以前のプロキシトンネル確立なども含まれます。
• time_starttransfer：レスポンスの最初の1バイトを受信するまでの累積時間です。それまでの接続処理と、接続先サービスの応答待ち時間が含まれます。
• time_total：今回のリクエストにかかった合計時間です。テストページのレスポンス本文はほぼないため、大容量ファイルの転送速度はわかりません。

各時間はリクエスト開始からの累積値で、単純に足し合わせるものではありません。テストの実装や接続の再利用方法が異なるため、クライアントカーネルの測定値と一致するとも限りません。同じノード、接続先、パラメーターでコマンドを繰り返し実行し、接続中と最初の1バイトを受け取るまでのどちらで遅くなっているかを比べると、原因の切り分けに役立ちます。

よくある質問：タイムアウト・パケットロス・自動選択

ノード選びでは遅延を最初の絞り込みに使い、その後、持続速度、失敗頻度、利用するアプリでの実際の動作を確認します。異常があれば、一度に変える条件は1つだけにしましょう。まず出口を固定し、次に測定対象を固定してから、ネットワークや時間帯を比較します。「すべて測定」を何度もクリックするより、結果を再現しやすく、問題の特定にも役立ちます。