Clashの遅延テストの仕組み：測定値とWeb・動画の体感速度が一致しない理由

Clashクライアントでノードを選ぶ際、最初に目に入る指標は通常、遅延値です。2つのノードがそれぞれ68 msと126 msなら、直感的には前者が「2倍速い」と考えがちです。しかし、この数値が示すのは、その時点の条件で特定のプローブに要した時間だけです。ダウンロード速度そのものではなく、Webページの読み込み、動画のバッファリング、ゲーム接続、大容量ファイル転送の実際の体感を完全に表すものでもありません。

遅延テストを理解するには、1回のネットワークアクセスを複数の段階に分けて考える必要があります。具体的には、名前解決、プロキシノードへの接続、プロキシプロトコルのハンドシェイク、ノード経由でのテスト先への接続、暗号化通信の確立、リクエスト送信、レスポンス待機、その後のデータ転送です。Clashクライアント、コアのバージョン、テスト方法によって計測対象が異なる場合があるため、同じノードでも2つのクライアントで異なる値が出るのは珍しくありません。

Clashの遅延値は何を測っているのか

多くのGUIクライアントでは「遅延テスト」や「速度テスト」と表記されていますが、内部処理は一般的なICMP Pingとは異なることがほとんどです。ClashやMihomoでは通常、指定したプロキシノード経由でテストURLへアクセスし、リクエストが成功するまでの時間を記録します。テスト先はステータスコード204など、ごく小さなHTTPレスポンスを返す場合が多いため、転送量はわずかです。その結果は、主に往復時間と接続確立のコストを反映します。

テストURLがHTTPSの場合、1回のプローブにTCP接続、プロキシプロトコルの処理、TLSハンドシェイク、HTTPレスポンス待機が含まれることがあります。接続の再利用、DNSキャッシュの有無、テスト先の応答性能も結果に影響します。クライアント画面には通常、これらをまとめたミリ秒値だけが表示され、各段階の所要時間は個別に示されません。

したがって、画面に表示される80 msは、「このノード経由で指定のリクエストを完了するまでに約80ミリ秒かかった」という意味に近い値です。ノードサーバーとローカル端末の純粋な物理距離を示すものでも、すべてのWebサイトで共通する固定値でもありません。テスト先を変えると、ノードの出口から対象サーバーまでの経路も変わるため、ノードの順位が入れ替わることがあります。

低遅延でもWebや動画が必ず速いとは限らない理由

遅延と帯域幅は別の指標です。遅延はリクエストの往復にかかる時間、帯域幅は単位時間あたりに転送できるデータ量を表します。小さなリクエストにはすぐ応答できるノードでも、出口帯域の不足、夜間の混雑、多人数での共有によって、継続ダウンロード時のスループットが低い場合があります。一方、初回応答が多少遅くても、利用可能な帯域が安定しているノードもあります。

Webページの読み込みには多くの処理が含まれる

現在のWebページは、HTML、スクリプト、スタイルシート、画像、APIデータ、外部リソースなどを読み込むのが一般的です。初回表示では、DNSルックアップ、TLSハンドシェイク、複数回の接続確立が発生することもあります。低遅延は小さなリクエスト間の待ち時間短縮に役立ちますが、ページ全体の所要時間は、リソース数、サーバー処理時間、ブラウザーキャッシュ、HTTP接続の再利用、アクセス先の負荷にも左右されます。

あるノードが遅延テスト先へ高速に接続できても、実際のWebページが利用するCDNエッジも速いとは限りません。テスト先と実際のWebサイトは、所在国、通信事業者、ASが異なる場合があり、ノード出口からそれぞれへの経路品質も大きく異なることがあります。

動画の体感は継続スループットと安定性に左右される

動画プレーヤーは通常、コンテンツをセグメント単位でダウンロードし、直近の転送速度に応じて画質を調整します。動画のビットレートを上回るスループットを継続して確保できれば、基礎遅延が多少高くても体感への影響は限定的です。反対に、遅延が低くてもスループットが頻繁に落ちるノードでは、画質低下、バッファリング時間の増加、再生中断が起こる可能性があります。

テストリクエストのデータ量は非常に小さいため、転送が安定状態に入る前に終了することが多く、数十秒後の混雑状況も確認しにくくなります。動画用途では、1回だけ記録した最小遅延より、継続的に利用できる帯域幅、ジッター、パケットロスの方が参考になります。

インタラクティブ用途ではジッターとパケットロスも重要

リモートターミナル、音声通話、一部のリアルタイムアプリは遅延の影響を受けやすいものの、平均値だけでは体感を十分に表せません。連続測定で70、72、75 msとなるノードは、45、180、60、260 msの間を上下するノードより、一般に安定しています。後者は一時的に低い値を示しても、ジッターや再送によって目立つ停止が発生することがあります。

同じノードの遅延が繰り返し変化する理由

