Clashのノード遅延テストの仕組み：表示されるミリ秒数が実際の通信速度と一致しない理由

遅延の数値は実際に何を測っているのか

Clashクライアントに表示される38 ms、126 ms、480 msといった数値は、一般的なICMP Pingでもダウンロード速度でもありません。通常はClashまたはmihomoのコアが指定されたプロキシノード経由でHTTPまたはHTTPSの測定URLへアクセスし、リクエスト開始から有効なレスポンスを受け取るまでの時間を記録します。クライアントによってボタン名は「遅延テスト」「速度テスト」「ヘルスチェック」など異なりますが、目的はほぼ同じです。ノードに接続できるかを確認し、短いリクエストの往復時間を推定します。

一般的な測定先はHTTP 204を返します。204レスポンスには本文がなく転送量も少ないため、繰り返しの疎通確認に適しています。たとえば https://www.gstatic.com/generate_204 と https://cp.cloudflare.com/generate_204 はこのタイプのURLです。レスポンス本文がほぼゼロなので、測定結果は主に接続確立とリクエスト応答の速さを示します。ノードが100 MBのファイルを継続転送した場合に何MB/s出るかまでは分かりません。

1回のHTTPS遅延テストに含まれる可能性がある手順

Clashがクライアントから送られたテスト指示を受け取り、プロキシノードを1つ選択します。
コアがノードサーバーのアドレスを解析し、ノード入口までTCPまたは別の転送接続を確立します。
Shadowsocks、VMess、VLESS、Trojanなど、使用するプロトコルに必要なハンドシェイクを完了します。
ノード経由で測定サイトへ接続し、対象サイトとのTCPおよびTLSハンドシェイクを完了します。
HTTPリクエストを送信し、ステータスコードとレスポンスヘッダーが返るのを待ちます。
クライアントが一連の所要時間をミリ秒に換算して表示します。

計測の開始点と終了点は、クライアントやコアのバージョンによって異なります。毎回新しい接続を作る実装もあれば、ヘルスチェックで一部のリソースを再利用する場合もあります。DNS名前解決を計測に含めるものや、DNSキャッシュを利用するものもあります。そのため、同じノードを2つのクライアントで同時に測ると、20～80 ms程度の差が出ることは珍しくありません。ノードの状態を判断するときは、同じ端末、同じクライアント、同じ測定URLで得た結果を優先して比較しましょう。

低遅延のノードでも遅いのはなぜか

低遅延は短い接続テストが速いことを示すだけです。Webページの読み込み、ソフトウェアのダウンロード、動画再生は、スループット、パケットロス、接続先までの経路、サーバー負荷にも左右されます。測定リクエストは少量のレスポンスヘッダーしか受け取らないため、ノードの出口が5 Mbpsに制限されていても、204リクエストなら50 ms以内に完了することがあります。実際にファイルをダウンロードすると、5 Mbpsの理論上限は約0.625 MB/sであり、速度差が継続して現れます。

ノードの帯域幅不足や共有入口の混雑

プロキシの入口は通常、複数のユーザーで共有されています。20:00～23:00の同時利用トラフィックは、午前中より大幅に増えることがあります。空いている時間帯に45 msだったノードが、混雑時も58 ms程度を保っていても、ダウンロード速度は18 MB/sから2.4 MB/sへ落ちる可能性があります。小さなリクエストは短時間でキュー処理できても、大容量通信では出口帯域を長時間奪い合うためです。

パケットロスとジッターは直接表示されない

クライアントは直近1回の成功結果だけを表示したり、複数回の結果から1つの値だけを表示したりすることがあります。たとえば10回の結果が52、54、55、53、410、タイムアウト、61、58、390、57 msだったとしても、画面に最後の57 msだけが残れば、目立つジッターやパケットロスは隠れてしまいます。Webページで多数のリクエストを同時に処理すると、再送が繰り返され、画像が段階的に表示されたり、ページが一時停止したりします。

