Clashのノード遅延テストの仕組み｜測定値と実際の通信速度が一致しない理由

遅延の測定値は1回のリクエスト時間であり、ダウンロード速度ではない

Clashクライアントのノード一覧にある「テスト」は、通常、指定したURLへプロキシ経由でアクセスし、コアが報告する所要時間を表示します。結果の単位はミリ秒（ms）です。継続的なダウンロード速度を測るものでも、プロキシサーバーへICMP Pingを1回送るものでもありません。画面に「遅延」と表示されていても、実際に何を測っているかはコアやテスト設定によって異なります。

この違いが、よくある現象を説明します。あるノードは80 msと表示されてもダウンロード速度は500 KB/s、別のノードは180 msでも10 MB/sで安定してダウンロードできることがあります。前者は小さなリクエストへの応答が速く、後者は継続的な転送能力に優れています。測っている段階が異なるため、両者に必ず相関があるわけではありません。

単位の違いも誤解の原因になります。通信帯域はMbps、ダウンロードツールはMB/sで表すのが一般的です。十進法で換算すると、100 Mbpsの理論上限は約12.5 MB/sですが、実際の転送ではプロトコルのオーバーヘッド分だけ低下します。遅延の100 msと帯域の100 Mbpsは換算できません。

URL Testの接続・ハンドシェイクの流れ

HTTPSのテスト先を例に、アクセスの流れをいくつかの段階に分けて見てみましょう。障害の発生箇所を理解するための説明であり、すべてのコアのバージョンが各段階を個別に計測・表示するわけではありません。画面の数値を各段階の所要時間の合計とみなすこともできません。

1. ノードの接続先を準備する。プロキシサーバーがドメイン名で指定されている場合、接続前に対応するアドレスを取得します。キャッシュが使われることもあれば、新たに名前解決が行われることもあります。
2. プロキシサーバーに接続する。クライアントはノードのプロトコルに従って通信接続を確立します。TCP、UDPベースの転送方式、暗号化プロトコルの違いによって準備の手順も異なります。
3. テスト先への経路を確立する。プロキシの出口からテスト先へ到達できる必要があります。テスト先のドメインをどちら側で名前解決するかは、プロトコルや関連設定によって異なります。
4. テスト先とHTTPS通信を完了する。通常はテスト先とのTLSハンドシェイクとHTTPリクエストが行われ、コアが定める応答条件を満たした時点で計測が終了します。

実際の計測開始・終了のタイミング、接続の再利用、再試行の方針、HTTPリクエストメソッドは、コアのバージョンによって異なる場合があります。あるクライアントの「接続遅延」を、別のクライアントも同じ計算方法で求めていると決めつけないでください。比較する際は、クライアント、コア、テストURL、ネットワーク環境をそろえましょう。

システムのPingは低いのにClashの遅延が大きい理由

ノードサーバーへのPingで確認できるのは、端末からサーバーまでのICMP往復時間だけです。URL Testには、プロキシプロトコルの処理、出口からテスト先までの経路、テスト先の応答も影響します。サーバーがICMPを制限していると、Pingではパケットロスが発生してもプロキシ経由のリクエストは正常に通ることがあります。2種類のテストは別々に記録し、互いの代わりにはしないでください。

テストURLによって測定するネットワーク区間が変わる

よく使われるテストURLには、HTTP 204を返す小さな応答のエンドポイントがあります。例：https://www.gstatic.com/generate_204。204はレスポンス本文がないことを示します。転送量が少なく、接続確認を頻繁に行うのに適していますが、大容量ファイルの転送能力はほとんどわかりません。

同じ出口からアクセスしても、ドメインが違えば接続先のCDNや接続拠点の地域が異なることがあります。テスト用エンドポイントまでの経路が短いノードでも、動画サイトやコードリポジトリ、業務サービスへの経路が短いとは限りません。テスト先を別のサイトに変えたときにノードの順位が変わるのは、よくあることです。

テストURLを選ぶ3つのポイント

