Clashのノード遅延測定の仕組み：url-testの数値と実際の通信速度が違う理由

遅延の数値が示すのはリクエストの所要時間であり、ダウンロード速度ではない

Clash for Windows のProxies画面でテストボタンを押すと、通常はノードの横にミリ秒単位の数値が表示されます。この数値で分かるのは「このプロキシ経由でテスト先にアクセスするまでの時間」であり、「ファイルを毎秒どれだけダウンロードできるか」ではありません。画面の80 msとダウンロードツールの8 MB/sは、別の指標です。

Clashで一般的な遅延テストは、プロキシ経由でHTTPリクエストを送るテストであり、コマンドラインのICMP pingとは異なります。指定したプロキシ経由でテストURLにリクエストを送り、所要時間を計測します。カーネルのバージョンやプロトコル、接続の再利用、テストの実装によって計測対象となる段階も異なるため、すべてのクライアントの数値を同じ基準で測定したものとは見なせません。

たとえば、小さなリクエストへの応答は速くても、大容量ファイルの転送時に速度制限がかかる回線があります。一方、海外との往復に時間がかかっても、十分な帯域を確保できる回線もあります。前者の遅延が低く表示されても、ダウンロードは後者のほうが速い場合があります。矛盾ではありません。

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

ローカルのカーネルからテスト先まで

一般的な経路は「ローカルのClashカーネル → プロキシサーバーまたはプロキシチェーン → テスト先 → ローカル」です。テストではプロキシ経由の通信を確立または利用して、指定URLにアクセスします。HTTPSのURLを使う場合は接続先とのTLS処理も発生します。DNS名前解決がどこで行われるかは、プロキシのプロトコルやDNS設定、実際の接続経路によって異なります。

1. テスト対象のプロキシを選択：カーネルは対象ノードに対してテストを実行します。対象がプロキシグループの場合は、そのグループが実際の出口をどう選ぶかも確認してください。
2. 接続を確立してリクエストを送信：ローカルのネットワーク、プロキシとのハンドシェイク、出口から接続先までの経路が所要時間に影響することがあります。
3. リクエスト結果を判定：成功すると遅延が返されます。失敗した場合や、条件に合わないステータスが返った場合、または制限時間を超えた場合は、画面にタイムアウトやエラーが表示されることがあります。

テスト先には、HTTP 204を返す軽量なエンドポイントがよく使われます。204はレスポンス本文がないことを示すため、大容量データの転送による測定への影響を抑えられます。一方、本文をほとんど転送しないため、継続的な帯域は測れません。このテストを「ダウンロード速度を測定済み」と解釈しないでください。

テストボタンと自動選択グループは別の仕組み

パネルで速度テストを実行すると、通常はクライアントがカーネルの遅延測定APIを呼び出します。一方、設定のtype: url-testは、テスト結果をもとにプロキシを自動選択するグループを定義します。テストURL、タイムアウト、実行タイミングはそれぞれ異なる場合があります。グループ内のurlを変更しても、パネルのテストボタンの設定まで変わるとは限りません。

url-testの設定：URL、間隔、切り替え許容値

以下は設定項目を説明するためのプロキシグループの例で、mihomo向けの書式です。完全なサブスクリプション設定ではありません。proxiesに記載するノード名は、現在の設定に存在している必要があります。旧バージョンのClashカーネルや各派生版では対応する項目が異なるため、コピーする前に使用するカーネルの設定ドキュメントを確認してください。

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

• url：テスト先です。例では軽量なHTTPSエンドポイントを使用しています。テスト先の稼働状況や接続経路によって結果が変わり、あらゆるネットワークで利用できるとは限りません。
• interval: 300：定期テストの間隔は300秒です。1回のリクエストで300秒待つという意味でも、ノードが停止したらすぐ切り替わるという意味でもありません。
• tolerance: 50：切り替え許容値は50ミリ秒です。小さな遅延差による頻繁な切り替えを抑えるための設定で、帯域のしきい値ではありません。
• lazy: true：グループが使用中かどうかなどの条件に応じて、定期チェックを実行するか決めます。詳しい挙動はカーネルの実装によって異なります。そのため、使用していない間はパネルに表示される過去の数値が更新されないことがあります。

