Clashの遅延テスト結果の見方｜url-testの仕組みと実際の通信速度

遅延の数値は1回の応答時間。ダウンロード速度ではない

クライアントに表示される80 msや230 msは、通常、コアが指定したノード経由でテスト先にHTTPまたはHTTPSリクエストを送り、応答を受け取るまでの時間です。測っているのは「リクエストがテスト条件を満たす応答を得るまでの時間」であり、「回線が1秒間にどれだけデータを転送できるか」ではありません。ボタンに「速度テスト」と表示されていても、大容量ファイルをダウンロードするとは限りません。

まず、3つの指標を区別しましょう。遅延は1回の通信で応答を待つ時間、スループットは継続的なデータ転送能力、安定性はリクエストごとのばらつきや失敗の有無を示します。遅延が小さいと短いリクエストには有利ですが、動画の読み込み、大容量ファイルのダウンロード、長時間接続の品質まで保証するものではありません。

url-testの仕組み：候補ノード経由でテスト先にアクセス

url-testはプロキシグループの種類の1つです。コアはグループ内の候補となるアウトバウンドをURLでテストし、到達性や遅延、切り替えの許容差に基づいて接続先を選びます。クライアントの手動遅延テストと、プロキシグループの定期テストでは、使うURLやタイムアウト、実行方法が異なる場合があります。画面上の数値だけで自動選択の異常を判断することはできません。

テスト経路に含まれる処理

1. 名前解決と接続の準備：ノードサーバーのドメイン名を名前解決します。接続先ドメインをローカルとリモートのどちらで解決するかは、プロトコルやDNS設定、実装によって異なります。
2. プロキシ経路の確立：ノードに接続し、プロトコルに必要なハンドシェイクを行ってから、ノード経由でテスト先にアクセスします。中継がある場合は、その経路も通ります。
3. テストリソースへのリクエスト：HTTPSの場合は通常、TLSハンドシェイクも行い、その後HTTPリクエストを送って応答を待ちます。
4. 結果の記録：テストに成功すると所要時間が記録されます。接続失敗やタイムアウト、応答がテスト条件を満たさない場合は、失敗、利用不可、タイムアウトなどと表示されることがあります。

ここで説明したのはリクエストが通る処理であり、すべてのコアが各処理を同じ数値にすべて含めているとは限りません。DNSキャッシュや接続の再利用、プロトコルの実装、計測の開始・終了位置によって結果は変わります。そのため、Clash、Clash Meta（mihomo）、各クライアントの画面に表示される数値を比較する場合は、同じ条件でテストしてください。異なる条件の数値をそのまま並べて比較するのは避けましょう。

このテストは従来のICMP pingとも異なります。サーバーでICMPが無効になっていても、HTTPテストが成功しないとは限りません。また、サーバーにpingが通っても、プロキシ認証やプロトコルのハンドシェイク、接続先サイトへのアクセスが正常とは限りません。

テスト結果は実際の通信ルールを反映するとは限らない

プロキシグループのテストでは候補のアウトバウンドごとにリクエストを送り、テストURLを通常の閲覧リクエストとして設定全体のrulesに通したうえでノードを選ぶわけではありません。一方、ブラウザーの実際の接続先は、動作モードやルールの適用結果、プロキシグループの選択に左右されます。ノードAをテストしていても、Webページへの接続が最終的にDIRECTや別のグループに振り分けられれば、体感が異なるのは当然です。

遅延が小さいのに通信が遅い：経路の違い4つ

短い応答は速くても、継続転送は遅い

よく使われるgenerate_204のURLは応答が小さく、軽量な接続確認に適しています。一方、継続的なデータ転送能力はほとんど分かりません。ノードの帯域が混雑している、単一接続に速度制限がある、出口の負荷が高いといった場合、短いリクエストにはすぐ応答しても、大容量ファイルはなかなか転送できないことがあります。

たとえば、指標の違いを説明するための次の仮の記録を考えてみましょう。実測値ではありません。ノードAは応答時間が65 ms、ダウンロード速度が1.2 MB/s、ノードBは応答時間が140 ms、ダウンロード速度が8 MB/sです。短いリクエストへの応答はAのほうが速くても、同じファイルのダウンロードはBのほうが早く終わる可能性があります。

