Clash ノード遅延テストの仕組み:パネルの数値と実際の速度が合わない理由

パネルの遅延数値は何を測っているのか

Clash のコントロールパネルを開くと、各ノードの横にミリ秒の数値が表示されます。緑は速い、赤はタイムアウトという表示です。多くの人はこの数値をそのまま「このノードがどれだけ速いか」の答えとして受け取り、遅延が最も低いノードを選んで使いますが、実際にはページの表示がカクついたり、ダウンロード速度が上がらなかったりします。問題はこの数値の解釈にあります――これは通信速度ではなく、1回のネットワークリクエストの往復にかかった時間を測っているだけで、そのリクエストの宛先や方式はクライアント側で事前に固定されており、これから実際にアクセスしたいサイトとは全く別物である可能性があります。

このしくみは Clash と Clash Meta(mihomo)でどちらも URL テスト(URL Test)と呼ばれています。原理は単純で、クライアントが特定のノードを経由して固定アドレスへ HTTP リクエストを送り、送信から応答受信までの時間を記録します。この時間がそのまま表示される遅延値です。過程全体で1回のリクエストしか発生せず、大きなファイルのダウンロードもスループットの計測も行いません。つまりこの数値が反映しているのは「接続できるかどうか、経路の応答速度」であり、「このノードでどれだけ速くダウンロードできるか」ではありません。

設定ファイルでは通常このように記述されます。

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

url はテスト先のアドレス、interval は自動再テストの間隔(秒)、tolerance は許容差です――新しい遅延が現在のノードよりこの数値以上低くならない限り、実際の切り替えは行われません。これは数ミリ秒の揺れで頻繁にノードが切り替わるのを防ぐためです。この数個のフィールドが、パネル上の数値の振る舞いをほぼ決定しています。

ハンドシェイク方式がこの数値に与える影響

遅延テストにかかる時間は「ネットワーク伝送」だけではなく、プロトロコル自体が接続を確立するためのオーバーヘッドも含まれます。プロトコルごとに使用可能な接続を確立するまでの手順数が異なり、この差がそのまま遅延数値に反映されます。

• TCP スリーウェイハンドシェイク:TCP ベースのプロトコルはすべてこのステップを最初に完了させる必要があり、通常は往復の物理遅延(RTT)にほぼ近い時間がかかります。
• TLS ハンドシェイク:TLS 暗号化を使うプロトコル(Trojan、一部の VMess/VLESS 設定など)は TCP の後に鍵交換を行う必要があり、通常さらに 1〜2 RTT ほど余分にかかります。初回接続時は特に顕著です。
• プロトコル固有の認証・ネゴシエーション:例えば Shadowsocks の暗号方式ネゴシエーション、VMess のタイムスタンプ検証など、いずれも一定の固定オーバーヘッドが加算されます。

つまり同じサーバー、同じ物理回線であっても、異なるプロトコルでノードを構築すれば計測される遅延数値に差が出ます――この差はプロトコルのオーバーヘッドによるものであり、回線自体が悪化したわけではありません。逆に、遅延数値が近い2つのノードでも、ハンドシェイクの複雑さが異なれば、実際にページを開いたときに「感じる」応答速度が一致しないこともあります。ウェブ閲覧では複数の接続を新規に張ることが多く、プロトコルのハンドシェイクオーバーヘッドが繰り返し積み重なるためです。

テスト先アドレスと結果キャッシュの落とし穴

パネルの数値はリアルタイム更新ではなく、interval で設定した間隔ごとに周期的にテストが行われ、次のテストまでの結果はキャッシュされてそのまま表示されます。これはよくある誤解を生みます――表示されている「現在の遅延」は数分前に計測されたものかもしれず、その時点で回線状況はすでに変化していることがあります。特に夜間のピーク時間帯など変動の大きい回線ほどこの傾向が強くなります。

テスト先アドレスの選び方も結果の代表性に影響します。

