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

1. ノードの遅延を示すミリ秒は、ダウンロード速度ではない

Clashクライアントの「速度測定」は、多くの場合、カーネルが実行するURL遅延テストを指し、大容量ファイルをダウンロードして帯域幅を測るものではありません。画面に表示される 120 ms は、小さなリクエストにかかった時間を示す値で、1秒あたりにダウンロードできるデータ量には換算できません。主に接続確立から応答までの待ち時間を表し、継続的な転送能力は測定しません。

わかりやすく「ハンドシェイクにかかる時間」と呼ぶことはできますが、技術的にはそれだけではありません。カーネルの実装、プロキシプロトコル、接続の再利用の有無、HTTPまたはHTTPSのテストURLなどによって、計測範囲は変わります。この数値は純粋なTCPハンドシェイク時間でも、システムの ping コマンドで測るICMPの往復時間でもありません。

たとえば、ノードAの遅延は80 msでダウンロード速度は2 MB/s、ノードBは160 msで15 MB/sだとします。これは説明用の例であり、本サイトでの実測値ではありません。Aは短いリクエストへの応答が速く、Bは大容量ファイルの転送に向いている可能性があります。帯域幅、混雑、単一接続の制限は、一度の小さなリクエストでは測れないため、結果に矛盾はありません。

2. url-testのリクエストはどのように処理されるか

url-testは、プロキシグループの種類の一つです。カーネルはグループ内の候補ノードを経由して指定URLにアクセスし、テスト結果を取得したうえで、接続可否や遅延、許容差などをもとにノードを選びます。GUIの「全ノードをテスト」もカーネルの遅延テスト機能を呼び出す場合がありますが、プロキシグループと同じURL、タイムアウト、実行条件を使うとは限りません。

HTTPSテストの一般的な流れ

1. テスト先を決める：テストURL（例：https://www.gstatic.com/generate_204）を読み込みます。このパスは通常、ダウンロードする本文のないHTTP 204を返します。
2. プロキシ経路を確立する：端末から候補ノードに接続し、プロキシプロトコルに必要な接続処理を行います。ノードのアドレス解決やトランスポート層、プロトコルのハンドシェイクに時間がかかる場合があります。
3. テストサイトにアクセスする：プロキシの出口を経由して接続します。HTTPSでは、接続先サイトとのTLSネゴシエーションも行われます。接続先ドメインをどちら側で名前解決するかは、プロトコルと実際の設定によって異なり、常に端末側で解決するとは限りません。
4. 応答を受け取り、結果を記録する：カーネルは実装に応じてリクエストの所要時間を記録し、結果またはエラーを返します。クライアントによって、失敗時の表示は「タイムアウト」、赤色のマーク、利用不可など異なります。

ノードのテストは通常、指定したプロキシの出口を対象に行われます。テストURLへのアクセスが、ブラウザーで普段のルールに従って通信する場合と同じとは限りません。実際のアプリ通信は、ルールにより直接接続、別のプロキシグループ、別ノードに振り分けられることがあります。「テストは速いのにウェブページが遅い」ときは、テストURLをすぐ変えるのではなく、まず接続ログでページがどの出口を使っているか確認しましょう。

3. テストURL・タイムアウト・テスト間隔の設定方法

以下は、これらの項目に対応するmihomoカーネル向けの設定例です。mihomoは、Clash Metaの後継プロジェクトで使われている名称です。旧版Clashや一部クライアントのGUI設定では、すべての項目を利用できない場合があります。まずクライアントに表示されるカーネルの種類を確認し、対応するカーネルのドキュメントを参照してください。この設定例を完全なサブスクリプションファイルとして、そのまま置き換えないでください。

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

ここで使う 香港-01 と 日本-01 は、既存の proxies にある名前と完全に一致させる必要があります。プロキシプロバイダーを使う場合は、カーネルが対応していれば use でプロバイダーを参照することもできます。ノードを定義していないファイルにこの部分だけを貼り付けても、通信できるようにはなりません。

• url：応答が小さく、経路が安定していて、普段のアクセス先を反映するURLを選びます。HTTPとHTTPSではハンドシェイクが異なるため、プロトコルを切り替えた後に以前の数値と単純に比較するのは避けましょう。
• interval: 300：自動チェックの間隔は300秒、つまり5分です。接続タイムアウトではなく、300ミリ秒ごとにテストする設定でもありません。
• timeout: 5000：1回のテストのタイムアウト上限は5000ミリ秒です。短すぎると一時的な混雑を接続不能と誤判定することがあります。長くしても、使えなくなったノードが直るわけではありません。
• tolerance: 50：切り替えの許容差は50ミリ秒です。遅延の小さな変動による頻繁な切り替えを抑えるための設定で、帯域幅のしきい値ではなく、表示遅延から50を差し引く設定でもありません。
• lazy: true：遅延チェックを有効にします。グループが使われていない間は、定期テストが省略される場合があります。すべてのノードが常に5分ごとに更新されるとは限りません。

数値を小さくするためだけにテストURLを変えない

テストサイトの地域、CDNの振り分け、出口回線の接続先によって結果は変わります。出口に非常に近いURLに変えれば数値は小さくなるかもしれませんが、普段使うサイトへの経路が改善するとは限りません。ノードを比較する際は、URL、ネットワーク環境、テスト方法をそろえましょう。特定のサイトの問題を調べる場合は、そのサイトの軽量なアクセス可能リソースも補助的にテストします。

数百のノードのテスト間隔を一律に10秒にするのもおすすめしません。頻繁なテストは接続数や通信量、端末の負荷を増やし、接続先でレート制限を受ける可能性もあります。普段はまず300秒間隔で様子を見て、問題が起きたときに手動で数回再テストするほうが、高頻度で更新し続けるより原因を把握しやすくなります。