自動選択グループは主に遅延と接続可否をもとに判断し、ダウンロード速度が速い回線を自動的に上位にするわけではありません。また、選択結果が変わっても、確立済みの接続がすべて新しいノードに移るとは限りません。長時間の接続は元の接続を使い続けることが多く、切り替えを確認するにはWebページを再読み込みするか、新しい接続を開始してください。

タイムアウトとテスト間隔は別々に確認

互換性のあるカーネル制御APIを例にすると、単一ノードの遅延測定には次の形式のリクエストを使えます。ここでのtimeout=5000は待機時間の上限が5000ミリ秒という意味で、プロキシグループの定期実行間隔とは別の設定です。ポート9090は制御ポートの例であり、プロキシポートではありません。

GET /proxies/香港の入口/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

実際に呼び出す際は、ノード名をURLエンコードし、ローカルの設定に応じて制御APIの認証情報を付ける必要があります。問題の切り分けには通常クライアントの画面で十分です。速度測定のために制御ポートをLANに公開する必要はありません。設定項目を確認する場合は設定リファレンスを参照し、制御ポート、HTTPプロキシポート、SOCKSポートを混同しないでください。

低遅延でも通信が遅くなる5つの原因

1. テスト先が近くても、実際のサービスへの経路は異なる

軽量なテスト用エンドポイントには近隣のCDN経由で接続できても、動画サイトやコードリポジトリ、ファイル配信サイトへの接続では別の地域に割り当てられることがあります。小さなリクエストがスムーズでも、実際のサービスが同じ経路を通るとは限りません。海外のサービスでは、戻りの経路やネットワーク間の混雑、サーバー側の制限も影響します。

2. 小さなリクエストは速くても、継続的な帯域が不足

接続のハンドシェイクに必要なデータはわずかなので、回線に速度制限があっても短時間で完了することがあります。ダウンロードを始めると、帯域制限や共有出口の混雑、サーバー負荷が顕在化します。スループットを比べる場合は、同じ配信元、近い時間帯、同じダウンロード方法を使ってください。異なるファイル配信サイトの速度だけでノードの優劣を判断することはできません。

3. 1回の遅延は低くても、変動が大きい

1回の測定で65 msだったとしても、回線が安定しているとは限りません。連続リクエストで70、75、820 msのようにばらつき、失敗も混じれば、Webページの読み込みが突然止まることがあります。TCPの再送は待ち時間を延ばし、連続したデータ転送もパケットロスやジッターの影響を受けます。最小値を何度も探すより、複数回の測定結果を確認するほうが有効です。

4. 実際のアプリが測定したノードを経由していない

Clash for Windowsでは、まずGeneral → System Proxyが有効か確認し、次にProxies → Ruleでルールモードと対象のプロキシグループを確認してください。Windowsのシステムプロキシ設定に従うアプリは通常この経路を使いますが、独自のネットワークスタックを持つアプリはシステムプロキシを無視することがあります。

Connectionsを開き、接続先のドメインで絞り込んで、適用されたルールとプロキシチェーンを確認してください。手動テストでは「日本の入口」を使っていても、実際の接続にDIRECTが適用されていれば、結果が一致しないのは当然です。自動選択グループ、手動選択グループ、ルールによる振り分けが何段にも入れ子になっている場合もあります。カードに表示された名前だけを見て判断しないでください。

5. UDP、DNS、アプリの通信方式がテストと異なる

HTTPSのテストが1回成功しても、UDP転送が使えるとは限りません。ゲームや音声通話、QUICを使うアプリでは、別のプロトコル経路が必要になることがあります。ブラウザーのキャッシュ、接続の再利用、DNSキャッシュ、Webサイト自体の応答速度も体感に影響します。TUNを使うと、システムプロキシに従わない接続もより広く取り込めますが、出口の帯域が増えるわけではなく、すべての通信がプロキシ経由になるとも限りません。最終的にはルーティング、ルール、除外設定によって決まります。

ノードがtimeoutと表示された場合：範囲を絞って原因を特定

timeoutは、指定した条件と時間内に今回のテストが成功しなかったことを示すだけで、「ノードが永久に使えない」とは限りません。まず、問題が1つのノードだけなのか、1つのテスト先だけなのか、ネットワーク全体なのかを確認してください。

