Clashの遅延テストの仕組み：画面上の数値と実際の通信体験が一致しない理由

Clashクライアントに表示される遅延値は、ノードの品質順位として扱われがちです。しかし、この数値が示すのは、特定のテスト先に対して、その時点のネットワーク、DNSの状態、回線負荷で行った1回の測定結果にすぎません。ウェブページ全体の読み込み時間を表すものでも、ダウンロード速度、動画の安定性、長時間接続の品質を直接示すものでもありません。テストの仕組みを理解すれば遅延値は役立ちますが、適切な範囲で解釈する必要があります。

遅延テストで測定するもの

Clash、Clash Meta（mihomo）、および各種GUIクライアントは、通常HTTPまたはHTTPSのURLを使ってヘルスチェックを行います。クライアントは指定したプロキシノード経由でテストリクエストを送り、対象URLから条件を満たす応答が返るまでの時間を待ち、その所要時間をミリ秒で表示します。テストURL、タイムアウト、実装の詳細はクライアントや設定によって異なるため、同じノードでもクライアントごとに数値が変わることがあります。

この結果は、従来の意味でのICMP Pingとは異なります。システムの ping コマンドは通常ICMP Echoパケットを送信しますが、プロキシの遅延テストではTCP接続を確立し、HTTPSテストではTLSネゴシエーションも行います。ノードがWebSocket、gRPC、QUICなどの転送方式を使う場合、接続経路自体に追加のハンドシェイクが発生することもあります。両者は対象となるプロトコル、ポート、ルート、サーバー処理が異なるため、単純に比較できません。

1回のHTTPSテストに含まれる可能性がある段階

テストドメインを名前解決するか、既存のDNSキャッシュを読み込みます。
ローカル環境からプロキシノードへ接続し、ノードのプロトコルに必要なハンドシェイクを完了します。
プロキシ側からテスト対象のIPアドレスへ接続します。
対象サイトとのTCPおよびTLSネゴシエーションを完了します。
HTTPリクエストを送信し、レスポンスヘッダーまたは指定された内容を待ちます。
コアが所要時間を記録し、制御インターフェースを通じてクライアントに表示します。

毎回のテストで、すべての段階が完全に実行されるとは限りません。DNSキャッシュ、TLSセッション再開、接続プール、クライアントの実装によって、2回目以降のテストが短縮されることがあります。初回の数値が高く、2回目から大きく下がる場合は、ノードの経路が突然改善したのではなく、キャッシュや接続のウォームアップが原因であることがよくあります。

テスト対象が観測する経路を決める

ノードの出口に近いデータセンターにテストURLが配置されている場合、結果は主にローカル環境からノードまで、そしてノードからそのデータセンターまでの経路を反映します。実際にアクセスするサイトは、別の国、通信事業者、CDNリージョンにある可能性があり、後半の経路はまったく異なります。そのため、テストURLへの応答が速いノードでも、特定のサイトへのアクセスが遅いことがあります。

同じノードで数値が変わる理由

ネットワーク遅延は固定された属性ではありません。ある時点における複数の経路区間の状態を合計したものです。家庭内ネットワーク、アクセス回線、異なるネットワーク間の接続、ノードの入口、ノードの出口、テストサーバーのいずれかで待ち行列が発生すれば、結果は変わります。1回のクリックで得た最小値だけを比べると、偶発的な変動を過大評価してしまいます。

ローカル無線ネットワークとアクセス回線

Wi-Fiの電波が弱い、同一周波数帯で干渉している、バックグラウンドでアップロードしている、ルーターの負荷が高いといった状況は、いずれも待ち時間を増やします。特に上り帯域がほぼ使い切られていると、ルーターのバッファにパケットが滞留し、軽いテストでも数十ミリ秒から数百ミリ秒まで遅くなることがあります。この場合、混雑はトラフィックがプロキシに入る前に発生しているため、プロキシノードを切り替えても解決しません。

まずダウンロード、クラウドストレージの同期、動画のアップロードを一時停止してから、テストを繰り返してみましょう。すべてのノードが同時に速くなり、バックグラウンド処理を再開すると一斉に遅くなるなら、優先してローカルネットワークを確認します。可能であれば、有線接続でも比較テストを行うと、無線干渉の一部を切り分けられます。

DNSキャッシュと名前解決の経路

テストドメインの初回名前解決には、追加の時間がかかります。 fake-ip モードでは、コアがドメインと仮想アドレスの対応を管理し、接続時に対象ドメインを復元します。redir-host モードや実アドレスを直接返すモードでは、名前解決の経路が異なります。上流DNSの応答速度、キャッシュヒットの有無、プロキシ経由かどうかが、初回テストに影響します。

