Clashの遅延テストの仕組み：速度測定の数値が実際の使用感と一致しない理由

Clashまたはmihomoのプロキシグループでは、ノードの横に遅延を示す数値が表示されることがあります。この数値は素早い並べ替えには便利ですが、ウェブページの表示速度、動画のバッファリング、長時間接続の安定性をそのまま表すものではありません。遅延テストは、端末から特定のテスト先までの一部の区間を測定しているにすぎず、実際のアクセスではDNS解決、プロキシのハンドシェイク、TLS接続、接続先サーバーの処理、コンテンツ転送などが発生するためです。

測定結果を正しく理解するには、まずテスト方法を区別し、次にテスト先が実際の利用先に近いかを確認します。Clashで表示される遅延は、ノードのヘルスチェック、URL Test、クライアント独自のテストなどに基づく場合があります。クライアント、コアのバージョン、設定ファイルによって実装の詳細も異なります。80ミリ秒と120ミリ秒の結果を見ても、数値だけで前者を選ぶのではなく、ジッター、パケットロス、出口地域、ルールの適用先、接続先サーバーの応答を合わせて判断しましょう。

速度測定の数値は何を測っているのか

プロキシノードの遅延テストでは、通常、ウェブページ全体をダウンロードするのではなく、指定されたアドレスに対して軽量なリクエストを送信します。テストには、プロキシサーバーへの接続、プロキシプロトコルのハンドシェイク、テストURLへのアクセスが含まれる場合があります。表示されるミリ秒数は、クライアントの計測方法によって変わります。TCP接続の確立時間を測る実装もあれば、HTTPリクエストに対する応答を受け取るまでを測る実装もあり、コアが提供するヘルスチェック結果を利用する場合もあります。

TCP遅延とHTTP遅延

TCP遅延は、トランスポート層の接続をどれだけ早く確立できるかを示します。クライアントが接続先へSYNを送信し、サーバーがSYN-ACKを返し、接続が確立してからデータ転送が始まります。この段階で主に反映されるのはネットワーク経路と接続確立の処理で、ウェブページ全体の処理時間は通常含まれません。

HTTPテストでは、接続を確立したうえでリクエストを送り、接続先からHTTPレスポンスが返るまで待ちます。そのため、接続先サーバーの負荷、リバースプロキシの待ち行列、TLS設定、リダイレクト、レスポンス生成速度の影響を受けます。HTTPテストは単純なTCP接続よりも「サイトへアクセスする」感覚に近い結果になりやすいものの、固定された1つの接続先を測っているにすぎません。

HTTPSを使う場合、初回アクセスにはTLSハンドシェイクが含まれることがあります。接続の再利用が有効なら、後続のリクエストでは既存の接続を使えるため、一部の接続確立コストを省けます。そのため、同じノードでも初めてページを開く場合と連続して更新する場合では、表示される所要時間が異なることがあります。テストツールが接続を再利用するかどうかによっても、数値の意味は変わります。

テスト先が結果の範囲を決める

テストURLは、ネットワーク品質を測る絶対的な基準ではありません。テスト先と出口ノードの地理的な距離、通信事業者間の接続品質、サーバー負荷、CDNの振り分けが結果に影響します。あるノードからテストサイトへ速くアクセスできても、実際に利用するサービスまで速いとは限りません。テスト先が特定地域にあり、実際のアクセス先が別地域のCDNから配信されているなら、両者に大きな差が出るのは自然です。

また、プロキシルールによって、リクエストが本当に対象ノードを通るかどうかが決まります。テスト先がDIRECTにマッチしていれば、表示されるのは端末からの直接接続経路かもしれません。プロキシグループにマッチした場合に限り、そのグループで現在選択されているノードを経由します。調査ではまず接続詳細やルールのマッチ履歴を確認し、テスト通信が想定したポリシーグループを使っていることを確かめましょう。

URL Test、接続確認、実際のアクセスの違い

URL Testの主な目的は、複数のノードから同じURLへアクセスした際の応答時間を比較し、遅延の小さいノードを選ぶことです。ノード数が多い場合の初期選別や、自動選択型ポリシーグループに定期的な判断材料を与える用途に適しています。ただし、帯域幅を測るテストでも、すべてのウェブサイトを総合評価する仕組みでもありません。

1. 接続確認：「接続先へ到達できるか」だけを確認します。結果は成功または失敗になることが多く、所要時間の情報は限られます。
2. TCPテスト：接続確立の速さを重視し、経路の基本的な応答を確認するのに適しています。ただし、HTTPサービスの処理速度までは分かりません。
3. URL Test：固定URLへリクエストを送り、応答時間を比較します。接続先サイトの状態やリクエスト方法の影響を受けます。
4. 実際のアクセス：DNS、ルール判定、プロキシプロトコル、TLS、ページリソース、APIリクエスト、コンテンツ転送を含みます。経路が長く、変動要因も多くなります。