測定サイトと実際の接続先では経路が異なる

ノードから測定URLまでの経路が短くても、コードホスティング、動画サービス、オンラインストレージまでの経路が同じように良好とは限りません。ノードから測定サイトへはローカルな相互接続を通って35 msでも、実際の接続先へは別地域を経由し、最初の1バイトが届くまで900 msかかることがあります。測定URLが示せるのはそのURLへの通信品質だけで、実際に使うサービスの確認の代わりにはなりません。

ローカル回線と端末の負荷

2.4 GHz Wi-Fiの干渉は再送を引き起こします。短時間のテストでは正常でも、大容量ファイルの転送では速度が継続的に変動することがあります。
TUNモードでは、ウイルス対策ソフト、システムファイアウォール、その他のネットワークフィルタリングソフトが処理時間を増やす場合があります。
性能の低いルーターで暗号化通信を処理するとCPU使用率が上限に達することがあります。遅延の数値が低くても、スループットは向上しません。
ブラウザー拡張機能、同時ダウンロード、システムのバックグラウンド更新はローカル帯域を消費し、体感速度に影響します。
MTUの設定が適切でないと、一部の接続でフラグメント化や再送が発生したり、特定サイトの読み込みが止まったりすることがあります。

高遅延のノードでも動画をスムーズに再生できる理由

動画再生では継続的なスループットとバッファーが重要で、すべてのデータ片が数十ミリ秒以内に返る必要はありません。遅延180 msでも安定して25 MB/s出るノードなら、遅延45 msで速度が2 MB/sしかないノードより、バッファーを速く満たせることが多いでしょう。再生開始後、ダウンロード速度が長時間動画のビットレートを上回っていれば、高い遅延が連続再生に与える影響は限定的です。

4K動画を例にすると、平均ビットレートが25 Mbpsなら約3.125 MB/sです。ノードが安定して12 MB/sを提供できれば、遅延が220 msあっても再生を維持する十分な余裕があります。一方、遅延30 msでも、混雑時間帯に1.5～4 MB/sの間で速度が変動するノードは、バッファーを頻繁に使い切る可能性があります。

インタラクティブ操作と大容量通信では重視する指標が異なる

利用シーン	より重要な指標	よくある結果
Webページ、オンラインドキュメントを開く	遅延、最初の1バイトまでの時間、パケットロス	低遅延なら複数の小さなリクエストを通常より速く完了できる
動画再生	継続スループット、ジッター、利用可能帯域	遅延がやや高くてもバッファーで滑らかに再生できる
大容量ファイルのダウンロード	継続速度、出口速度制限、回線の安定性	開始直後数秒のピークは平均速度を示さない
リモートターミナル、クラウドデスクトップ	往復遅延、ジッター、パケットロス	80 msと250 msでは操作への反応に明確な差が出る
音声通話とリアルタイム通信	遅延、ジッター、UDPの利用可否	帯域が十分でもジッターによって音声や映像が途切れることがある

測定URLは結果をどのように変えるか

測定先の位置、プロトコル、レスポンス状態はいずれも数値に影響します。HTTPSのURLを選ぶと、通常はTLS接続の確立も測定に含まれます。HTTPのURLならTLSの分だけ処理が少なくなります。測定サイトがノードの出口に近ければ結果は低くなり、サイトが大陸をまたぐか応答処理で混雑していれば高くなります。測定サイトが接続元ネットワークによって制限されている場合、ノードが正常でもタイムアウトと表示されることがあります。

測定URLを選ぶ3つの基準

レスポンスが安定している：連続アクセスでステータスコードが一定で、リダイレクト、CAPTCHA、動的ページを避けられること。
レスポンスが小さい：204または小さな静的ファイルを使い、ヘルスチェックで通信量を消費し続けないこと。
実際の用途に合っている：特定地域のサービスを主に利用するなら、測定サイトもその地域への出口品質を代表できること。