画面に表示される所要時間にDNS処理が含まれるかどうかは、コアのバージョン、テストAPI、クライアントの呼び出し方法によって異なります。実装を確認できない場合は、DNSを潜在的な変数として扱い、1つの数値から特定の段階の正確な所要時間を推測しないようにしましょう。

接続の再利用とウォームアップ効果

テストを連続して実行すると、内部で確立済みの接続が再利用されたり、システムキャッシュ、TLSセッションチケット、解決済みアドレスが利用されたりすることがあります。後続のテストでは準備処理の一部が省かれるため、結果が低くなります。一方、クライアントが毎回新しい接続を強制すれば、新規アクセスの開始コストに近い数値になりますが、ウェブページが読み込む複数ドメインのリソースや並列リクエストまでは反映できません。

回線の混雑とジッター

夜間のピーク、ネットワーク間の接続点の混雑、出口側の負荷上昇によって、ノードの遅延は周期的に変化します。5回の結果が65、68、210、72、190ミリ秒だった場合、最小値だけを見ると非常に速い回線だと判断してしまい、平均値だけではスパイクの頻度を見落とす可能性があります。中央値、最大値、タイムアウト回数を同時に記録するほうが、実態を把握しやすくなります。

現象	よくある原因	次に確認すること
初回は高く、その後は安定して低下する	DNS、TLS、または接続のウォームアップ	少し間隔を空けて再テストする
すべてのノードが同時に高くなる	ローカルネットワークまたはテスト対象の異常	バックグラウンド通信を停止し、別のテスト対象と比較する
1つのノードだけ継続的にタイムアウトする	ノードに到達できない、ハンドシェイク失敗、または出口障害	コアのログとサブスクリプションの状態を確認する
数値は低いのにウェブページが遅い	対象までの経路、パケットロス、または帯域制限	実際にアクセスする対象へ直接テストする
数値が周期的に大きく変動する	回線混雑、無線干渉、またはノード負荷の変化	時間帯別に記録し、ジッターを確認する

低遅延でもアクセスが速いとは限らない理由

ウェブ体験は複数の段階で決まります。遅延テストは通常、軽量なURLを1つだけ取得しますが、現代のウェブページはHTML、スクリプト、スタイル、画像、API、外部リソースを読み込みます。これらのリソースは複数のドメインに分散し、異なるルールで別々のプロキシグループへ振り分けられることがあります。1つのテストリクエストが成功しても、ページ全体の接続構成を確認したことにはなりません。

帯域幅と遅延は別の指標

遅延はリクエストの往復にかかる時間を示し、帯域幅は単位時間に転送できるデータ量を示します。40ミリ秒でも出口帯域が小さいノードは、軽いページの表示は速くても大容量ファイルのダウンロードは遅くなります。一方、90ミリ秒でも帯域が十分で安定したノードは、初回応答こそ少し遅くても、高画質動画や大容量ダウンロードに向く場合があります。

ダウンロード速度は、TCP輻輳制御、受信ウィンドウ、パケットロスによる再送、対象サーバーの速度制限にも左右されます。帯域の大きい回線でも継続的にパケットロスが発生すれば、再送を繰り返して期待したスループットに達しないことがあります。画面上の遅延値には、通常これらの情報は直接表示されません。

リアルタイム通信では、1回の最小値よりジッターが重要

音声通話、リモートデスクトップ、インタラクティブな接続では、遅延の安定性が重視されます。テスト結果が50〜300ミリ秒の間を行き来すると、最小値がどれだけ低くても、入力への反応や音声再生が途切れます。それに対し、90ミリ秒前後で安定する回線のほうが、予測しやすい通信体験になりやすいでしょう。

通常の遅延テストは、厳密なパケットロステストと同じではありません。タイムアウトは深刻な問題の兆候になりますが、少量のパケットロスは、ある回だけ数値が急上昇する形で現れることがあります。リアルタイム通信を分析するには、連続観測を追加し、システムのネットワークツール、アプリのログ、実際のセッションも組み合わせて確認しましょう。クライアントカードに表示された1つの数値だけで判断してはいけません。

ルールによる振り分けが実際の出口を変える

Clashは上から順にルールを照合してリクエストを処理します。あるプロキシグループをテストすると、そのグループで現在選択されているノードが使われます。しかし、実際のウェブサイトでは別のプロキシグループ、DIRECTルール、またはフォールバックルールに一致することがあります。たとえばメインサイトのドメインはプロキシ経由でも、静的リソースのドメインが直接接続になる場合、ページの体験は複数の経路によって決まります。