たとえば、URL Testで70ミリ秒だったノードでも、大規模なウェブページを開くと期待ほど速くないことがあります。ページに複数のクロスドメインリソースが含まれ、その一部が遠いCDNへ振り分けられている場合があるためです。一方、表示が110ミリ秒のノードでも、出口地域が対象サービスに近く、接続が安定していれば、実際の初期表示や連続したリクエストはよりスムーズかもしれません。動画、リモート端末、リアルタイム通信では、1回のテストにおける40ミリ秒の差より安定性が重要になることが多いです。

同じノードの測定値が変化する理由

ノードの遅延は一定ではありません。家庭内Wi-Fiの干渉、LAN内のアップロード帯域の占有、通信事業者の混雑時間帯、プロキシサーバーの同時接続数、テストURLの瞬間的な負荷などが変動を引き起こします。テスト間隔が短いと接続が再利用されることがあり、間隔が長いと接続が閉じて再接続やハンドシェイクが必要になるため、所要時間が増える場合があります。複数のテストを同時に実行すると、端末やノード側で余分な待ち時間が発生することもあります。

クライアントのテスト間隔にも注意が必要です。間隔が短すぎるとリクエストが頻発し、長すぎるとノードの状態変化をすぐに検知できません。自動選択グループが測定結果に基づいてノードを切り替える場合、切り替えによって一部の接続が中断されます。ダウンロードやログインセッションでは、中程度の遅延でも安定したノードを維持するほうが、頻繁に切り替えるより適していることがあります。

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

平均遅延は、サンプル群の中心的な水準を示すだけで、各リクエストが一貫しているかまでは表しません。ジッターとは、時間の経過に伴う遅延の変動幅です。たとえば82、85、83、210、91ミリ秒と連続して測定された場合、平均値は許容範囲でも、210ミリ秒の突発的な待ち時間が操作感を損ないます。音声通話、ゲーム、リモートデスクトップ、継続的なAPIリクエストは、特にジッターの影響を受けやすい分野です。

パケットロスは、送信したデータパケットが想定時間内に届かなかったり、応答が返ってこなかったりする状態です。TCPは再送によって信頼性を確保しますが、再送には待ち時間が発生し、輻輳制御によって送信速度が低下することもあります。短いURL Testでは少量のパケットロスが表面化しなくても、大容量ファイル、長時間接続、動画の連続再生では蓄積して再生停止やカクつきにつながります。

スループットは、単位時間あたりに転送できるデータ量を示します。ノードの出口帯域、共有ユーザー数、輻輳制御、プロトコルのオーバーヘッド、接続先サーバーの速度制限などの影響を受けます。遅延の小さいノードが必ずしも高スループットとは限りません。小さなリクエストには素早く応答できても、大容量ファイルのダウンロードでは速度が落ちる場合があります。逆に、遅延がやや大きくても帯域が十分なノードは、システム更新、ファイル同期、高ビットレート動画の視聴に適することがあります。

Clashの設定とルールから測定値の差を切り分ける

同じ端末上のアプリでも、マッチするルールが異なれば別の経路を使うことがあります。設定ファイルのDOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCHなどのルールが順番に評価され、最終的にDIRECT、特定のプロキシグループ、または別のポリシーへリクエストが渡されます。プロキシグループ名だけを見て、対象ドメインが実際にどのルールへマッチしたかを確認しないまま測定すると、直接接続の速度とプロキシ経由の速度を混同しやすくなります。

DNSもテスト結果と実際のアクセスに影響します。ドメイン解決は端末上で行われる場合もあれば、プロキシ経由や設定したDNSモードで行われる場合もあります。解決結果はCDNの振り分けに関係するため、リゾルバーの所在地とプロキシの出口位置が一致しないと、最適でないアドレスが返されることがあります。Fake-IPモードではドメインに仮想アドレスを割り当て、後続の接続段階でコアが元のドメインと関連付けます。変わるのはドメイン解決とルール判定の流れであり、ネットワーク遅延が下がることを意味するものではありません。

TUNモードを使うと、仮想ネットワークアダプターに取り込めるシステム通信が増え、システムプロキシ設定に従わないアプリも処理しやすくなります。TUNを有効にしても、通信がプロキシを通るかどうかはルーティング、DNS、ルール設定によって決まります。ブラウザーだけでテストしている場合、問題がシステムサービスや別のアプリにあるなら、ブラウザーのURL Test結果ではその通信を評価できません。調査時は、アプリ、ドメイン、接続先IP、適用ルール、実際のポリシーグループを記録しましょう。

再現性のあるテスト手順

