Clashの遅延テストの仕組み

遅延の数値が示すのは1回のリクエスト

Clashクライアントの「遅延テスト」ボタンは通常、指定したURLへプロキシ経由でアクセスするのにかかる時間を測定します。大きなファイルをダウンロードして帯域幅を計算する機能ではありません。画面に表示される80 msや160 msは、テスト経路での所要時間です。1秒あたりに何MBダウンロードできるかを直接示すものでも、すべてのWebサイトの応答時間を表すものでもありません。

クライアントによっては、TCP接続テスト、HTTP遅延テスト、ダウンロード速度テストが別々に用意されています。この記事では、設定のurl-testと、HTTPリクエストを使ったノードの遅延テストを扱います。計測する範囲や接続の再利用方法はクライアントやコアのバージョンによって異なる場合があるため、比較の前にテストの種類をそろえてください。

url-testのリクエストで発生する処理

一般的なHTTPSテストURLであるhttps://www.gstatic.com/generate_204を例にすると、コアはテスト対象のプロキシ経由でHTTPリクエストを送信します。このURLは通常、本文のないHTTP 204を返すため、軽量な疎通確認や応答時間の測定に適しています。帯域幅を測るためのファイルではなく、どのネットワーク環境でも必ず使えるとは限りません。

1. 接続先の準備。クライアントはプロキシサーバーのアドレスを把握する必要があります。サーバーがドメイン名で指定されている場合、接続前にDNS名前解決が行われることがあります。テスト先のドメインをローカルとリモートのどちらで解決するかは、プロキシのプロトコルとコアのDNS設定によって異なります。
2. プロキシの入口へ接続。ローカルネットワークからプロキシサーバーまでの通信経路を確立します。TCPベースのプロトコルではTCPハンドシェイクが発生し、プロトコルによってはTLSハンドシェイクや認証も必要です。別のトランスポートを使うプロトコルに、同じ手順をそのまま当てはめることはできません。
3. テスト先への通信経路を確立。プロキシの出口からテストサイトへ接続します。入口が近くても、出口からテスト先まで近いとは限りません。地域をまたぐ迂回や出口の混雑によって待ち時間が増えることもあります。
4. リクエストを送信して応答を待つ。コアが定める計測範囲内でテストを実行し、所要時間をクライアントに表示します。証明書の検証エラー、接続のリセット、タイムアウトなどが発生すると、有効なミリ秒値ではなく失敗として扱われることがあります。

そのため、HTTP遅延は単純な「端末からサーバーまでのping」ではなく、すべてのハンドシェイク時間を足した固定値でもありません。DNSキャッシュ、TLSセッション再開、下位層の接続再利用、コアの実装などが測定結果に影響します。初回が230 msで次に120 msになっても、それだけで回線の帯域幅が向上したとはいえません。

pingの数値が低くなる理由

コマンドラインのpingは通常、ICMPエコー要求を送り、指定したホストとの往復時間を測定します。前述のHTTPリクエストは実行せず、通常はシステムのHTTPプロキシも経由しません。サーバーがICMPを制限していても、プロキシサービスは正常に動作する場合があります。そのため、pingに応答がないからといってノードが使えないとは限らず、pingが低くてもHTTPSのページが速く開くとは限りません。

テスト先によって比較対象が変わる

ノードテストではテスト用URLにアクセスしますが、ブラウザーでは動画サイトやコードリポジトリ、会議サーバーなどを利用することがあります。接続先ごとにCDNの配置、オリジンサーバーの場所、通信事業者間の接続状況は異なります。テストサイトまで60 msで接続できる回線でも、業務で使うサイトには迂回が必要なことがあります。一方、テスト値が110 msの回線のほうが、実際の用途に適した経路を通る場合もあります。

• ノードを比較するなら、同じURLを使います。ノードAとノードBで異なるサイトをテスト先にすると、公平に数値を比較できません。
• テスト先の異常は切り分けて確認します。テストドメインの名前解決失敗、証明書の有効期間エラー、サーバー側のレート制限などにより、複数のノードが同時にタイムアウトすることがあります。その場合は、まず安定して応答する小さなHTTPS URLに変更して再テストしてください。
• ステータスコードは設定と合わせて確認します。コアやクライアントによっては、期待する応答ステータスを設定できます。リダイレクトや認証画面、想定外のステータスが返った場合、「応答があった」ことと「テストに成功した」ことが同じとは限りません。
• 実際の用途での確認も欠かせません。候補のノードを選んだら、実際に使うサイトを開き、ログイン、画像、動画の再生、長時間接続などを確認してください。クライアントの一覧だけで判断しないようにしましょう。

遅延が低くてもダウンロードが遅い理由

軽量なリクエストでは、接続確立や応答待ちにかかる時間が主に表れます。一方、継続的なダウンロードでは、利用可能な帯域幅、輻輳制御、回線のパケットロス、サーバーの配信能力がより重要です。小さな応答はすぐ返ってきても、同じ回線で500 MBを転送すると、出口の速度制限にすぐ達することがあります。

例で見る遅延とスループットの違い

ノードAのHTTP遅延が65 ms、継続ダウンロード速度が2 MB/sで、ノードBのHTTP遅延が140 ms、継続ダウンロード速度が15 MB/sだとします。これは指標の違いを説明する例であり、実回線の測定順位ではありません。短いWebリクエストならAのほうが早く応答を始める可能性があります。大きなファイルや高ビットレートの動画には、Bのほうが十分なスループットを提供できるでしょう。ただしサイト側に速度制限があれば、どちらも配信元の制約を受ける場合があります。