• よく使われるテストアドレス(generate_204 のような軽量エンドポイント)自体が CDN による高速化を受けているため、地域によってはこのアドレスへの遅延と、本当にアクセスしたいサイトへの遅延が大きく異なる場合があります。
• 一部の出口ノードは特定のアドレスに対して専用に最適化されたルーティングを持っており、テストアドレスがちょうどその最適化パスに当たった場合、数値が異常に良く見えても、別のサイトに切り替えると元の実力が露呈します。
• ノードが属するネットワーク環境でテストアドレスがレート制限されていたり一時的に到達不能だったりすると、そのまま「タイムアウト」と表示されます。実際には他のサイトへのアクセスに何も問題がなくても、です。

言い換えると、遅延数値は「ある特定の対象への、ある特定の時点でのサンプリング」であり、そのノードの終日・全サイトにわたる平均的なパフォーマンスではありません。実際の場面に近い判断をしたいなら、この数値だけを見るのでは不十分です。

低遅延=高帯域ではない

最も見落とされがちな点です――遅延は「応答が速いかどうか」を測り、帯域は「どれだけのデータを送り込めるか」を測ります。両者は全く異なるネットワーク特性によって決まり、低遅延のノードでも帯域が非常に低いことは十分にあり得ますし、高遅延のノードでも帯域が十分な場合があります。

直感的な例え話をすると、遅延は電話に相手が出るまでの速さ、帯域はその電話線が同時にさばける通話の本数のようなものです。すぐ出てくれても通話品質が良いとは限らず、線自体の容量が小さければ人が多いときには途切れたり聞き取れなくなったりします。プロキシの場面に当てはめると、よくあるのは次のようなケースです。

• コントロールパネルの測定リクエスト向けに特別最適化されたノードは、ハンドシェイクの応答が極めて速い一方、出口サーバーの帯域が限られており、大きなファイルのダウンロードや動画視聴を始めた瞬間に速度が追いつかなくなります。
• 物理的な距離が遠いノードは(光速による物理的な下限のため)遅延数値が自然と高めになりますが、出口帯域が十分で回線が安定していれば、継続的なダウンロードの実速度はむしろ良好な場合があります。
• 遅延数値の揺れ幅(絶対値ではなく)のほうが回線の安定性を反映することが多いです――常時 80ms 前後で揺れているノードは、30ms と 300ms の間を跳ね回るノードよりも、たいてい体感が良好です。

実感に近いノード選びの方法

遅延数値だけでは十分ではないとわかったところで、実際のノード選びには以下の考え方を組み合わせると、より信頼できる判断ができます。

1. tolerance を適切な値に設定する

   許容差が小さすぎると数ミリ秒の揺れで頻繁にノードが切り替わり、むしろ体感を悪化させます。通常は 50ms 前後に設定すると、感度と安定性のバランスが取れます。

2. 実際の用途に近いテストアドレスに変更する

   主な用途が特定の種類のサイトに集中している場合は、url をそのサイトの静的リソースアドレスに変更することで、汎用的な測定エンドポイントよりも実際のアクセス場面に近い遅延数値が得られます。

3. 単発のスナップショットではなく、遅延数値の変動傾向を観察する

   パネルが数回更新された後の数値変化に注目しましょう。平均値が低くても時々急激に跳ね上がるノードより、常に安定しているノードの方が優れています。

4. 実際のダウンロードや再生テストで検証する

   遅延ランキング上位の2〜3個のノードを選び、それぞれ実際のダウンロードや動画再生テストを行い、体感速度で最終判断を下します。遅延数値はあくまで一次選別として使いましょう。

5. 「自動選択」と「手動固定」の2つの戦略を使い分ける

   軽い用途であれば url-test グループの自動選択に完全に任せて構いません。速度に敏感な場面(大容量ファイル転送など)では、帯域を確認済みのノードを手動で固定する方が安定する場合が多いです。

これらをまとめると、遅延テストの価値は明らかに使えない、あるいは応答が遅すぎるノードを素早く排除し、候補を数個まで絞り込むことにあります。日常の体感を実際に左右する帯域と安定性については、実際の使用場面に合わせた二次検証が別に必要です。このしくみを理解した上でパネルのミリ秒数を見れば、それを唯一の判断材料にすることはなくなるはずです。