テスト先は近くても、利用するサイトは遠い

テストURLはCDNで配信されていることがよくあります。出口の地域によって接続先のデータセンターが異なる場合があり、良好なテスト結果が示すのは、そのテスト先までの経路の状態だけです。別の地域にあるコードリポジトリや動画サービス、社内システムにアクセスすると、出口以降のルーティングや相互接続の品質、サーバー負荷が変わることがあります。

一度は低遅延でも、連続リクエストが不安定

同じノードで70、75、620、タイムアウト、82 msと続いた場合、最後の82 msだけを見ると、大きなばらつきを見落とします。パケット損失による再送は、特にTLS接続の確立、Webページの複数リソースの読み込み、長時間のデータ転送に影響します。ここでいう「タイムアウト」はアプリケーション層のテスト失敗であり、ICMPのパケット損失率と同じではありません。

実際の通信ではUDPなど別の接続方式を使う

HTTPテストが成功しても、UDP転送が使えるとは限りません。音声通話やゲーム、QUICを使うサービスでは、UDPへの対応、サーバー設定、クライアントのトラフィック処理、防火壁なども影響します。TUNを有効にしてもノードの帯域が増えるわけではありません。主にクライアントへのトラフィックの取り込み方を変える機能であり、すべての通信がHTTPテストと同じ経路を通ることを保証するものではありません。

url-testの設定：URLとテスト間隔を先に決める

以下はmihomoのプロキシグループ設定例であり、単独で動作する完全な設定ではありません。既存のproxiesに「香港-A」と「香港-B」という名前のノードが定義されている必要があります。設定に取り込む際は、実際に使用しているノード名に置き換えてください。ファイル末尾に同名のトップレベルproxy-groupsを追加しないでください。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• type: url-test：URLテストの結果に基づいて候補のアウトバウンドを選びます。帯域幅を測るグループではありません。
• url：このグループがテストに使う接続先です。上の例は軽量なHTTPSテストエンドポイントとしてよく使われますが、現在のネットワークから到達できるか確認してください。
• interval: 300：定期テストの間隔は300秒、つまり5分です。300ミリ秒ではありません。
• tolerance: 80：切り替えの許容差は80ミリ秒です。小さな遅延差による切り替えを抑えるために使います。
• lazy: true：mihomoの遅延テストの仕組みにより、使用されていないグループでは定期テストが継続して実行されない場合があります。確認時にバックグラウンドで常に更新されているとは限りません。

サブスクリプションの提供元が、proxy-providersのhealth-checkでヘルスチェックを設定している場合もあります。プロバイダーのチェック間隔、プロキシグループのinterval、クライアント画面からの手動テストは、それぞれ別の設定・操作です。どれか1つを変更しても、すべての表示やテスト動作が連動して変わるとは限りません。

toleranceの設定：小さな差による切り替えを抑える

toleranceは「許容される最大遅延」でも、「この値より小さければ合格」という基準でもありません。現在選択中のノードから、より速い候補へ切り替える際の許容差です。候補が少し速い程度なら現在の利用可能なノードを使い続け、設定した差を超えて速い場合に切り替える、と考えると分かりやすいでしょう。

mihomoでよく使われる選択ロジックを例にします。現在のノードが150 msで、候補が110 msなら、差はわずか40 msです。tolerance: 80では、通常、この程度の差だけで切り替わることはありません。候補が60 msになり、差が90 msになれば、許容差を超えます。実際の選択結果は、現在のノードの利用可否や有効なテスト結果、コアの実装にも左右されます。

数値を調整する前に順序を整える

1. まず、テストURLとネットワーク環境を固定し、ノードのテストが頻繁に失敗していないか確認します。
2. まずは許容差を50～100ミリ秒程度に設定して様子を見ます。これは設定を始める際の目安であり、すべての回線に適した基準ではありません。
3. 候補の遅延が近く、頻繁に切り替わる場合は、許容差を少し大きくします。明らかに速いノードが長期間選ばれない場合は、遅延差と現在有効なテスト結果を確認してください。
4. 現在のノードがすでに利用できない場合は、ヘルスチェックと失敗の検出を重点的に確認します。障害のあるノードを維持するための設定として、許容差を使わないでください。