異なるURLで得たミリ秒数をそのまま並べ替えてはいけません。たとえばノードAはアジアの測定サイトへ48 ms、ノードBは欧州の測定サイトへ130 msでも、この2つのデータは公平に比較できません。複数ノードを測定するときは、同じURL、同じタイムアウト時間、近い測定時刻をそろえる必要があります。

url-testとヘルスチェックの設定方法

Clashとmihomoの設定にある url-test ポリシーグループは、候補ノードを定期的に測定し、その時点で遅延の低いノードを選びます。自動選択には適していますが、継続的なダウンロード速度を測る機能ではありません。interval はチェック間隔を制御し、通常は秒単位です。tolerance は遅延が近いときの頻繁な切り替えを抑えます。

proxy-groups:
  - name: 自動選択
    type: url-test
    use:
      - 空港サブスクリプション
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

この設定では300秒ごとにチェックします。「自動選択」グループは、新しいノードが10 ms速いだけで直ちに切り替わりません。tolerance: 80 を設定すると、差が小さい場合は現在のノードを優先し、接続の中断を減らせます。Web閲覧では、ミリ秒単位で追いかけるより50～100 ms程度の許容差のほうが実用的です。リアルタイム会議中も、間隔を10秒にすることはおすすめしません。頻繁な測定と切り替えが不要な接続変化を増やすためです。

プロキシプロバイダーごとにヘルスチェックを設定することもできます。次の断片は、サブスクリプション内のノードに到達できるかを600秒ごとに確認します。

proxy-providers:
  空港サブスクリプション:
    type: http
    path: ./providers/airport.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

lazy: true は、関連するプロキシプロバイダーが使われていないときに能動的なチェックを減らす設定です。具体的な動作は使用するコアのバージョンによって異なります。クライアントがGUIで設定を管理している場合、実行時に生成されたYAMLを直接編集すると、サブスクリプション更新後に上書きされる可能性があります。まずはクライアントのオーバーライドまたはマージ設定機能でルールを追加してください。たとえばClash Verge Rev 2.xでは、「設定」→「サブスクリプション設定」→設定を選択→「グローバル拡張設定を編集」という手順が一般的です。完了後にサブスクリプションを再読み込みし、実行中の設定を確認します。

実際の使用感に近い測定方法

ノードを選ぶときは、稲妻ボタンを1回押すだけでなく、測定を「応答速度」「継続スループット」「安定性」の3つに分けます。比較する際は端末、ネットワーク、時間帯、プロキシモードをすべて固定してください。Wi-Fiと有線を混在させたり、システムプロキシとTUNモードを混在させたりすると、結論の比較性が失われます。

ステップ1：遅延を繰り返し測り、中央値を見る

Clash Verge Rev 2.xで「プロキシ」→対象のポリシーグループを開きます。
ポリシーグループ右上の測定ボタンをクリックし、グループ内の全ノードが完了するまで待ちます。
候補ノードを5～10回繰り返し測定し、各回の間隔を約10秒空けます。
最低値だけでなく、中央値、最大値、タイムアウト回数を記録します。

結果が68、71、69、74、70 msのグループは中央値70 msで、変動も小さい状態です。もう一方が42、45、310、タイムアウト、53 msなら、最低値は優れていても安定性に欠けます。Web閲覧やリモート操作には通常、前者のほうが適しています。

ステップ2：瞬間的なピークではなく継続ダウンロードを測る

配信元が安定し、用途に近い場所にある100～500 MBのテストファイルを選び、少なくとも30秒間連続してダウンロードします。開始直後2～3秒のピークは無視し、10秒、20秒、30秒時点の速度を記録します。たとえばノードAは遅延46 msで、読み取り値が8.2、7.9、7.8 MB/s。ノードBは遅延128 msでも30.5、31.4、30.8 MB/sです。ダウンロード用途なら明らかにノードBを選ぶべきでしょう。