遅延はノード固有の恒久的な値ではなく、測定時刻、入口、出口、テスト先の組み合わせによって決まる結果です。短時間の連続テストで数十ミリ秒の差が出るのは珍しくありません。変動幅が大きい場合は、ローカルネットワーク、プロキシ経路、テスト先のどこが不安定なのかを切り分ける必要があります。

1. ローカルのアクセス回線が変動している。 Wi-Fiの電波干渉、モバイル回線の切り替え、ルーター内のキュー、ほかの端末によるアップロード帯域の使用によって、プローブの待ち時間が延びることがあります。LAN側の問題をノード障害と誤認しないため、まず安定したネットワークで繰り返しテストしてください。
2. ISPの経路が変化している。 ローカル環境からノードまでの経路は常に同じとは限りません。時間帯によって異なる中継回線を通ることがあり、夜間の混雑時にはキュー遅延やパケットロスが発生する場合もあります。
3. プロキシサーバーの負荷が変化している。 ノードは接続、プロトコルのハンドシェイク、転送を処理します。CPU使用率、接続数、出口帯域、システムのスケジューリングはいずれも応答時間に影響します。
4. テスト先の状態が変化している。 テストサーバー側で帯域制限がかかったり、別のアドレスへ振り分けられたり、ノードの出口ごとに異なる経路が使われたりすることがあります。テスト先が一時的に混雑すると、すべてのノードが同時に遅くなる場合もあります。
5. DNSキャッシュと接続再利用の状態が異なる。 最初のプローブには名前解決と新規接続の確立が含まれ、その後はキャッシュや既存接続が使われる場合があります。クライアントとコアのテスト方法によっては、前後の結果をそのまま比較できないことがあります。
6. 同時テストによる競合が発生している。 数十個のノードへ一斉にリクエストすると、ローカル接続、アップロード帯域、システムリソースを消費します。一括結果は一次選別に向いていますが、最終判断には候補を絞った連続再テストの方が適しています。

url-testプロキシグループが遅延結果を使う仕組み

ClashとMihomoの設定では、url-testは自動選択用のプロキシグループです。コアが設定済みURLを使ってグループ内のプロキシをチェックし、利用可能で遅延の低いノードを優先して選びます。同じような用途のノード群から自動選択するのに適していますが、その結果はテスト先の影響を受けます。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

intervalは定期チェックの間隔を指定します。例の300は、300秒ごとにチェックする設定です。短すぎる間隔はプローブとノードへの接続回数を増やし、長すぎる間隔は回線状態の変化をすぐに検出できない原因になります。家庭用ネットワークや日常的なブラウジングでは、数秒おきに更新する必要は通常ありません。

toleranceは切り替え許容値を設定する項目です。現在のノードと候補ノードの遅延差が指定範囲を超えない場合、わずかな数値変動による頻繁な切り替えを防げます。出口が頻繁に変わると既存接続に影響するほか、ログイン先のサービスに接続元アドレスの変化を検知される場合があります。常に数ミリ秒の最小値を追うより、適切な許容値を設けた方が安定しやすくなります。

lazyの具体的な動作は、使用しているコアのバージョンで確認してください。一般には、プロキシグループに実際の通信需要がないとき、能動的なチェックを減らす目的で使われます。サブスクリプションから配信された設定では、パラメーター名だけを見て安易に変更しないでください。更新時にローカル変更が上書きされる場合があり、クライアント側のオーバーライド機能でプロキシグループを管理していることもあります。

テストURLには、安定していてレスポンスボディが小さく、主な利用先とある程度経路の関連性があるものを選びます。普段アクセスするサービスとテスト先のネットワーク上の位置が大きく異なる場合、自動選択された最低遅延ノードが実際の用途でも最適とは限りません。また、HTTPとHTTPSでは結果が異なることがあります。HTTPSのテストには暗号化通信の確立も含まれるためです。

ルールモード、TUNモードと遅延テストの関係

遅延テストは通常、Clashコアが指定プロキシ経由で直接実行します。ブラウザー通信がシステムプロキシやTUNに完全に取り込まれた場合の挙動と同じではありません。クライアント上でノードが利用可能と表示されても、それはコアからテスト先へのプローブが成功したことを示すだけです。ブラウザーでWebページが開けない場合は、システムプロキシ、ルールの一致、DNS、アプリのプロキシ除外なども確認する必要があります。

ルールモードでは、実際の通信が上から順にルールと照合され、最初に一致したルールのポリシーで接続先が決まります。ノードテストでは特定のプロキシを直接指定していても、実際のWebリクエストは別のプロキシグループ、DIRECTルール、ブロックルールに一致する場合があります。トラブル対処では、プロキシグループ画面の遅延値だけで推測せず、接続履歴やログを見て、対象ドメインに実際に適用されたポリシーを確認してください。