• 応答が小さく安定している。接続確認用として明確に使えるエンドポイントを選び、画像の多いトップページやログイン後のリダイレクト、内容が頻繁に変わるページは避けましょう。
• プロトコルを統一する。ノードを比較する際は、同じHTTPS URLを使い続けます。HTTPとHTTPSでは通信手順が異なるため、同じランキングに混ぜないでください。
• 実際の用途でも確認する。共通のエンドポイントで候補を絞ったうえで、実際に使うアプリでも検証します。ログイン情報や機密性の高いクエリパラメータを含むURLへ、頻繁にリクエストを送るのは避けてください。

テストの入口は、ノードごとの手動テスト、url-testプロキシグループの自動テスト、proxy-providersのヘルスチェックの3種類に分けて考える必要があります。それぞれでURL、間隔、タイムアウトを個別に設定できる場合があります。1か所を変更しても、ほかの画面のテスト条件には反映されないことがあります。

mihomoのurl-test設定と自動ノード選択

url-testプロキシグループは、テスト結果に基づいてメンバーを自動選択します。以下はグループ単位の設定例です。「香港-01」と「日本-01」は、例に登場するノード名です。実際の設定で使う場合は、メンバー名を自身のproxies定義と一致させてください。一致しないと正しく参照できません。

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

• interval: 300：自動チェックの間隔は300秒で、300ミリ秒ではありません。
• tolerance: 50：切り替えの許容差をミリ秒単位で指定します。わずかな遅延差による頻繁な切り替えを抑えるための設定で、タイムアウト時間ではありません。
• lazy: true：このグループが使われていない間は定期テストを省略し、バックグラウンドのリクエストを減らせます。そのため、長く使われていないグループの遅延値は最新とは限りません。

設定項目は、使用中のコアがサポートする範囲に合わせてください。従来のClashとmihomoでは、すべての項目が共通しているわけではありません。クライアントが設定の上書きやサブスクリプション変換を行い、最終的な内容が変わることもあります。確認する際は、サブスクリプションの元データだけでなく、実際に適用中の設定を確認してください。設定方法やインストール手順は全プラットフォームガイドをご覧ください。

遅延は低いのにダウンロードが遅い主な原因

出口の速度制限と共有回線の混雑

小さなHTTPレスポンスは転送量がわずかなため、回線が5 Mbpsに制限されていてもすぐに返る場合があります。一方、1 GBのファイルをダウンロードするには帯域を継続して使うため、出口の速度制限や共有回線の混雑、サーバー側の速度制限が表面化します。夜間に「遅延はあまり変わらないのにダウンロードが大幅に遅くなる」場合は、遅延テストを繰り返すのではなく、持続スループットを比較しましょう。

パケットロスと再送が長時間接続に与える影響

まれなパケットロスは短いテストには影響しなくても、長時間の転送では再送や輻輳制御を引き起こすことがあります。速度が波打つように変化する、最初は正常でも途中から低下するといった症状が目安です。複数回のリクエスト成功率とダウンロード中の状態をあわせて確認しましょう。最小遅延の1回だけで安定性は判断できません。

実際の通信がテスト対象のノードを通っていない

ノードを手動テストしても、ブラウザーがそのノードを選択したとは限りません。ルールによって対象ドメインが別のプロキシグループに振り分けられたり、DIRECTで接続されたりすることがあります。システムプロキシの設定が影響するのは、その設定に従うアプリだけです。TUNモードの適用範囲も、ルーティング、除外設定、クライアントの設定によって異なります。クライアントの接続一覧で、対象ドメイン、適用ルール、プロキシグループ、最終的に使われたノードを確認してください。

ダウンロード元や端末側がボトルネックになっている

接続先のサイトが、接続数やアカウント、地域に応じて速度を制限している場合があります。端末側のWi-Fi干渉、バックグラウンド同期、ディスクへの書き込みも測定結果に影響します。同じダウンロードをノードだけ切り替えて繰り返すより、異なる配信元を2つ使って比較するほうが、原因の切り分けに役立ちます。