測定では実際の通信量が発生します。モバイル回線や従量制回線ではファイルサイズを小さくし、ほかのダウンロードを停止してください。ブラウザーの開発者ツールにある「ネットワーク」パネルでリクエストの所要時間を確認できます。Chromium系ブラウザーでは F12 を押して「ネットワーク」を開き、対象リクエストを選択し、「タイミング」で「サーバー応答の待機」と「コンテンツのダウンロード」の各段階を確認します。

ステップ3：実際のサービスを確認する

Web利用：よく使うページを5つ連続して開き、ファーストビューがすぐ表示されるか確認します。
動画利用：同じ画質に固定し、再生開始までの時間と10分間のバッファリング回数を記録します。
ダウンロード：同じファイル配信元を使い、30秒間の平均速度を記録します。
リモート接続：3～5分間連続して操作し、キーボード入力への反応と画面の引っかかりを確認します。
TUNモード：有効化の前後でそれぞれ測定し、問題がシステムプロキシの適用範囲に由来するか確認します。

遅延に異常があるときは各段階を確認する

すべてのノードが同時に高くなった

まずローカルネットワークを確認します。実行中のクラウドストレージ同期やシステム更新を停止し、有線接続または5 GHz Wi-Fiで再測定してください。プロキシを使わずにWebページを開いても明らかに遅いなら、問題はローカルの固定回線、モバイル回線、またはルーターにある可能性が高いでしょう。Clashを再起動してもプロキシ接続を再構築できるだけで、通信事業者側の回線混雑は解消できません。

特定の地域だけ高くなった

同じ地域の複数ノードが約80 msから300 msへ同時に上昇した場合、国際経路の変更や地域側の入口混雑が考えられます。一時的に別の地域を選び、日中と混雑時間帯に分けて測定してください。深夜に回復し、夜間に繰り返し上昇するなら、クライアント設定の誤りよりも混雑の特徴に当てはまります。

測定はタイムアウトするのにWebページは開ける

測定URLを変更して再測定し、DNSモードが正常か確認します。Fake-IPを使用すると、測定ドメインはまず予約アドレスを取得し、接続時にClashがドメイン名へ戻します。ルールによって測定ドメインが誤って直接接続または拒否ポリシーに振り分けられていると、テストに失敗することがあります。ログで対象ドメイン、適用ルール、出力ノードを確認すれば、リクエストが本当に測定対象のプロキシを経由しているか判断できます。

遅延は正常なのに一部のWebサイトだけ遅い

ログで、そのWebサイトが想定したポリシーグループに振り分けられているか確認します。Clashのルールは上から順に照合され、最初に一致した時点で停止します。対象サイトが、より上位の DOMAIN-SUFFIX、GEOSITE、または IP-CIDR ルールによって別のノードへ振り分けられていると、ポリシーグループに表示された低遅延は実際の接続とは関係ありません。ブラウザーで独自のプロキシ、HTTP/3、セキュアDNSが有効になっていないかも確認し、想定と異なる通信経路を避けてください。

ノードの並べ替えでは4つの数値を同時に見る

単一のミリ秒数は利用できないノードをすばやく除外するには便利ですが、すべての用途を決めるには不十分です。より確実な記録項目は、遅延中央値、最大ジッター、タイムアウト率、継続ダウンロード速度です。たとえばノードAが72 ms、ジッター12 ms、タイムアウト率0%、平均14 MB/s、ノードBが41 ms、ジッター280 ms、タイムアウト率20%、平均6 MB/sだったとします。ノードBの最低遅延のほうが小さくても、通常はノードAをデフォルトにするほうが適しています。

自動ポリシーグループにも一定の許容差を設けるべきです。2つのノードがそれぞれ64 msと71 msなら、7 msの差では既存接続を切り替えるコストを補えないことが多いでしょう。遅延差が長時間安定している、またはスループットや対象サイトでの体感も優れている場合にのみ、切り替える実益があります。測定結果は候補を絞る入口として使い、最後は実際のタスクで確認しましょう。1回の測定結果だけで並べ替えるより、信頼性の高いノード選びができます。