TUNモードは、システムプロキシ設定に従わない通信も広く取り込みますが、プロキシノードの物理的な回線品質を自動で向上させる機能ではありません。TUNを有効にすると、DNS処理、ルーティングテーブル、ネットワークスタック、ファイアウォール権限が実際の接続に関係します。ノードの遅延が正常でもアプリが通信できない場合は、TUNが起動しているか、DNSが到達可能なアドレスを返しているか、ルールに正しく一致しているか、対象アプリが特殊なネットワークプロトコルを使っていないかを個別に確認してください。

ノード選びで遅延データを正しく使う方法

ノードを比較する際は、まず遅延値を絞り込みに使い、その後で安定性と実際の用途を検証します。72 msと79 msの間で何度も切り替える必要はありません。この程度の差は、1回のネットワーク変動で簡単に逆転します。それよりも、ノードが継続して利用できるか、連続テストの値が安定しているか、実際のアクセス先で目立つ停止が起きないかを重視してください。

1. まず一括テストで候補を絞る。 タイムアウトが続くノードや、明らかに遅延が高いノードを除外します。タイムアウトしても完全に利用不能とは限りませんが、現在の条件ではテストを完了できていないため、後で個別に検証してください。
2. 候補ノードを連続して再テストする。 3〜5個の候補を選び、時間を空けて繰り返し測定します。最低値を1回だけ記録するのではなく、結果の変動幅を確認してください。
3. 実際のアクセス先で検証する。 普段使うWebサイトを閲覧し、一般的な画質で動画を再生するか、日常業務で使うダウンロードや接続処理を実行します。数分間継続して試すと、混雑やスループットの変動を見つけやすくなります。
4. 用途別にグループを分ける。 Web閲覧、動画、低遅延のインタラクティブ通信では、重視すべきネットワーク指標が異なります。プロキシグループとルールを使ってアクセス先ごとにノードを分ければ、1つのノードですべての用途をまかなう必要はありません。
5. 安定したノードを予備として残す。 最低遅延のノードが不安定になったときは、その場で探し直すより、安定した候補へ切り替える方が実用的です。fallbackプロキシグループでは、単に最低遅延を選ぶのではなく、可用性チェックと障害時の切り替えを重視します。

遅延異常を切り分ける順序

すべてのノードが突然高遅延またはタイムアウトになった場合、ノード設定を1つずつ変更するのではなく、まず共通経路を確認してください。すべてのノードは、ローカル端末、LAN、DNS環境、テスト先、クライアントコアを共有しています。どこか1か所に異常があるだけで、一覧全体から結果が得られなくなる可能性があります。

第1段階：ローカルネットワーク

端末から普段使うサイトへ直接接続できることを確認し、Wi-Fiの電波状況、モバイル回線の状態、ルーターの負荷を調べます。大容量ファイルのアップロード、クラウドストレージの同期、LAN内の高負荷タスクを一時停止してから、再度テストしてください。別のアクセス回線へ切り替えて改善する場合、原因は元のLANまたはISP経路にある可能性が高くなります。

第2段階：クライアントとコア

設定が正常に読み込まれているか、プロキシノードにプロトコルやパラメーターのエラーが表示されていないか、コントロールポートとコアプロセスが動作しているかを確認します。サブスクリプション更新後に全ノードで異常が出た場合は、以前起動できていた設定のコピーへ戻し、サブスクリプションの構造、プロキシグループの参照、オーバーライド設定の変更が原因か比較してください。

第3段階：テスト先

ノード経由で実際のWebページにはアクセスできるのに、遅延テストがすべてタイムアウトする場合は、プローブ先を疑います。小さなレスポンスを安定して返すテストURLへ変更し、もう一度比較してください。複数の条件を一度に変えず、毎回1つだけ変更すると、原因がテスト先なのかノード経路なのかを判断できます。

第4段階：ノードと回線

一部のノードだけ遅延が高い場合は、それらが同じ地域にあるか、同じ入口や回線を使っているか確認します。日中は安定し、夜間に継続して遅くなる場合は、長時間の測定結果も合わせて時間帯による混雑の有無を判断してください。1回だけ低い値に戻っても、問題が解消した証拠にはなりません。

ミリ秒値を適切な判断材料として使う

Clashの遅延テストは、軽量かつ短時間で比較できるネットワークプローブの結果を提供します。到達不能なノードの除外、明らかに遅延が高い回線の発見、url-testによる自動選択の判断材料として役立ちます。ただし、Webの体感はDNS、ルールの一致、アクセス先への経路、リソースの読み込み方式にも左右されます。動画とダウンロードでは、継続スループット、混雑度、パケットロスがより重要です。

より確実なのは、遅延値で一次選別し、連続テストでジッターを確認したうえで、実際のアクセスによって帯域幅と安定性を検証する方法です。近い数値が並んでいるとき、絶対的な最小値にこだわる必要はありません。接続が安定し、実際のアクセス先を利用でき、ポリシーの切り替えが頻繁すぎないことの方が、一時的に十数ミリ秒だけ速いことより重要です。