1. すべてのノードで失敗する：まずローカルのネットワークが正常で、カーネルが動作していることを確認します。既知の正常な経路からテストURLにアクセスできるか試し、ログにDNSエラーや接続エラーがないか確認してください。
2. 1つのノードだけ失敗する：サブスクリプションが更新されているか、ノードの認証情報が有効か、使用中のプロトコルを現在のカーネルがサポートしているか確認してください。サブスクリプションを更新した後、対象ノードを選び直してテストします。
3. テスト先を変えると成功する：元のテスト先、証明書、名前解決、または接続経路に問題がある可能性が高いです。比較するときは、すべてのノードで同じ新しいURLを使い、測定条件をそろえてください。
4. 待機時間の上限が短すぎる：設定できる場合は、3000ミリ秒から一時的に5000ミリ秒へ延ばして試してください。待機時間を延ばすと応答の遅い接続を確認しやすくなりますが、混雑が解消したり回線が速くなったりするわけではありません。
5. 速度測定は成功するのにWebページが開かない：同じテストボタンを繰り返し押すのではなく、接続先のサイト、適用されたルール、アプリの通信経路を確認してください。

実際の使い心地に近いノードの比較方法

候補ノードは2～3個に絞ります。Windows Updateや大容量ファイルの同期を一時停止し、できるだけ同じ接続方法を保ってください。Wi-Fiを使う場合は、測定中に場所を変えないようにします。比較の前後で条件がそろっているか判断できるよう、クライアント、カーネル、テストURL、時間帯を記録してください。

1. プロキシ経路を固定：一時的に手動選択グループでノードを指定し、対象アプリの接続が実際にそのノードを経由していることを確認します。自動切り替えによる影響を防げます。
2. 軽量テストを繰り返す：同じURLを数秒間隔で5～10回測定し、中央値、最大値、失敗回数を記録します。最小値だけで判断しないでください。
3. 普段使うWebサイトを開く：日常的に使うサービスを2～3個開き、初回表示と再読み込みが安定するか確認します。ブラウザーの開発者ツールにある「ネットワーク」パネルもリクエスト時間の確認に役立ちますが、キャッシュやサーバーの処理時間も含まれます。
4. 連続転送を個別にテスト：ダウンロードが許可されている固定のファイル配信元を選び、30～60秒間の速度を確認します。通信量に注意し、並列接続数をそろえてください。記録した単位がMB/sかMbpsかも明記します。
5. 実際に使う時間帯にも再測定：平日の日中と夜間では混雑状況が異なることがあります。1回の順位だけで判断するより、2つの時間帯の測定結果を残すほうが確実です。

以下は比較方法を説明するための仮想データであり、このサイトでの実測値ではありません。どちらの回線も軽量リクエスト10回すべてに成功していますが、適した回線は用途によって異なります。

チャットやリモート操作、Web閲覧では応答性と安定性が重要です。ダウンロードでは継続的なスループットが重視されます。動画視聴ではビットレート、適応型バッファリング、CDNの割り当ても影響します。単位にも注意してください。理論上、8 Mbpsは約1 MB/sですが、実効速度はプロトコルのオーバーヘッド分だけ低くなります。

旧版Clash for Windowsを使う際の注意点

Clash for Windowsのメンテナンスは終了しています。旧環境を使い続ける場合は、General、Proxies、Connections、Logsから動作状況、ルールの適用先、エラー情報を確認できます。ただし、旧カーネルが新しいサブスクリプションのすべてのプロトコルやmihomoの設定項目に対応しているとは限りません。サブスクリプションを読み込めても、すべてのノードが正常に動作するとは限りません。

新たにインストールする場合は、クライアント比較で、Clash Verge RevやFlClashなど現在もメンテナンスされているプロジェクトの状況、対応プラットフォーム、カーネル対応状況を確認してください。クライアントを乗り換えた後は、システムプロキシ、待ち受けポート、テストURLをあらためて確認します。旧クライアントに残った過去の数値とそのまま比較しないでください。

最終的な確認手順：まず接続が正しいノードを経由しているか確認し、次に測定条件をそろえます。そのうえで複数回のリクエストの安定性を確認し、最後に実際の用途で帯域と使い心地を検証してください。url-testは利用可能な出口の選別に役立ちますが、回線全体の総合評価ではなく、測定結果の一つを示すものです。