遅延の数値が示すもの：小さなリクエストの応答時間

Clashのノード一覧に表示されるミリ秒数は、通常、指定したプロキシ経由でHTTPまたはHTTPSのテストを行った結果です。ノードサーバーにICMP pingを送った数値ではありません。url-testポリシーグループは、このテストで候補ノードの接続可否や応答速度を確認し、カーネルの選択ロジックや許容差などに基づいて使用するノードを決めます。手動の「遅延テスト」とポリシーグループの自動チェックは関連する機能を使う場合がありますが、テスト先やタイムアウト、実行範囲が同じとは限りません。

遅延は応答にかかる時間、ダウンロード速度は単位時間あたりに転送できるデータ量を表します。少量のデータを返すテストリクエストは、接続失敗や大きな迂回、応答の遅さを見つけるのに適していますが、継続的なダウンロード速度の推定には向きません。そのため、遅延80 msのノードでダウンロード速度が2 MB/s、遅延180 msのノードで15 MB/sになることは、技術的に十分あり得ます。

url-testのリクエストが通る経路

HTTPSのテストURLを例にすると、カーネルは通常、テスト対象のプロキシ経由でURLにアクセスし、必要な接続を確立してHTTPレスポンスを待ちます。計測されるのは特定のテスト実装における所要時間であり、ネットワーク回線の一部分だけを伝わる純粋な遅延ではありません。

  1. プロキシ接続の準備：ノードの設定を読み込み、必要に応じてプロキシサーバーのホスト名を解決します。DNSキャッシュが使われるかどうかで、今回の処理量は変わります。
  2. プロキシへの接続：ノードの入口に接続し、使用するプロトコルに応じてトランスポートやセキュリティ、プロキシのハンドシェイクを完了します。プロトコルによって、TCP・UDPや多重化の方式は異なります。
  3. テスト先へのアクセス：プロキシ経由でテストサイトに接続します。接続先ホスト名をどこで名前解決するかは、使用するプロトコルやDNS設定によって異なり、常にローカルで解決されるわけではありません。
  4. レスポンスの受信と計測：HTTPSでは接続先サイトとのTLS通信も発生します。その後、カーネルが実装に応じて結果を記録し、クライアントに表示します。

ここまでの手順は経路を理解するためのモデルです。毎回すべての手順を最初から実行するとは限らず、どのカーネルでも準備にかかる時間がすべて表示値に含まれるわけではありません。DNSキャッシュ、確立済みのトンネル、セッション再開、接続の再利用によって、2回目以降のテストが初回より速くなることがあります。異なるクライアントの数値を比べる前に、テストURLと計測方法が同じか確認してください。

OSのpingは低いのにClashの遅延が高いのはなぜ？

端末でノードの接続先に対してpingを実行しても、分かるのは端末から接続先までのICMP往復時間だけです。ICMPは速度制限されたり、破棄されたりする場合もあります。ClashのURLテストではテストサイトへのアクセスも行うため、ノードから接続先サイトまでの経路も結果に影響します。測定対象が異なるので、両者の差を単純に引いて「プロトコルの追加オーバーヘッド」とすることはできません。

遅延・帯域幅・混雑：見るべき指標の違い

指標主に分かること直接は分からないこと
URLテストの遅延（ms）現在の経路で小さなリクエストに応答するまでの時間継続的なダウンロード速度、すべてのサイトでの通信速度
スループット（MB/s）一定時間あたりの実際のデータ転送能力操作への応答性や、別の時間帯での安定性
複数回のテスト結果のばらつき応答時間が安定しているか少数のサンプルだけでパケットロスの発生箇所を特定すること
タイムアウトや失敗の回数指定したテスト条件での接続可否ノードがすべての接続先で利用できないこと

たとえば、ノードAの5回の応答時間が70、74、71、520、76 ms、ノードBが145、149、146、152、148 msだったとします。これは説明用の数値であり、当サイトで実測した結果ではありません。Aは多くの回で低遅延ですが、1回だけ大きく遅れています。リモート端末で使うなら、Bのほうが安定して操作できる可能性があります。最小値だけを見ていると、この違いは分かりません。

継続的なダウンロード速度は、サーバー側の速度制限、ノードの共有帯域、ネットワーク間の混雑、トランスポートプロトコルの輻輳制御、端末側のネットワーク環境にも左右されます。接続帯域が100 Mbpsなら、オーバーヘッドを除いた理論上の速度は約12.5 MB/sですが、単一の接続でその速度が出るとは限りません。204レスポンスが一度すぐ返ってきても、大容量ファイルの転送では数秒後にキューの滞留や共有回線の競合で速度が落ちることがあります。

