Clashの遅延テストの仕組み：パネルのミリ秒表示が実際の速度と一致しない理由

Clashパネルを開くと、ノード一覧の右側に並ぶ数字は、多くの人がノードを選ぶ唯一の基準になっています——数字が小さいほど良い、まるで遅延こそが速度の代名詞であるかのように。しかし気づいた人もいるかもしれませんが、直感に反する現象があります。あるノードは遅延がわずか40ミリ秒で、驚くほど速そうに見えるのに、動画サイトを開くとバッファリングが延々と続く。別のノードは遅延300ミリ秒で、遅そうに見えるのに、実際にページを開くと快適に動く。これはパネルの不具合ではなく、遅延テストが測っているものと、日常的なネット体験との間に、いくつかの説明されにくい違いがあるからです。

遅延テストが実際に測っているもの

Clash（Clash Meta / mihomoコアをベースとする各種クライアントを含む）が遅延テストを行う際、実際にアクセスしたいサイトにリクエストを送るわけではなく、設定内で指定された固定のテスト用URLにリクエストを送信し、送信から応答を受け取るまでの時間差を記録します。この時間差がパネルに表示されるミリ秒数です。デフォルトでは、このURLは通常http://www.gstatic.com/generate_204のようなアドレスで、これはGoogleが提供する接続確認専用のインターフェースで、応答が非常に速く、コンテンツも極小で帯域幅をほとんど消費しないという特徴があります。

テスト経路全体はおおよそ次のように進みます：端末 → ローカルのClashコア → 選択したプロキシノード（1回または複数回の中継を経由）→ 着地サーバー → テスト用URLのサーバー → 元の経路で返送。この経路上のどこかが遅くなれば、最終的な数字は大きくなります。ただ注意すべきは、この経路には「実際にアクセスしたいそのサイト」がまったく含まれていないということです。テスト用URLと、実際に開く動画サイト、SNS、業務システムとでは、物理的な位置、ネットワーク構成、CDN配置がまったく異なる場合があります。遅延の数字が反映しているのは、ノードからテスト用サーバーまでの特定の経路における接続応答速度であり、ノードから任意の対象サイトまでの速度と同じではありません。

なぜHEADリクエストを使うのか、完全なダウンロードではなく

気づいた人もいるかもしれませんが、ノードの回線自体がそれほど速くなくても、遅延テストはほぼ瞬時に完了します。これは多くの実装がHTTPのHEADリクエスト（または204 No Contentを返すような極小コンテンツのGETリクエスト）を使っているためで、サーバーはレスポンスヘッダーを返すだけで完了し、本文データの転送を伴いません。このやり方の利点は明確です：測定自体がほとんど通信量を消費せず、数十KBのコンテンツをダウンロードすることによる帯域幅の影響も受けないため、「接続確立」という段階の速さをより純粋に反映できます。

しかしこれこそが限界でもあります。HEADリクエストが測るのは接続段階——TCPの3ウェイハンドシェイク、TLSのネゴシエーション、リクエスト送信からレスポンスヘッダー返却までで、転送されるデータ量は無視できるほど小さいものです。一方、実際にWebページを開いたり、動画を読み込んだり、ファイルをダウンロードしたりする際に試されるのは、大量のデータを継続的に転送し続ける際の安定した性能です：帯域幅が十分か、転送中にパケットロスが発生するか、パケットロス後の再送コストがどれだけかかるか、複数の同時接続が互いにリソースを奪い合わないか。これらの要素は、一度の微小なHEADリクエストでは一切現れません。ノードが「接続は速いのに、大きなファイルの転送が始まると失速する」ことは十分にあり得ます。

接続が速いことと転送が安定していることは別物

例えるなら、遅延テストは友人に電話をかけたときに相手が出るまでの速さを測っているようなものです。すぐに出れば信号が良好で回線が混んでいないことを示しますが、通話の質が良いか、途中で切れないか、音量が急に変わらないかは別の話で、通話を最後まで続けてみないと判断できません。ノードの遅延が低いということは、この経路の「接続」段階が順調であることを意味しますが、その後大量のデータが流れ込んできたときに順調さが続くかどうかは、遅延の数字だけでは分かりません。

低遅延ノードでもカクつくのはなぜか

上記の原理を踏まえると、カクつきの一般的な原因は、遅延テストがまったくカバーできない次のようないくつかの側面にあります：

