Clashの速度測定値と実際の使用感が異なる理由｜url-testの遅延測定を解説

Clashの遅延測定値が示すのは1回のリクエスト。ダウンロード速度とは別

ノードの横に表示される「80 ms」は、通常、そのプロキシ経由でHTTPまたはHTTPSのテストを1回行ったときの時間です。msはミリ秒で、テストにかかった時間を示します。一方、MB/sは1秒あたりに転送できるメガバイト数、つまり継続的な転送能力を表します。両者には関係がありますが、相互に換算できるものではありません。80 msだからといって、ダウンロード速度が8 MB/sになるとは限りません。

Clashの設定にあるurl-testは、プロキシグループの自動選択方式の一つです。候補のプロキシから指定したテスト先にアクセスし、その結果をもとに利用するプロキシを選びます。クライアント画面の「速度測定」ボタンも、コアの遅延測定機能を使う場合がありますが、ボタンのテスト先やタイムアウト設定は、設定ファイル内の自動選択グループと異なることがあります。

Clash Metaに関する説明は、後継名称として使われているmihomoにも当てはまります。クライアントによって画面の構成は異なり、コアのバージョンやテスト条件も変わることがあります。比較する前に、テスト先、ネットワーク環境、測定時間帯をそろえましょう。

url-testのリクエストはどのような経路を通るのか

システムコマンドのpingとは異なる

一般にシステムのpingは、ICMPエコー要求を送信します。一方、ClashのURLテストは、プロキシ経由でWebサイトにアクセスします。プロキシサーバーがICMPに応答しなくても、Webリクエストを転送できる場合があります。反対に、サーバーへのping値が低くても、プロキシの出口から目的のWebサイトへ速くアクセスできるとは限りません。

新しいHTTPS接続をテストする場合、端末からプロキシの入口への接続、プロキシプロトコルのハンドシェイク、出口からテストサイトへの接続、TLSハンドシェイクなどが発生することがあります。TLSはHTTPSで暗号化通信を確立するためのプロトコルです。DNSの名前解決、接続の再利用、プロトコルの実装も結果に影響するため、表示値を単純に「PCからノードサーバーまでの往復時間」と捉えることはできません。

1. プロキシの入口に接続：自宅の回線、Wi-Fiの干渉、通信事業者の経路、入口側の混雑が影響します。
2. プロキシ接続を確立：プロトコルやトランスポート層の違い、既存の接続を再利用できるかどうかで、接続確立にかかる時間が変わります。
3. テスト先へアクセス：プロキシ出口からテストサイトまでの経路、サイトの応答速度、ドメインの名前解決結果などが、最終的な結果に影響します。
4. テスト結果を返す：コアは1回のリクエストにかかった時間を記録します。計測の開始・終了位置は実装によって異なるため、数値を決まった回数のハンドシェイクに分解して考えるのは適切ではありません。

204を返すテスト先がよく使われる理由

HTTPステータスコード204は、リクエストが成功したものの、レスポンス本文がないことを示します。このようなテストは転送量が小さく、プロキシが利用可能かどうかを頻繁に確認するのに適しています。一方、大きなファイルをほとんど転送しないため、回線を使い続けた場合のスループットや、動画を10分間再生したときの安定性は測れません。

初回と2回目以降の測定では、DNSキャッシュ、接続の再利用、サーバーのキャッシュ状態も結果に影響することがあります。最低値だけを記録するのではなく、数回続けて測定し、ばらつきやタイムアウトの回数も確認すると、実際の利用状況に近い判断ができます。

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

1. 小さなリクエストは速くても、持続的な帯域幅が足りない

小さなリクエストなら約60 msで完了する回線でも、実効スループットが2 Mbpsしかないことがあります。10進法で概算すると、3 MBのダウンロードに約12秒かかり、さらに通信のオーバーヘッドが加わります。別の回線は遅延が160 msでも、50 Mbpsで安定して転送できれば、大きな画像や動画はかえって快適に読み込めることがあります。