夜の混雑時に「遅延は正常なのに動画が止まる」理由

小さなリクエストは転送データ量が少ないため、回線のスループットが限られていてもテスト自体はすぐ完了することがあります。一方、動画は分割されたデータを継続的に取得する必要があります。利用可能な帯域幅が画質に必要なビットレートを下回ると、バッファが徐々に減っていきます。この場合は遅延テストを繰り返すのではなく、プレーヤーのバッファ状況、実際の動画データのダウンロード速度、接続ログを確認してください。

テストURLによって結果を適用できる範囲が変わる

よく使われるテストURLは、本文のない成功レスポンスであるHTTP 204を返します。たとえば、https://www.gstatic.com/generate_204はこの種のテストに利用できます。テスト先には、長期にわたってアクセスでき、レスポンスが小さく、動作が安定したURLを選びましょう。大容量のダウンロードファイル、ログインが必要なページ、認証画面が頻繁に表示されるAPIは避けてください。

  • プロトコルの違い：HTTPとHTTPSでは接続手順が異なるため、異なるURLの計測時間をそのまま並べて比較できません。HTTPSでは、接続先とのTLS通信が正常かどうかも確認できます。
  • 接続先の場所の違い：同じドメインでも、CDNの振り分けによって接続先の地域が変わることがあります。ノードの出口が変われば、実際に接続されるサーバーも変わる可能性があります。
  • サイト側の設定の違い：テストサイトが特定の出口を制限していたり、一時的に障害が発生したりする場合があります。テストが1回失敗しても、そのテスト経路が想定どおりに完了しなかったことしか分かりません。
  • 利用目的の違い：公開テストサイトに接続できても、動画配信サービス、コードリポジトリ、ゲームサーバーで同じ経路やアクセス権が使えるとは限りません。

日常の自動選択には、安定した基本テストURLを使い、別途、実際のサービスで動作を確認するのがおすすめです。コードリポジトリをよく使うなら、リポジトリのページ表示と実際の取得速度を比べましょう。動画視聴が中心なら、対象サービスの再生統計を確認してください。自動テストに大容量ファイルのURLを設定し、それを帯域幅全体の測定とみなすのは避けましょう。

url-testの設定：間隔・許容差・必要時のテスト

以下は、該当フィールドに対応するmihomoカーネル向けのポリシーグループ例です。既存の設定に統合して使ってください。例ではメンバーとして組み込みのDIRECTを指定し、フィールドの構造を示しています。このまま使うと直結のみがテストされ、プロキシノードが自動で追加されるわけではありません。実際に使う際は、メンバーを現在の設定にあるノード名に置き換えるか、カーネルのドキュメントに従ってプロキシプロバイダーを指定してください。

config.yaml · ポリシーグループの設定例
proxy-groups:
  - name: 遅延自動選択
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300は自動テストの間隔が300秒、つまり5分であることを示します。リクエストのタイムアウトではなく、300ミリ秒ごとにテストするという意味でもありません。
  • tolerance: 50は、わずかな遅延差による頻繁な切り替えを抑えるための、ミリ秒単位の許容差です。ノードの遅延を必ず50 ms以下にする設定ではありません。
  • lazy: trueを設定すると、使用していないポリシーグループのテストを利用状況に応じて減らせます。バックグラウンドで新しい数値が継続して表示されなくても、テストが止まったとは限りません。
  • proxiesには、既存のノードや対応するポリシーメンバーを指定します。メンバーが1つだけの場合、比較対象となる候補はありません。

現在のメンバーの遅延が約120 ms、別のメンバーが約105 msだとします。許容差を50 msに設定するのは、この程度の差で頻繁に切り替わるのを防ぐためです。実際の選択は、メンバーの利用可否、テストの実行タイミング、カーネルの実装にも左右されるため、許容差を厳密な切り替え条件と捉えないでください。ポリシーグループのメンバーが切り替わっても、既存のTCP接続がそのまま引き継がれるわけではありません。通常、新しい接続から新しい選択先が使われます。

タイムアウト・失敗・「0 ms」の確認方法

タイムアウトは、所定の時間内にリクエストが想定どおり完了しなかったことを示します。遅延がその上限と同じという意味ではありません。たとえばテストのタイムアウトが5000 msの場合、タイムアウト表示は、そのテストが5秒以内に成功しなかったことを示します。ノードへの接続失敗、テストサイトへの接続不可、DNSの異常、ハンドシェイクの停止など、原因はさまざまです。