• 帯域幅の上限不足。ノードサーバー自体の出口帯域幅が限られている、あるいは同時間帯の他ユーザーに占有されている場合、接続自体は速いままでも、動画のビットストリームのような継続的な大容量転送が始まると速度が追いつかず、バッファリングを繰り返す形で表れます。
• ジッターとパケットロス。遅延の数字は通常1回、あるいは短時間の数回の測定の平均値であり、ネットワーク品質の変動を隠してしまいます。この回線が速かったり遅かったりを繰り返し、時々パケットロスが発生する場合、動画再生のような継続的で安定したスループットが必要な場面ではカクつきが明確に感じられますが、1回の遅延テストがたまたまネットワーク状態の良い瞬間に当たれば、きれいな数字が表示されてしまいます。
• 対象サイトのCDN配置の違い。テスト用URLのサーバーと、実際にアクセスする動画サイトやダウンロードサイトは、まったく異なるデータセンター、あるいは異なる大陸に配置されている場合があります。ノードからテスト用サーバーまでの経路は短くても、対象サイトまでの実際の経路はより遠回りになり、途中で経由する通信事業者のノードや国際回線の混雑度も異なります。
• 着地地域とコンテンツ配信戦略。多くの動画プラットフォームはアクセス元の地理的位置に応じて異なる配信ノードや速度制限を割り当てます。ノードの着地地域がたまたまそのプラットフォームの速度制限地域や混雑ピーク地域に当たっていれば、テスト用URLへの接続自体は速くても、実際に動画ストリームを取得する際には制限を受けます。
• 同時接続数の影響。Webページの読み込みや動画再生では、しばしば複数の接続が同時に確立されます。プロキシノードや着地回線の同時接続処理能力に限りがある場合、複数の接続が互いにリソースを奪い合い、実際の体感は単発の遅延テストが示す結果よりも悪くなります。

より実体験に近い判断方法

遅延の数字はあくまで参考の一部分でしかないため、日常的にノードを選ぶ際にはミリ秒数だけを見て決めるのを避け、より直接的な判断方法をいくつか組み合わせるとよいでしょう。

1. スループットも合わせて確認する。多くのクライアントには遅延テストに加えて「速度測定」ボタンがあり、実際にデータをダウンロードして帯域幅を計算します。この数字は単純な遅延よりも継続的な転送能力をよく反映しているため、両方を合わせて参考にするのが理想です。
2. 実際のシーンで短時間試用する。よくアクセスする少数の重要なサイトやサービスについては、遅延の数字にこだわるより、ノードを切り替えて数十秒開いてみる方が確実です。動画がスムーズに再生されるか、ページの読み込みが快適かは、どんな測定数字よりも実際の答えに近いものです。
3. 単発の数値ではなく、複数回測って参考範囲を見る。あるノードの遅延が測定ごとに大きく変動する場合（例えば1回目は60ミリ秒、別の回は400ミリ秒）、その回線自体が不安定であることを示しており、絶対値よりも安定性のリスクに注意すべきです。
4. ルールのヒット先と着地地域が用途に合っているか確認する。遅延が低くても、着地地域が実際にアクセスしたいサービスに適していなければ速度は上がりません。逆に、ルール設定で異なる種類のトラフィックを異なるノードに振り分けられれば、それぞれに適した経路を走らせることができ、「全体で最も低遅延」の単一ノードにこだわるより実用的な場合が多いです。プロキシモードの選び方を参考に、ルール・グローバル・直接接続をそれぞれ適切に使い分けるとよいでしょう。

テスト用URL自体にも注意を払う価値がある

設定内でテスト用URLを自分でカスタマイズしている場合は、応答が安定していて、地理的にある程度の代表性を持つアドレスを選ぶようにしましょう。それ自体が不安定だったり、実際にアクセスしたい地域から離れすぎているインターフェースを使うと、測定される数字の参考価値がさらに下がってしまいます。多くのクライアントやサブスクリプション設定でデフォルトで使われている接続確認インターフェースは、すでに広く検証されているため、通常は追加で変更する必要はありません。自分のネットワーク環境からデフォルトのアドレスへのアクセス自体が不安定な場合にのみ、他の公開されている軽量な確認インターフェースへの変更を検討してください。

まとめ

パネルに表示されるミリ秒数は、本質的にはノードから固定のテスト用アドレスまでの接続応答時間であり、接続確立段階の順調さを反映しているだけで、大量のデータを継続的に転送する際の実際のスループットを表すものではなく、特定のサイトを開いたときの実際の体感とはさらに別物です。この違いを理解すれば、遅延の順位付けを見るときに1桁のミリ秒差にこだわる必要がなくなり、帯域幅が十分か、回線が安定しているか、着地地域が自分の用途に合っているかにより注目できるようになります——これらこそが「速いか遅いか、カクつくかどうか」を本当に決める要因です。