1. テスト端末、ネットワーク接続、テスト時間を固定し、帯域を大量に使用する同期やダウンロードを一時停止します。
2. テストURLにアクセスできることを確認し、クライアントが使用するテスト方法、テスト間隔、接続先アドレスを記録します。
3. 候補ノードを3～5個選び、複数回連続してテストします。最低値だけでなく、中央値、最高値、失敗回数も記録しましょう。
4. 普段使うサービスへ個別にアクセスし、初期表示までの待ち時間、接続切断、ページリソースの読み込み失敗、継続的なダウンロード速度を確認します。
5. ログでルールのマッチ結果とDNSの応答を確認し、比較対象が本当に同じプロキシ経路を使用していることを確かめます。
6. 時間帯を変えて再測定します。混雑時間帯の変動が大きい場合は、単発の最低遅延を追い続けるより、安定性と予備のポリシーを優先します。

テスト記録の例：
ノードA | URL Test中央値 86 ms | 最高値 142 ms | 失敗 0/10 | ダウンロード安定
ノードB | URL Test中央値 63 ms | 最高値 310 ms | 失敗 2/10 | 変動大
ノードC | URL Test中央値 118 ms | 最高値 135 ms | 失敗 0/10 | スループット高め

利用シーンに合わせたノードの選び方

ウェブ閲覧では、DNS解決、TLS接続、最初の1バイトまでの時間が重要です。遅延が中程度でもジッターが小さく、ルール適用が安定しているノードを優先するとよいでしょう。ページのリソースが複数のドメインから配信される場合は、関連ドメインが不適切なポリシーグループへ誤って割り当てられていないかも確認します。

動画再生では、安定したスループットとコンテンツCDNまでの経路がより重要です。初期バッファリングには遅延が影響しますが、再生が始まった後は帯域とパケットロスが大きく関わります。テストではノードカードのミリ秒数だけで並べ替えず、一定時間の継続的なダウンロードを確認しましょう。

オンラインゲームやリモートデスクトップでは、往復時間が短く安定していることが求められ、ジッターとパケットロスにも敏感です。ノードの地域が接続先サーバーに近いことは有利ですが、通信事業者間の接続品質も同じように重要です。一時的に遅延が上昇したときは、すぐにノード障害と判断せず、端末側の混雑、Wi-Fi信号の変化、バックグラウンドのアップロードがないか確認してください。

ファイルのダウンロードやシステム更新では、スループット、接続の維持時間、サーバー側の速度制限が重視されます。遅延が数十ミリ秒増えても、大容量ファイルの転送速度には通常大きな影響はありません。ノードが頻繁に切り替わると、かえって接続の再確立が必要になることがあります。固定のポリシーグループを使い、ノードが継続して安定していることを確認してから長時間の転送を始めるとよいでしょう。

自動選択型ポリシーグループでは、URL Testを選別条件の1つとして使い、唯一の判断基準にはしないことをおすすめします。適切な設定では、ノードの可用性、地域要件、倍率ルール、サービスとの互換性、予備ノードの順番も考慮します。自動切り替えの目的は手動メンテナンスを減らすことであり、すべての通信が常に最低値を追い続けることではありません。

よくある誤解と切り分けの結論

「遅延が最小なら最速」

最低遅延は、あるテストで応答が速かったことだけを示します。ノードの帯域が不足していたり、パケットロスが多かったり、接続先までの経路が適切でなかったりすると、実際のダウンロードやページ表示は遅くなることがあります。中央値、変動幅、失敗回数を実際のサービス利用テストと合わせて判断しましょう。

「速度テストに成功すれば、すべてのサイトが使える」

テスト先が応答したことから分かるのは、その時点でそのテスト経路が利用できたという事実だけです。ドメインごとに異なるルール、DNS結果、出口経路が適用される場合があり、接続先サイトの地域制限やサーバー側のポリシーの影響を受けることもあります。特定のサイトだけに問題がある場合は、まずそのドメインのルール適用結果と接続ログを確認してください。

「TUNを有効にすれば遅延問題が自動的に解決する」

TUNが解決するのは、システムプロキシを利用できない一部のアプリの通信を取り込む問題です。物理的な距離、ノードの帯域、接続先サーバーの負荷が変わるわけではありません。有効にした後は、システムルート、DNS処理、権限、既存VPNとの競合も確認する必要があります。正しく設定すれば通信経路をより完全にできますが、経路を誤ると切り分けが複雑になることもあります。

「1回のテストでノード選びは十分」

1回の結果は、一時的な混雑や接続先サイトの状態に左右されやすいものです。少なくとも複数回テストし、実際の利用シーンでも確認してください。最低値だけがきれいで、最高値や失敗回数が明らかに多いノードは、第一候補ではなく不安定なノードとして扱うべきです。

Clashの遅延値は、使用感を評価する最終スコアではなく、ネットワーク状態を観測するための有用な入口です。まずテスト方法と接続先を確認し、次にルール、DNS、プロキシ経路を調べ、最後にジッター、パケットロス、スループット、実際のサービス利用結果を合わせて判断します。再現性のある記録方法を使えば、ノード選びは「1つのミリ秒数を見る作業」から、説明と再検証が可能なネットワーク診断へ変わります。