Mbpsはメガビット毎秒、MB/sはメガバイト毎秒で、約8倍の差があります。たとえば40 Mbpsは、理論上およそ5 MB/sです。クライアント、ブラウザー、速度測定サイトの数値を比較するときは、まず単位を確認しましょう。

2. テスト先への接続は速くても、目的のサイトへの経路が異なる

テストサイトはCDN経由で配信されている場合があります。CDN（コンテンツ配信ネットワーク）は、リクエストをエッジサーバーに振り分けます。プロキシからそのエッジサーバーへ速く接続できても、別の地域にある動画サイト、コードリポジトリ、ゲームサーバーにも同じように速く接続できるとは限りません。

そのため、「ノードAは70 ms、ノードBは130 ms」という結果が示すのは、その時点で各ノードからテスト先へアクセスしたときの状況だけです。コードのダウンロードが主な用途なら、実際に使うリポジトリでもテストしましょう。動画をよく見るなら、利用するプラットフォームでバッファリング速度、画質、コマ落ちを確認してください。

3. 一時的なパケットロスや夜間の混雑

1回だけの測定では、たまたま混雑を避けて見栄えのよい数値が出ることがあります。しかし、長時間の接続でパケットロスが起きると、再送や速度低下が発生し、接続し直しが必要になる場合もあります。5回の測定結果が65、68、72、980 ms、タイムアウトなら、問題は「平均遅延が少し高い」ことではなく、安定性が不足していることです。

20時の回線の混雑状況は、10時とは大きく異なることがあります。実際に使う時間帯に比較し、早朝の1回の測定結果で夜間の使用感を判断しないようにしましょう。

4. 実際の通信が測定したノードを経由していない

ルールモードでは、ルールとプロキシグループに基づいて通信の出口が決まります。「自動選択」グループを測定しても、目的のドメインには別のグループが適用される場合や、DIRECT、つまりプロキシを経由しない直接接続になる場合があります。システムプロキシの設定が反映されるのは、その設定に従うアプリだけです。TUNモードは仮想ネットワークインターフェースを使って通信を取り込みますが、対象範囲はルーティングや除外設定によって異なります。

クライアントの「接続」画面を開き、目的のドメインを見つけて、適用されたルール、プロキシグループの経路、最終的なノードを確認しましょう。「ノードを切り替えたのに変化がない」理由を調べるには、速度測定を何度も実行するより効果的です。リクエストが一覧に表示されない場合は、アプリがプロキシを経由しているか、接続履歴の絞り込み条件が適切かも確認してください。

5. DNS、アプリ、端末がページ表示を遅くしている

Webページでは、複数のドメインから画像、スクリプト、ログイン用APIなどを読み込むことがあります。特定ドメインの名前解決に時間がかかる、拡張機能が干渉する、端末のCPU使用率が高いといった要因でも、ページの表示が遅くなります。短時間のURLテストでは、こうした問題を把握できません。動画のバッファリングが十分なのにコマ落ちが続く場合は、ノードを変えるだけでなく、ハードウェアデコードや端末の負荷も確認しましょう。

url-testの設定：テスト先、間隔、許容差の役割

以下はmihomoのプロキシグループ設定例です。設定ファイル内に「香港01」と「日本01」というプロキシが定義されているものとします。既存のYAMLに追加する場合は、元のプロキシ定義やほかのグループを残し、ルールからこのグループが実際に参照されるようにしてください。YAMLはインデントで階層を表すため、スペースの代わりにTabを使わないでください。

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

tolerance: 50は、測定結果に50 msを加減する設定でも、遅延を50 ms未満に保証する設定でもありません。自動選択で切り替えるかどうかの判定に影響します。実際の動作は、現在のプロキシの状態、テストに成功したかどうか、コアの実装にも左右されるため、2つの測定値だけから毎回の切り替えを予測することはできません。