クライアントでの手動速度テスト、カーネルのコントロールAPI、ポリシーグループの自動テスト、プロキシプロバイダーのヘルスチェックでは、それぞれ異なるタイムアウト設定が使われる場合があります。あるAPIのtimeoutパラメーターを、あらゆるYAML階層にそのまま貼り付けないでください。使用中のカーネルに対応するフィールドを確認し、ログで変更後の値が実際のテストに反映されているか確かめましょう。

  1. まずエラーの種類を確認：接続拒否、名前解決の失敗、TLSエラー、リクエストのタイムアウトは、それぞれ異なる段階の問題を示します。「赤色」とだけ記録するより、エラー全文と発生時刻を記録するほうが役立ちます。
  2. 次に比較テストを実施：同じノードで安定した別のテストURLを試し、同じURLを別のノードでも試します。一度に変える条件は1つにして、問題がノード側と接続先側のどちらに近いかを判断しましょう。
  3. 通信が意図したメンバーを通っているか確認：特定のノードをテストしても、ブラウザーがそのノードを使っているとは限りません。「接続」画面で、実際に適用されたルール、ポリシーグループ、出口メンバーを確認してください。
  4. 端末側のプロキシ設定を確認：ブラウザーはシステムプロキシを使っていても、端末のシェルにはプロキシが設定されていない場合があります。TUNでは別の範囲の通信が取り込まれます。速度テストの成功と、すべてのアプリの通信がプロキシ経由であることは別の問題です。

0 ms、空欄、極端に低い数値が表示されても、すぐに「最速ノード」と判断しないでください。未テストの状態、キャッシュされた結果、丸め処理、クライアントの表示方法が原因の可能性があります。ログを確認し、再テストして意味を確かめましょう。結果に異常があったら、まず記録を保存してから設定を変更してください。DNSのリセット、ノードの変更、モードの変更を同時に行うと、原因を特定する手がかりが失われます。

再現性のあるノード比較手順

ノードを比較するときは、テスト条件を揃えることが重要です。以下の手順で記録すれば、設定全体を何度も変更する必要はありません。

  1. 環境を固定：クライアントとカーネルのバージョン、テストURL、タイムアウト、ネットワークの種類を記録します。大容量ファイルの同期を一時停止し、Wi-Fiとモバイルホットスポットを頻繁に切り替えないようにしましょう。
  2. 初回の結果を記録：初回のテスト結果は分けて保存します。名前解決や最初のハンドシェイクの影響を受けやすいため、2回目以降の結果と混ぜて解釈しないでください。
  3. 複数回テスト：ノードごとに5～10回、約10秒間隔でテストし、中央値、最大値、失敗回数を記録します。各ノードで同じ間隔を使い、大量の同時テストでローカルネットワークに負荷をかけないようにしましょう。
  4. 実際の用途で確認：対象サイトに一度アクセスしたあと、約30秒間ダウンロードまたは再生して状態を確認します。ダウンロードテストでは通信量が発生するため、ファイルサイズとテスト回数を抑えてください。
  5. 時間帯を変えて再テスト：普段使う夜間の時間帯にもテストし、一時的な混雑と長期的な傾向を見分けます。空いている時間帯の最高値だけを記録するのは避けましょう。

記録例：「ノードA、HTTPS 204テスト、中央値92 ms、10回中1回失敗。対象ファイルの平均ダウンロード速度3.2 MB/s。」数値は記録方法を示すための例です。遅延、失敗率、実際の用途でのスループットを合わせて確認するほうが、緑色で表示されたミリ秒数だけを見るより参考になります。

最小値ではなく、用途に合わせて選ぶ

  • Web閲覧・リモート端末：応答の安定性、遅延の大きな跳ね上がりの少なさ、失敗率の低さを重視します。
  • 動画・大容量ファイル：接続できることを確認したうえで、継続的なスループット、バッファの状態、混雑時のパフォーマンスを重視します。
  • ゲーム・音声通話：実際のUDP経路、パケットロス、ジッターを重視します。HTTPテストはゲームサーバーや音声通話の経路テストの代わりにはなりません。

url-testは、候補メンバーから応答が速く利用可能な経路を選ぶ機能であり、帯域幅のランキングではありません。安定したテスト条件を保ち、実際の用途や接続ログと合わせて判断すれば、「遅延は低いのに速度が出ない」理由を把握しやすくなり、根拠のない切り替えも減らせます。