トラブル対処では、接続一覧またはコアのログを開き、対象ドメインがどのルールに一致したか、どのプロキシグループが選ばれたか、最終的にどのノードが使われたかを確認します。プロキシグループの画面で何度も速度テストを行うだけでは、実際の通信が同じ出口へ送られているか検証できません。

TUNモードで回線遅延が自動的に下がるわけではない

TUNモードは、より多くのシステム通信を取り込み、IPパケットをコアに処理させるための機能です。システムプロキシ設定に従わないアプリも対象にできますが、物理的な通信経路を短くするものではありません。TUNを有効にすると、DNSのリダイレクト、ルーティングルール、MTU、システムファイアウォールの設定が通信経路に関わります。設定が適切でない場合、特定サイトだけ遅い、接続を確立できない、大きなパケットの転送に失敗するといった問題が起こることがあります。

システムプロキシとTUNモードを比較する際は、ノード、ルール、テスト対象、ネットワーク環境をそろえましょう。TUNモードだけで問題が起きるなら、ノード品質の変化だと決めつけず、DNSの取り込み、ルーティングの除外範囲、IPv6の挙動、MTUを確認します。

url-test、fallback、手動プロキシグループでの遅延値の使われ方

Clashの設定におけるプロキシグループの種類によって、ヘルスチェック結果を選択にどう反映するかが決まります。手動の select グループは候補を提示するだけで、別のノードの遅延が低くても自動では切り替わりません。url-test グループは指定URLを定期的にテストし、利用可能なノードの中から遅延が低いものを選ぶ傾向があります。fallback グループは候補が利用可能かどうかを重視し、通常は設定順に、チェックを通過した最初のノードを選びます。単純に最小のミリ秒数を追いかける仕組みではありません。

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: BACKUP
    type: fallback
    proxies:
      - NODE-A
      - NODE-B
    url: https://www.gstatic.com/generate_204
    interval: 300

interval は定期チェックの間隔を制御します。間隔が短すぎるとノードやテスト対象へのリクエストが増え、短時間の変動に反応して頻繁に切り替わりやすくなります。長すぎると、回線の変化をすぐに検知できません。普段使いでは数分単位から始め、ノードの安定性を見ながら調整するとよいでしょう。

tolerance は、遅延が近いノード間で url-test が頻繁に切り替わるのを抑えるために使います。コアのバージョンによって細かな実装は異なる場合がありますが、目的は共通しています。候補間の差が小さいときは現在の選択を維持し、わずかな揺れのたびに出口が変わるのを防ぎます。長時間接続、ログインセッション、ダウンロード作業では、こうした安定性が特に重要です。

lazy を有効にすると、プロキシグループが実際に使われていない間、コアが能動的なチェックを減らせます。待機中のテスト負荷を下げるのに適していますが、長時間使われていなかったグループを再び有効にした際、新しい結果が出るまで待つことがあります。クライアント画面の「今すぐテスト」ボタンは通常、手動でチェックを開始するため、バックグラウンドの定期チェックとは分けて考えてください。

再現可能なノードテスト方法を作る

信頼できる比較には、変数をそろえることが必要です。テスト中にノード、DNSモード、TUN設定、テストURLを同時に変更すると、差がどこから生じたのか判断できません。環境を固定し、段階ごとに記録する方法が適しています。

ローカル接続を固定する。同じ端末、同じWi-Fiまたは有線ネットワークでテストし、大容量のアップロード、ダウンロード、システム更新を一時停止します。
サブスクリプションの更新を確認する。ノード名、プロトコルパラメータ、プロキシグループの参照先を確認し、すでに無効になったノードやサブスクリプションから削除された項目をテストしないようにします。
テスト対象を固定する。まずクライアントの既定URLで1周テストし、その後、実際の用途と地域に関係する安定したURLで比較します。
連打せず、繰り返し測定する。各ノードを複数回テストし、測定の間には適切な間隔を空け、中央値、変動幅、タイムアウト回数を記録します。
実際のルールを確認する。対象サイトへアクセスした後、接続一覧を確認し、ドメイン、ルール、プロキシグループ、最終ノードが想定どおりか確かめます。
実際の用途で確認する。ページの初回表示、動画のバッファリング、大容量ファイルのダウンロード、リモート接続をそれぞれ観察し、1種類のテストですべての用途を判断しないようにします。
時間帯を変えて再測定する。普段使う時間帯と夜間のピーク時にそれぞれ記録し、ノードに周期的な混雑がないか判断します。

結果を記録する際、実験室レベルの精度を求める必要はありません。ノード名、測定時刻、3〜5回分の遅延、タイムアウト回数、対象サイトの初回表示の体感、継続ダウンロード速度を簡単な表にまとめるだけで十分です。数日続ければ、安定したノード、空いている時間帯だけ良好なノード、特定の対象への経路に適したノードを見分けられるようになります。