「遅延が低いから必ず速い」という考え方では、転送量の違いが見落とされます。「ダウンロードが速いから会議にも向いている」と判断すると、安定性や上り帯域、リアルタイム通信の経路を考慮できません。用途を決めてから適切な指標を選び、すべての結果を一つのランキングにまとめないようにしましょう。

ジッターとパケットロスが使用感に与える影響

最小遅延だけでは、ばらつきを見落としがちです。たとえば5回の測定結果が78、82、80、460、85 msなら、途中の460 msは注意すべき値です。Wi-Fiの混雑、キューイング、再送、テストサイトの一時的な遅延などが原因として考えられますが、HTTPリクエスト5回の結果だけで物理的なネットワークのパケットロス率を断定することはできません。

確実なデータ転送が必要な通信では、データの欠落による再送や輻輳ウィンドウへの影響で、長時間のダウンロードが大幅に遅くなることがあります。リアルタイムの音声・映像では、音声の途切れ、映像のフリーズ、バッファリングの増加として表れる場合があります。アプリごとに再送やバッファリングの処理は異なるため、同じノードでもバッファ付きの動画再生には向き、リアルタイム会議には向かないことがあります。

• テストを5～10回連続で行い、中央値、最大値、失敗回数を確認しましょう。最小値だけを記録するのは避けてください。
• HTTPテストを10回行って2回失敗した場合は、「今回のテストでリクエストが2/10回失敗」と記録しましょう。「回線のパケットロス率が20%」とは書かないでください。
• ネットワークが空いている時間帯と、夜間の通常利用時間帯にそれぞれテストします。夜だけ悪化する場合は、ローカル回線とプロキシの出口の負荷を比較してください。
• テスト中はクラウドストレージの同期、大容量ファイルのダウンロード、ほかの速度テストを一時停止し、自分の通信による混雑を避けましょう。

url-testの自動選択は帯域幅の優先選択ではない

ClashやClash Meta（現在はmihomoと呼ばれることが多い）の設定では、url-testプロキシグループは指定したURLへの遅延テスト結果をもとにメンバーを選びます。名前に「テスト」が含まれていても、大容量ファイルを自動でダウンロードして帯域幅を比較するわけではありません。特定の回線を手動で固定したい場合は手動選択グループを使います。自動テストグループを使う場合は、主に遅延を基準に選択されることを理解しておきましょう。

以下はプロキシグループの設定例です。現在の設定に「香港 A」と「日本 B」というプロキシがすでにあるものとします。実際に使うときは、メンバー名を既存の設定にある正確な名前に置き換え、既存のproxy-groupsリストに追加してください。設定ファイル全体をこの例で置き換えないでください。

proxy-groups:
  - name: 遅延優先
    type: url-test
    proxies:
      - 香港 A
      - 日本 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300は、テスト間隔が300秒に設定されていることを示します。実際の実行タイミングはコアの遅延テストなどの仕組みに左右されることがあるため、常に正確な間隔で実行されるタイマーとは限りません。
• tolerance: 50はミリ秒単位で自動選択の切り替え許容幅を設定し、数ミリ秒の差による頻繁な切り替えを抑えます。具体的な動作は使用するコアのバージョンによって異なります。
• グループを設定しただけでは不十分です。実際の通信で選択結果を使うには、ルールからそのグループを参照するか、上位の手動選択グループで対象グループを選ぶ必要があります。

自動選択グループでメンバーが再選択されても、確立済みの接続がすべてすぐに移行するとは限りません。既存の接続は以前の出口を使い続け、新しい接続から切り替わる場合があります。原因を調べるときは、グループ名の横にある現在のノードだけでなく、クライアントの「接続」画面で対象ドメイン、適用ルール、プロキシチェーンを確認してください。

条件をそろえて実際の速度を確認する

多くのクライアントでは、「プロキシ」画面でノードを選んで遅延テストを実行し、「接続」や「ログ」画面でリクエストの経路を確認できます。ただし、画面名やメニュー構成はクライアントによって異なります。また、システムプロキシモードとTUNモードでは通信をプロキシに通す範囲が異なるため、比較時はモードをそろえてください。

1. まずネットワーク環境をそろえます。同じ端末、同じ回線、同じWi-Fi周波数帯でテストしてください。可能なら有線でも再確認します。スマートフォンのモバイル回線とPCのWi-Fiの結果をそのまま比較しないでください。
2. 実際の通信がプロキシを経由しているか確認します。「接続」画面でテストサイトを探し、出口がDIRECTではないことと、実際に使われているノードを確認してください。コア内蔵の遅延テストは通常、テスト対象のプロキシを指定して実行されます。テストに成功しても、ブラウザーの通信が正しくプロキシに流れているとは限りません。
3. 軽量なリクエストを記録します。同じURLで5～10回続けてテストし、一般的な所要時間、目立つピーク、失敗回数を記録してください。大量のノードを一度に連続してテストするのは避けましょう。
4. 次に継続的なスループットを測定します。十分な帯域幅がある配信元を一つ選び、約30秒間ダウンロードして安定時の速度を確認してください。比較時はファイル、配信元、同時接続数をそろえ、契約プランのデータ通信量にも注意しましょう。
5. 最後に実際の用途で確認します。動画ではバッファリングと再生の安定性、会議では上り速度と音声の途切れ、コードリポジトリではページ表示とファイルのダウンロードをそれぞれ確認してください。1回の検証で変更する条件は一つだけにします。

ノードを選ぶときは、まず遅延テストで現在接続できない候補や明らかに異常な候補を除き、その後で遅延のばらつき、継続的なスループット、実際のアプリでの動作を確認します。Web閲覧では応答時間、大容量ファイルの転送では帯域幅、リアルタイム通信では安定性と上り速度も重要です。指標を分けて記録すれば、クライアントの数値が良好でも実際の使用感が改善しない理由を把握できます。