切り替えの影響は通常、新しく確立する接続に及びます。既存のTCP接続が別のノードにシームレスに移行するわけではありません。切り替え後も以前からのダウンロードは遅いままなのに、新しく開いたページは速くなることがあります。また、intervalを1秒にして何度もテストするのはおすすめしません。テスト自体が接続と通信量を発生させ、過度なチェックは負荷を増やす一方で、実際の回線のばらつきをなくすことはできません。

テストURLの選び方：軽量で安定し、用途に合うもの

テストURLには、長期間アクセスでき、応答データができるだけ小さく、ログイン不要で、一時的な署名にも依存しないものを選びます。リダイレクトが何度も発生するURLも避けましょう。動画ページ全体や大容量ファイル、認証コードが必要なページをヘルスチェックに使うと、ページ側の動作をネットワーク障害と誤認しやすくなります。

https://www.gstatic.com/generate_204は、テストURLの候補として使えますが、どのネットワークにも適した唯一の選択肢ではありません。特定の出口で問題が起きる場合は、ログや接続先への到達性、応答ステータスを確認してから、別の安定した軽量エンドポイントでもテストしてください。1つのURLへの接続失敗だけで、すべての通信が使えないと判断することはできません。

HTTPとHTTPSのテスト結果を同じ順位に並べて比較するのも避けましょう。HTTPSでは通常、TLS関連の処理が加わります。テストURLをHTTPに変更して数値が下がっても、ノードの回線が改善したことにはなりません。特定のサービスに近い条件で確認したい場合は、そのサービスへの初回応答も別途テストできます。ただし、ログイン状態が必要なページをプロキシグループの常設ヘルスチェックに使うのは避けてください。

実際の通信と比較する：同じ経路で再テスト

「遅延は小さいのにWebページの表示が遅い」場合は、まずテスト結果と実際のリクエストが同じアウトバウンドを通っているか確認し、その後でDNSやスループット、接続先サービスを調べましょう。クライアントのメニュー名はバージョンによって異なるため、以下では特定バージョンの画面構成ではなく、機能を基準に手順を説明します。

1. 動作モードを確認：ルールで通信を振り分ける場合は、mode: ruleになっていることと、変更した設定が有効で、別のProfileが使われていないことを確認します。
2. 接続先の振り分けを確認：クライアントの接続一覧を開いて対象サイトにアクセスし、該当する接続の適用ルール、プロキシグループ、実際のアウトバウンドを確認します。必要に応じてログも調べてください。
3. ノードを一時的に固定：手動選択できるプロキシグループでノードAを固定し、比較中に自動で切り替わらないようにします。テストが終わったら、元の選択方法に戻してください。
4. 連続した測定結果を記録：同じネットワークから同じURLに10回テストし、中央値、最大値、失敗回数を記録します。失敗は別に集計し、0 msとして平均に含めないでください。
5. 実際の用途でもテスト：同じサイトから同じファイルを30秒間ダウンロードし、速度が安定した時点の値を記録します。動画の場合は、バッファリングやシーク後の再生再開、再生が続くかを確認します。
6. トラフィックの取り込み方式を個別に確認：TUNでのみ問題が起きる場合は、DNSやルーティング、UDPへの対応を調べます。システムプロキシ使用時に接続一覧へ通信が表示されない場合は、アプリがシステムプロキシに対応しているか確認してください。

ローカルのプロキシ接続先も確認しましょう。たとえば設定がmixed-port: 7890の場合、テストツールは現在のクライアントが実際に待ち受けている127.0.0.1:7890に接続します。他のクライアントが残した7897や1080を共通ポートと思い込まないでください。ポートが利用できるかどうかは、有効な設定と待ち受け状態で確認します。

比較が終わったら、障害の種類に応じて対処します。テストは安定しているのに大容量ファイルが遅い場合は、スループットや混雑を優先して確認します。特定のサイトだけ遅い場合は、接続先までの経路やルールを調べます。周期的に失敗する場合は、ネットワークの変動やノードの状態を確認してください。遅延の数値は候補の絞り込みに使い、最終判断は実際の用途でのテストに基づいて行います。

よくある質問：タイムアウト、手動テスト、自動選択