中央値を優先して見る理由

平均値は1回だけ極端に高い結果が出ると引き上げられ、最小値は楽観的すぎます。5回の結果を並べて中央の値を取ると、偶発的なスパイクの影響を抑えられます。たとえば62、64、66、70、420ミリ秒の中央値は66ミリ秒で、多くのリクエストの状態に近い値です。ただし420ミリ秒はジッターのリスクとして残し、単純に削除してはいけません。

複数のノードで中央値の差が数十ミリ秒程度しかない場合は、安定性、タイムアウト回数、実際の対象での結果を優先して比較しましょう。一般的なウェブページでは、この程度の差はDNS、ページスクリプトの実行、サーバー応答による変動より小さいことがよくあります。

遅延異常と全面的なタイムアウトの対処手順

画面にタイムアウト、失敗、異常に高い遅延が表示されたら、まず1つのノードだけの問題なのか、すべてのノードの問題なのか、特定のテストURLだけの問題なのかを切り分けます。設定をすぐに変更するより、影響範囲を判断することが重要です。

1つのノードだけ異常な場合

サブスクリプションを直前に更新していないか、ノードのプロトコル、ポート、転送経路、サーバー名が完全かを確認します。
コアのログで、ハンドシェイク失敗、接続拒否、タイムアウト、証明書に関する情報を確認します。
プロキシグループ名の重複、同名項目による上書き、プロバイダーのフィルタールールによって、そのノードが除外されていないか確認します。
同じサブスクリプション内の別ノードへ切り替え、単一の入口の障害なのか、サーバー側の地域全体の異常なのかを判断します。

すべてのノードが同時に異常な場合

まず端末が正常にインターネットへ接続できることを確認し、システム時刻が正確かも確認します。
上り帯域を消費している処理を一時停止し、ローカル側のバッファ膨張を切り分けます。
テストURLに直接接続できるか、リダイレクト、レート制限、地域によるブロックが発生していないか確認します。
上流DNSが利用可能か確認します。特にTUNモードでは、DNSの取り込みとファイアウォールの権限を確認してください。
画面を更新するだけでコアの状態が戻っていない可能性があるため、コアを再起動してからもう一度テストします。

速度テストは正常なのに対象サイトが異常な場合

この場合は対象サイトへの接続から確認します。適用されたルールと出口を確認し、対象ドメインが異常なアドレスに解決されていないか調べます。必要に応じて、システムプロキシとTUNモードを比較してください。ページの画像やAPIだけが遅い場合は、それらのリソースが利用する個別ドメインも確認します。テストURLが正常でも、そのテスト経路が利用可能だと示すだけで、すべての対象経路が正常だとは限りません。

用途に応じたノード選び

ノード選びに、すべての用途へ通用する最低遅延の基準はありません。ニュースの閲覧や文書作成では、数十ミリ秒の差より安定性と正しいルール適用が重要です。リアルタイム音声、クラウドゲーム、リモートデスクトップでは、低ジッターと低パケットロスが重視されます。動画や大容量ダウンロードでは、継続的なスループットと少ない再送が必要です。

ウェブ閲覧: 初回接続、DNSの安定性、対象サイトまでの経路を確認します。遅延が近い候補の中では、タイムアウトが少ないノードを選ぶとよいでしょう。
リアルタイム通信: 連続した遅延、ジッター、パケットロスを確認します。たまに最小値を出す回線より、少し低めの遅延が安定する回線のほうが適しています。
動画とダウンロード: 継続的な帯域、夜間の混雑、接続切断を確認します。軽量なヘルスチェックは、到達可能性を判断する参考にとどまります。
複数ルールによる振り分け: 用途に対応するプロキシグループとルールを個別に検証し、1つの自動選択グループの結果で、すべての出口を判断しないようにします。

普段の設定では、手動プロキシグループと自動テスト用プロキシグループを1つずつ用意すると便利です。自動グループは利用可能なノードから基本的な候補を選び、手動グループは重要なセッションを固定したり、対象経路の違いに対応したりするために使います。自動グループの切り替えが頻繁なら、許容差を大きくするかチェック間隔を延ばします。ノード障害からの復帰が遅すぎる場合は、間隔を短くしてバランスを取ります。

最終的に、遅延値は品質の結論ではなく、診断の手がかりとして捉えましょう。まずテスト対象と経路を確認し、次に連続した結果を観察し、最後に実際の用途で検証します。これにより、Clashとmihomoのヘルスチェック機能を活用しながら、1回だけの最小値でノードを頻繁に切り替え、長時間接続を切断したり、ログイン状態を変化させたり、通信体験を不安定にしたりする事態を避けられます。