4. 遅延が小さいのにウェブや動画が遅い理由

小さなリクエストが成功しても、混雑時の帯域幅はわからない

204リクエストでやり取りするデータはごくわずかです。出口の帯域幅が混雑していてもすぐに完了することがありますが、動画のセグメントや大容量ファイルの転送では回線を継続的に使います。サーバー側の速度制限、共有出口の負荷、ネットワーク間の接続、端末側Wi-Fiのパケットロスなどにより、実効速度は低下します。

実際のサイトとテストサイトでは、ノード以降の経路が異なる

端末からプロキシノードまでの経路は、通信の前半にすぎません。ノードからテストサイトと、ノードから動画サイトでは、まったく異なる回線を通ることがあります。あるテストURLが速くても、別のCDNまで速いとは限りません。接続先の地域別ルール、負荷、出口IPへの制限が、利用可否に直接影響することもあります。

ブラウザーがテストと同じノードを使っていない

• ルールモードでは、ドメインが DIRECT に一致したり、別のプロキシグループに振り分けられたりする場合があります。接続ログを開き、対象ドメイン、適用されたルール、最終的なプロキシ経路を確認しましょう。
• システムプロキシの設定が適用されるのは、通常、その設定に従うアプリだけです。ゲーム、独自のネットワーク機能を使うアプリ、一部のコマンドラインツールでは利用されないことがあります。
• TUNは仮想ネットワークアダプターを使って対象の通信を取り込みますが、その範囲はルーティング、除外設定、DNS設定にも左右されます。TUNを有効にしても、ノードの帯域幅が自動的に増えるわけではありません。
• ブラウザーが再利用する長時間接続は、プロキシを切り替えてもすぐには張り直されない場合があります。切り替えの効果を試す際は、対象アプリを開き直し、必要に応じて関連する接続だけを切断してください。進行中のダウンロードを中断しないよう注意しましょう。

単位の取り違えにも注意してください。理論上、8 Mbpsは約1 MB/sに相当しますが、実際にはプロトコルのオーバーヘッド分だけ低下します。通信事業者の公称帯域、速度測定サイトの表示、ダウンロードツールの表示単位が異なる場合は、まず単位を換算してから速度に異常があるか判断しましょう。

5. 遅延・帯域幅・安定性の3点でノードを選ぶ

ノードを選ぶときは、まず接続できないものを除外し、次に安定性を確認して、最後に用途に応じて転送速度を比較します。リストの並び順だけに頼らないでください。また、自動切り替えを有効にしたまま固定ノードの速度を比べると、測定対象が途中で変わる可能性があります。

1. 条件をそろえる：同じ端末、同じネットワークでテストし、バックグラウンドのダウンロードを一時停止します。候補ノードは手動選択グループで固定し、実際の通信もそのノードを経由していることを確認してください。
2. 複数回の遅延を確認する：約10秒間隔で手動テストを5回行い、結果と失敗回数を記録します。これは短時間のトラブル調査向けであり、自動テストを常時10秒間隔にすることを推奨するものではありません。
3. 連続転送をテストする：信頼できる同じダウンロード先を使い、30～60秒間テストして、開始直後のピークではなく速度が安定した後の値を記録します。速度測定では通信量を消費するため、従量課金の回線では先にデータ残量を確認してください。
4. 実際の用途で確認する：動画ではバッファリングやシーク後の再生再開、リモート端末では入力への応答、会議では切断や音声の途切れを確認します。URLテストはUDPを使うサービスのテストには代用できません。

表の数値は記録方法を示すための例であり、特定のサービス事業者での実測値ではありません。Aの遅延の中央値は83 ms、Bは153 msです。Cは5回中1回失敗しており、サンプル上の失敗率は20％です。回数が少ないため長期的な故障率は推定できませんが、Cの最小値が70 msだからといって優先せず、継続して確認する必要があることはわかります。

6. タイムアウト・テスト結果の不一致・自動切り替えの確認手順

すべてのノードがタイムアウトする

まず端末の基本的なネットワーク接続が使えること、サブスクリプションの有効期限が切れていないこと、端末の日付と時刻が正しいことを確認します。次にカーネルログを確認してください。timeoutは制限時間内に処理が完了しなかったことを示します。connection refusedは通常、接続が拒否されたことを意味します。証明書関連のエラーが出る場合は、時刻、接続先の証明書、ネットワークによる干渉を確認します。すべての失敗を「ノードが遅い」と決めつけないでください。

次に、アクセスできることがわかっている別の軽量なテストURLでも試します。元のURLだけ失敗する場合は、接続先のサービスか、出口から接続先までの経路を調べましょう。複数のURLで失敗する場合は、ノードの設定、ローカルネットワーク、ファイアウォールを確認します。証明書エラーを解消するために検証機能を無効にすると、根本原因を見逃すおそれがあります。

GUIの速度測定と自動選択グループの結果が異なる

両者で使っているURL、タイムアウト、最終更新時刻を確認します。GUIからの手動テスト、url-testプロキシグループ、proxy-providersのhealth-checkは別々の設定項目です。一か所を変更すればすべてに反映されるとは限りません。サブスクリプションの更新でローカル編集が上書きされることもあるため、設定を維持する場合は、クライアントが対応する上書き設定またはマージ設定を使いましょう。

最速のノードがすぐに選ばれない

実際の通信でurl-testグループを使っていることを確認してください。手動選択グループやfallbackグループでは、動作が異なります。fallbackは主に登録順に利用可能な候補を選ぶもので、遅延が最小のノードを単純に選ぶ機能ではありません。url-testでも、許容差、テストの更新タイミング、遅延チェックの動作、既存の接続を考慮する必要があります。数ミリ秒の差で頻繁に切り替える必要は通常ありません。