timeoutの意味と確認手順

timeoutは、指定された時間内にテストが完了しなかったことを意味し、サブスクリプションが無効だと確定したわけではありません。DNSの名前解決失敗、サーバーへの接続不可、プロトコルパラメータの誤り、テスト先の制限、現在のネットワーク速度の低下などでテストに失敗することがあります。クライアントによっては複数のエラーを一律にタイムアウトと表示するため、具体的な原因はログで確認してください。

1. ネットワーク環境をそろえる。大容量ダウンロードを一時停止し、同じWi-Fiまたは有線ネットワークで再テストして、失敗した時刻を記録します。
2. 1つのノードだけか、すべてのノードかを切り分ける。特定のノードだけ失敗する場合は、まずそのノードの情報を確認します。すべてのノードが同時に失敗する場合は、ローカルネットワーク、DNS、共通のテスト先を先に確認してください。
3. テスト先を一度変更する。別の安定した小容量レスポンスのエンドポイントを使います。元のテスト先だけで失敗しても、ノード全体が利用できないとは判断できません。
4. ログでエラーの種類を確認する。名前解決エラー、接続拒否、TLSエラー、応答待ちのタイムアウトでは、それぞれ対処方法が異なります。TLSの異常がある場合は、システムの日付と時刻も確認してください。
5. どの設定のタイムアウトか確認する。手動テスト、プロキシグループ、プロバイダーのヘルスチェックでは、異なる制限時間が使われる場合があります。1か所の値を大きくしても、ほかのテストに反映されるとは限りません。

たとえば、テストの制限時間が5秒なら、完了まで6秒かかったリクエストは失敗と判定されます。10秒に延ばせば成功と表示されることはありますが、回線そのものが改善するわけではありません。タイムアウトは待機時間の上限を定めるもので、速度を上げる設定ではありません。応答に数秒かかる状態が続く場合は、画面上の成功表示だけを求めるのではなく、ネットワーク経路を引き続き確認してください。

同じ条件で比較してノード品質を判断する

次の手順は、繰り返し実行できるノード選定の方法です。数値は記録方法を示す例であり、本サイトが特定のノードを実測した結果ではありません。比較する際は、端末、テストURL、ダウンロード元、時間帯をそろえ、毎回ノードだけを変更してください。

1. まず短いリクエストを測る。各ノードでURL Testを5回、約10秒間隔で実行します。最良の値だけを残さず、すべての測定値と失敗回数を記録してください。
2. 次に継続転送を測る。速度測定が許可された固定のダウンロード元を選び、30～60秒間の状態を確認します。開始直後と速度が安定した後の値をそれぞれ記録し、通信量にも注意してください。
3. 実際の出口を確認する。接続一覧で、そのタスクがどのノードを使っているか確認します。プロキシグループを切り替えたらタスクを再接続してください。既存の接続はすぐに切り替わらない場合があります。
4. 実際に使うアプリでも再確認する。動画では再生開始、シーク、バッファリングを確認します。Webページでは初回表示と連続アクセス、リモート接続では入力への応答と切断の有無を確認してください。
5. 時間帯を変えて再確認する。少なくとも日中と夜間の1回ずつ比較し、ある1分間の結果を長期的な品質とみなさないようにします。

この例では、ノードAは短いリクエストへの応答が速く、ノードBは大容量ファイルの転送に向いています。5回中2回がタイムアウトした場合は、残り3回の平均値だけでなく「成功3/5」と明記してください。インタラクティブな用途では低く安定した遅延が重要です。大容量ファイルや高ビットレート動画では、持続スループットと成功率も同じように重要になります。

最終的には実際の用途に合わせて選びましょう。まずURL Testで明らかに接続できないノードを除外し、その後、実際のアプリで経路と使用感を確かめます。遅延は選定基準の1つであり、通信速度の総合評価でも、あらゆるサイトへの接続性を保証するものでもありません。