サブスクリプションの更新によって、プロキシグループを直接編集した内容が上書きされる場合があります。長期的に設定を変更する場合は、クライアントのオーバーライド機能や設定のマージ機能を使い、最終的に適用された設定を確認しましょう。項目名や場所はクライアントのバージョンによって異なるため、エディターに保存された内容だけで判断しないでください。

10分で比較できる測定結果をそろえる

すべてのノードを一度に測定する必要はありません。まず利用地域に合った候補を2～3個選び、同じ手順で比較しましょう。以下の数値は判断方法を説明するための例であり、このサイトで実測した結果ではありません。

1. 環境をそろえる：同じ端末、同じネットワークを使い、大容量ファイルの同期を一時停止します。システムプロキシとTUNのどちらを使っているか、実際に利用するプロキシグループも記録します。
2. 出口を確認する：「接続」画面で対象のリクエストを開き、最終的なノードを確認します。ノードを手動で選ぶ場合は、対象ルールが実際に適用されるプロキシグループを操作してください。
3. 繰り返し測定する：同じテスト先を使い、ノードごとに5回、5～10秒ほど間隔を空けて測定します。最低値だけでなく、中央値、最高値、タイムアウトの回数も記録してください。
4. 転送速度も測る：同じ配信元から大きめのファイルを30～60秒ダウンロードし、速度が安定したときの値を確認します。ファイルがブラウザーのキャッシュから直接読み込まれていないことを確かめ、サブスクリプションの通信量にも注意してください。
5. 実際の用途で確かめる：普段使うWebサイトを開くか、同じ画質の動画を3分間再生します。最後に、普段利用する時間帯でもう一度測定しましょう。

音声通話やリモート操作では遅延と揺らぎが重要です。動画や大容量ファイルでは継続的なスループットがより重視されます。ゲームではUDPの経路も別途確認してください。HTTPテストに成功してもUDPが使えるとは限らず、ゲーム内の遅延測定の代わりにもなりません。

異常値や自動選択のトラブルを症状別に確認

timeout、負の値、空欄が表示される

多くの場合、テストに失敗した、有効な結果を取得できなかった、または表示が更新されていない状態です。具体的な表示はクライアントによって異なります。ノードが完全に使えないとは限らず、テスト先に接続できない、タイムアウト時間が短すぎる、プロキシプロトコルの設定が合っていない可能性もあります。まず実際のWebサイトを手動で開き、クライアントのログで接続エラーを確認してください。ログを共有する前に、サブスクリプションURL、トークン、ノードの認証情報を隠しましょう。

0 msと表示される。非常に速いということ？

そうとは限りません。0は、数値の丸め、画面の初期値、一時的な異常値などで表示されることがあります。クライアントの実装を確認したうえで、再測定し、実際のリクエストがどの出口を経由し、どれだけ時間がかかったかを確認してください。地域をまたぐプロキシで0 msが長時間固定される場合は、テストが実行されているか特に確認が必要です。

自動選択で数値は最も低いのに使いにくいノードが選ばれる

url-testは主に遅延測定値をもとに動作し、動画のバッファリング、帯域幅の上限、サービスの地域制限、通信量の倍率までは判断しません。まず候補を絞り、実際の用途で問題ないことを確認したノードだけを自動選択に含めましょう。接続地域を固定したいサービスには専用のプロキシグループを設定し、異なる地域のノードを1つの自動選択グループにまとめないようにしてください。

グローバルモードにすると速くなる？

グローバルモードで変わるのは通信の振り分け方であり、回線の帯域幅が直接増えるわけではありません。一時的に切り替えると、ルールによる振り分けが結果に影響しているか確認できます。テスト後は元のルールモードに戻し、「接続」画面で出口を確認してください。システムプロキシとTUNも単純な「速度切り替え」ではなく、アプリの通信を取り込む必要があるかを基準に選びましょう。