URL Testで測るのは小さなリクエストの応答時間で、ダウンロード速度ではない
まず結論から。Clashクライアントに表示される遅延は、通常、指定したプロキシ経由でカーネルがテストURLにアクセスしたときの応答時間です。単純なICMP Pingでも、ノードの帯域幅でもなく、動画の画質に直接換算できる数値でもありません。用途に合ったノードを選ぶには、遅延の変動、継続的な転送速度、接続先サイトへのアクセス可否、実際に適用されたルールをあわせて確認しましょう。
クライアントはテストを開始して結果を表示し、カーネルはプロキシ接続を確立して接続先にアクセスします。画面上の「遅延テスト」と「接続テスト」は異なるAPIを使う場合があり、遅延値を統一するか、2回目のリクエストを採用するかもカーネルやクライアントの設定によって異なります。結果を比較する前に、テストURLと測定方法が同じであることを確認してください。
- URL Test：小さなHTTPリクエストが成功するか、完了までにどれくらいかかるかを測定します。通常はミリ秒で表示されます。
- ダウンロードテスト：一定時間に転送できたデータ量を測定します。通常はMB/sまたはMbpsで表示され、実際に通信量を消費します。
- 実際の利用：DNS、コネクションの再利用、ページ内リソースの同時読み込み、サーバー側の処理、アプリ自体の待ち時間も影響します。
遅延テストのリクエストがたどる経路
テスト経路は「端末 → プロキシの入口 → プロキシの出口 → テストサイト」と簡略化できます。実際の構成では中継や多段プロキシを使うことがあり、入口と出口が同じ地域にあるとも限りません。リクエストにはこれらすべてが影響しますが、どの処理が表示値に含まれるかは、カーネルの実装、キャッシュの状態、コネクションを再利用するかどうかによります。
- 接続に必要なドメイン名を名前解決する。プロキシサーバーのドメイン名は名前解決が必要です。テスト先の名前解決がどこで行われるかはプロキシプロトコル、DNS設定、カーネルの動作によって異なり、すべてローカルで行われるとは限りません。
- プロキシへの接続を確立する。プロトコルによって、TCP、TLS、またはUDPベースのトランスポートのハンドシェイクが発生します。既存の接続を再利用する場合より、初回接続のほうが時間がかかるのが一般的です。
- プロキシ経由でテスト先にアクセスする。プロキシの出口からテストサイトまでの経路でも、ルーティング、輻輳キュー、接続先サイトの処理が影響します。
- HTTPレスポンスを受信する。HTTPSを使う場合は、テストサイトとのTLSセッションも関係します。レスポンスのステータス、リダイレクト、タイムアウトの処理も結果に影響します。
2回目のテストが大幅に速くなることがある理由
DNSキャッシュ、コネクションの再利用、TLSセッションの再開により、2回目以降のリクエストは短時間で完了することがあります。mihomoのunified-delayオプションは、プロキシプロトコルごとのハンドシェイク時間が遅延比較に与える影響を抑えるためのものです。有効時の数値を、測定条件の異なる結果とそのまま比較しないでください。調査中は設定を変えず、切り替え前後の差を回線の改善と取り違えないようにしましょう。
一括テストでは複数の接続が同時に発生します。性能に余裕のないルーターやモバイル回線、同時接続数が制限されたノードでは、測定自体が競合を引き起こすことがあります。「すべてテスト」を何度も続けても、順位の信頼性が高まるとは限りません。
テストURLがノードの順位に与える影響
テストURLは無視できる設定ではありません。ドメインによって接続先のCDNが異なり、同じドメインでもプロキシの出口や名前解決の結果次第で別のデータセンターにつながることがあります。テストサイトまでの経路が短いノードでも、動画配信サービス、コードホスティング、業務サイトまでの経路が短いとは限りません。
テストURLを選ぶ3つの条件
- レスポンスが小さい：HTTP 204を返す接続確認用URLなど、安定した小さなレスポンスを返すエンドポイントを選び、本文の転送による影響を抑えます。
- アクセス条件が安定している：ログイン、CAPTCHA、地域制限が必要なページや、頻繁にリダイレクトされるページは避けます。
- 測定条件を統一する：同じノード群を比較するときは、同一のURL、タイムアウト、ネットワーク環境を使い、異なるサイトの結果を混在させないでください。
https://www.gstatic.com/generate_204はよく使われる例で、HTTPSの既定ポートは443です。小さなリクエストの接続確認には適していますが、インターネット上のあらゆるサービスを代表するものではありません。ローカルネットワークや特定の出口からこのURLにアクセスできない場合、テストに失敗してもノード全体が使えないとは限りません。
| テスト結果 | まず確認できること | 追加で確認すること |
|---|---|---|
| 小さなリクエストの遅延が低い | 現在のテスト経路の応答が速い | 継続的な転送速度と目的のサービスでの実際の動作 |
| 1つのURLですべてタイムアウトする | テスト先または共通経路に問題がある可能性 | 別の信頼できるテスト先でも失敗するか |
| 特定のノードだけタイムアウトする | そのノードの現在の経路を調べる価値がある | 入口への接続、プロトコル設定、出口の状態 |
| 数値が頻繁に大きく変動する | 回線または測定条件が不安定 | ローカルWi-Fi、同時接続、高負荷時の輻輳 |
テストURLを変更したら、ノード群全体を再テストし、切り替えた時刻も記録しましょう。1つのノードだけを再測定して、他のノードの古いキャッシュ値と比較しないでください。
遅延の低いノードでも通信が遅くなる理由
小さなリクエストが速くても、継続的な転送が速いとは限らない
ごく小さなレスポンスなら、輻輳が目立つ前に返ってくることがあります。一方、大きなファイルのダウンロードや高ビットレート動画の再生では、継続的な転送が必要になるため、帯域幅の制限、パケットロスと再送、夜間の混雑、接続のリセットなどが表面化しやすくなります。遅延は応答時間、スループットは転送能力を表す指標です。相関はありますが、同じものではありません。
単位換算の例では、20 Mbpsの理論上の転送速度は約2.5 MB/sです。実際のアプリではプロトコルのオーバーヘッド分が差し引かれます。これは換算例であり、ノードの実測値ではありません。遅延が60 msのノードでも、150 msのノードよりダウンロードが遅いことは十分にあり得ます。
アプリの通信が測定したノードを経由していない可能性もある
単一ノードのテストでは通常、指定したプロキシ経由で接続を確認します。しかし、ブラウザーのリクエストにも同じルールやプロキシグループが適用されるとは限りません。アプリの通信がDIRECTに一致したり、別のプロキシグループに振り分けられたりすることがあります。ノードを手動で選んだ場合も、対象ドメインに最終的に適用されたルールと、プロキシチェーン全体を確認してください。
- クライアントの「接続」または「接続ログ」画面で対象ドメインを探し、ルール、プロキシグループ、アウトバウンドプロキシを確認します。
- 現在ルールモードになっていることを確認してください。誤って直接接続モードに切り替わっている場合があります。グローバルモードでは、
GLOBALの選択先を確認します。 - アプリがシステムプロキシを使わない場合は、TUNでの透過的な接続が必要か、アプリがルーティング対象から除外されていないかを確認します。
HTTPのテストではUDPやサービス側の制限を確認できない
一般的なHTTPSテストで確認できるのは、主に該当するHTTPリクエストの経路です。ゲーム、音声通話、一部のQUIC通信ではUDPが使われ、ノードのプロトコル対応、サーバー設定、ローカルルーティングも異なる場合があります。テストに成功してもUDPが必ず使えるとは限りません。TUNを有効にしても、ドメイン名の解決やUDP転送に関する問題がすべて自動的に解決するわけではありません。
また、接続先サービスが出口IP、アカウントの地域、リクエスト頻度を制限していることもあります。地域制限、403、CAPTCHAが表示された場合は、遅延値だけを見てノードを何度も切り替えるのではなく、サービスからの応答内容を確認してください。
url-testプロキシグループのinterval・toleranceの設定方法
url-testはテスト結果を自動比較するプロキシグループで、ダウンロード速度を測るツールではありません。以下は、これらのフィールドに対応するmihomoカーネル向けの例です。ノード-Aとノード-Bには、既存のproxiesで定義した名前を指定してください。使用前に実際の名前へ置き換え、この部分設定だけでサブスクリプション全体を上書きしないでください。
proxy-groups:
- name: 自動遅延
type: url-test
proxies:
- ノード-A
- ノード-B
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true
- name: 出口選択
type: select
proxies:
- 自動遅延
- ノード-A
- ノード-B
rules:
- MATCH,出口選択ここでのMATCHは、通信がプロキシグループに入る流れを示しています。既存の設定では、LAN向け、直接接続、用途別の振り分けルールを維持したうえで、フォールバック先または対象の通信を該当グループに指定してください。すでにproxy-groupsやrulesがある場合は、項目を追加・統合し、トップレベルのキーを重複させないでください。フィールドの全体構成はYAMLマニュアルを参照してください。
| フィールド | 設定例 | 意味と設定の考え方 |
|---|---|---|
interval | 300秒 | 定期テストの間隔です。1回のリクエストのタイムアウトではなく、時間が来るたびにノードを強制切り替えする設定でもありません。 |
tolerance | 50ミリ秒 | 切り替えの許容差です。小さな遅延差で現在のノードが頻繁に変わるのを防ぎます。 |
lazy | true | このグループを使っていないときに定期テストを省略し、測定負荷を抑えます。 |
url | HTTPSの小さなレスポンスを返すURL | テスト先を指定します。変更すると比較の基準も変わります。 |
まずは300秒と50ミリ秒に設定し、変動に応じて調整する
一般的なWeb閲覧なら、interval: 300、tolerance: 50を出発点にできますが、すべての環境に最適な値ではありません。ノード数が多い場合やモバイル回線を使う場合は、間隔を600秒に延ばす方法があります。ネットワークが頻繁に切り替わり、結果をより早く反映したい場合は、負荷を確認したうえで120秒を試してください。グループが未使用の場合や端末がスリープ中の場合など、実際にテストされるタイミングは状況によって変わります。
許容差は、安定性とのバランスを取るための設定です。現在のノードが120 ms、別のノードが100 msなら、差はわずか20 msです。許容差を50 msに設定すると、通常は現在利用できるノードが維持されます。別のノードが60 msなら、60 msの改善となり、切り替えが発生しやすくなります。これはパラメーターの説明例です。実際の動作は、利用可能な状態、過去の測定結果、カーネルの実装にも左右されます。
サブスクリプションの更新で手動変更が上書きされる場合は、クライアントが対応するオーバーライドまたはマージ機能を使ってください。設定画面の名称はクライアントごとに異なります。保存後は、エディター上の表示だけでなく、カーネルが実際に読み込んだ実行設定も確認しましょう。
実際の通信体感を確認する再現可能な手順
「Clashの測定値は速いのにWebページの表示が遅い」場合は、接続テストと実際のサービスの確認を分けて記録しましょう。一度に変更する条件を1つに絞ると、改善がノード、ルール、ローカルネットワークのどれによるものか判断できます。
- テスト条件を固定する。同じWi-Fiまたは有線ネットワーク、同じテストURL、同じ遅延設定を使い、上りまたは下りを占有するタスクを一時停止します。
- 連続した結果を記録する。候補ノードを2～3個選び、それぞれ約10秒間隔で5回テストします。最良値だけでなく、中央値、最大値、失敗回数を記録してください。
- 候補ノードを手動で固定する。
selectグループでノードを選び、サービスの動作を確認している間に自動グループが出口を切り替えないようにします。 - サービスへの接続をやり直す。対象ページを開き直すか、転送を再実行し、接続画面でドメイン、適用ルール、プロキシチェーンが一致していることを確認します。
- 継続的な動作を確認する。アクセス可能な同一ファイル、または同じ動画区間を使い、60～120秒間観察します。読み込み待ち、バッファリングの回数、安定した転送速度をそれぞれ記録してください。
- ローカル環境の要因を振り返る。すべてのノードで変動する場合は、まず有線接続とWi-Fiを比較し、バックグラウンドのアップロードやDNSを確認してから、プロキシのパラメーターを1つずつ変更します。
記録項目は「時刻、ノード、テストURL、5回分の遅延、失敗回数、接続先サービスの状態」の6項目で十分です。混雑時間帯だけ問題が起きる場合は、近い時間帯に再テストしてください。深夜と夜間のピーク時間帯の数値は、単純には比較できません。
最終的な選択は用途に合わせましょう。Web操作では応答性と安定性、ファイル転送では継続的なスループット、ゲームや音声通話では該当するUDP経路とジッターが重要です。url-testは、統一した小さなリクエストの指標で自動選別するのに適していますが、実際のサービスでの確認に代わるものではありません。手動選択の手段を1つ残しておくほうが、テスト間隔を短くし続けるより問題を特定しやすくなります。