Clashの遅延テストの数字の見方：80msのノードのほうが遅く感じる理由

Clashの遅延テストで実際に測っているもの

Clashの画面に表示される80 ms、150 ms、500 msといった数値は、通常のICMP Pingとは異なります。Clash Premium、Clash for Windows 0.20.39、mihomoカーネルを使用するClash Verge Rev 2.3.xを例にすると、クライアントは通常、指定したプロキシノードを経由してカーネルからテストURLへアクセスし、リクエスト完了までの時間を記録します。よく使われるアドレスには https://www.gstatic.com/generate_204 や https://cp.cloudflare.com/generate_204 があります。サーバーは本文が空のHTTP 204を返すため、接続確認に適しています。

このリクエストは、ローカルのClashカーネル、ノードの入口、プロキシ転送経路、ノードの出口、テストサイトを通過します。計測値にはTCP接続の確立、TLSハンドシェイク、プロキシプロトコルのハンドシェイク、HTTPレスポンス待ちの時間が含まれる場合があります。範囲はカーネルのバージョン、接続の再利用、テストURL、クライアントの実装によって異なります。そのため、この数値は「小さなWebリクエスト1回にかかった時間」に近く、端末からノードサーバーまでの物理的な往復遅延と直接同じものではありません。

テスト方式	主な計測対象	分かること
Clash URL Test	プロキシ経由で指定したHTTPまたはHTTPSアドレスへアクセスする所要時間	そのノードが現在、小さなリクエストを素早く完了できるか
`ping`	ICMPの往復時間とパケットロス	宛先がICMPに応答するか、基礎経路が不安定でないか
ダウンロードテスト	継続転送時のスループット	大容量ファイル、動画、アップデートをどれだけ速く処理できるか
実際のWebページ読み込み	DNS、接続、リソース数、宛先サイトの処理時間	閲覧体験が安定しているか

テストURLによって結果は変わる

テスト対象は中立的な基準ではありません。たとえばノードの出口が東京にある場合、アジアにあり相互接続の良好なテストサイトへアクセスすると75 msになることがあります。一方、経路が遠く接続方式も異なるサイトに変更すると、同じノードでも160 msになる可能性があります。テストサイトが特定の出口IPを帯域制限したり、接続を拒否したり、TLSエラーを引き起こしたりすると、Clashにタイムアウトが表示される場合もあります。ただし、これはすべてのWebサイトが利用できないことを意味しません。

なぜ80msのノードのほうが150msより遅く感じるのか

80 msという値は、ある1回の小さなリクエストが速かったことを示すだけです。Web閲覧、動画再生、コード取得、クラウドストレージのダウンロードでは複数の接続を確立して継続的にデータを転送するため、体感はパケットロス、ジッター、帯域幅、輻輳、出口品質にも左右されます。低遅延でも数秒おきに再送が発生するノードは、遅延がやや高くても安定したノードより使いにくいことがよくあります。

パケットロスは再送と輻輳制御を引き起こす

TCPではデータが順序どおりに届く必要があります。あるセグメントが失われると、後続データが到着していても再送を待たなければならない場合があります。1回のURL Testで送るデータ量は少ないため、たまたまパケットロスに当たらなければ80 msと表示されます。しかし数十個のリソースを含むWebページを開くと、接続数とデータ量が増え、パケットロスが表面化する確率も高くなります。

1回の結果だけでなく、リクエストを100回連続して観察してみましょう。たとえばノードAは中央値82 msでも、95パーセンタイルが780 msで、3%のリクエストが失敗するかもしれません。ノードBは中央値148 ms、95パーセンタイル190 ms、失敗率0%です。Web閲覧や会議通話では、ノードBのほうが安定することが多いでしょう。1回だけの最小値は、継続利用中の品質を表しません。

低遅延でも利用可能な帯域幅が高いとは限らない

URL Testのレスポンス本文は通常空で、継続的なスループットはほとんど測定しません。帯域制限が5 Mbpsのノードでも70 ms以内に204を返せますが、500 MBのファイルをダウンロードする場合、理論上データ転送だけで約800秒かかります。一方、160 msでも安定して80 Mbpsを提供するノードなら、同じデータ量をはるかに速く処理できます。動画が高ビットレートになると、帯域不足は画質の頻繁な低下やバッファリングとして現れます。

混雑時間帯の輻輳とキュー遅延

家庭回線の上り、通信事業者の国際回線、ノード入口では、いずれも待ち行列が発生する可能性があります。空いているときは80 msでも、ダウンロードを始めると遅延が600 msまで上がるなら、典型的な負荷時遅延の増加です。この状態では、速度測定ソフトが高いスループットを示していても、ページのクリック応答は遅くなります。ノードを判断するときは、アイドル時と転送中の遅延を分けて観察し、深夜の1回の数値だけを記録しないでください。

アイドル時遅延：目立ったアップロードやダウンロードがない状態で測定し、基礎経路を確認します。
負荷時遅延：継続的なダウンロードまたはアップロード中に測定し、キュー管理と輻輳の状態を確認します。
ジッター：複数回の結果のばらつきです。80、83、79 msなら比較的安定していますが、80、420、95 msなら不安定です。
失敗率：タイムアウト回数をテスト総数で割った値です。継続利用では、1回だけの最小値より重要です。

URL Test、ヘルスチェック、自動選択の違い

手動で「遅延テスト」を実行すると、通常は画面上の現在の結果だけが更新されます。一方、設定ファイルの url-test プロキシグループは、メンバーを定期的にテストして結果に応じて自動選択します。プロキシプロバイダーの health-check は、ノードが利用可能かを確認します。3つとも似たリクエスト方式を使えますが、実行タイミングと目的は異なります。

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

この例では、interval: 300 は自動選択グループが設定した間隔でテストすることを示し、tolerance: 80 は遅延が近いノード間で頻繁に切り替わるのを抑えます。現在のノードが許容範囲内にある限り、数ミリ秒の差だけで接続をすぐ移行する必要はありません。lazy: true は、プロキシグループが実際に使われていないときに不要な能動テストを減らせることを示します。Clashの各派生版では対応フィールドが異なるため、使用前に現在のmihomoまたはクライアントのカーネルドキュメントを確認してください。

自動選択ですべての既存接続が移行するわけではない

プロキシグループがノードAからノードBへ切り替わると、通常は新しい接続から新しい選択が使われます。すでに確立されたTCP接続や長時間接続は、すぐに移行するとは限りません。再接続するまで、再生中の動画、SSHセッション、ダウンロードが古い接続を使い続けることがあります。テスト値が下がったのに現在のページが重い場合は、シークレットウィンドウを新しく開くか、該当する接続を完全に終了してから再テストしてください。

4つの指標でノード品質を判断する

信頼できる判断には、少なくとも遅延分布、パケットロスと失敗率、継続スループット、出口と宛先サイトの位置という4種類の情報が必要です。テスト中はローカルネットワークを固定し、システム更新とクラウドストレージの同期を一時停止して、Wi-Fiと有線を同時に切り替えないようにします。候補ノードごとに5〜10分観察するほうが、ボタンを10回連続で押して最小値を選ぶより有効です。

第1グループ：中央値と高遅延域を記録する

平均値は、少数の極端な結果によって高くも低くもなります。20〜100回の結果を記録し、中央値、最大値、95パーセンタイルを重点的に確認しましょう。統計ツールがなければ、結果が一定範囲に集中しているかだけでも確認してください。次の2グループは平均値が近くても、安定性はまったく異なります。

ノード	代表的な結果	判断
ノードA	78、81、79、84、690 ms	基礎遅延は低いが、明確なスパイクがある
ノードB	142、149、151、146、155 ms	遅延はやや高いが、変動幅が小さい

第2グループ：プロキシリクエストの失敗率を確認する

システムの ping コマンドは、ノード入口のファイアウォールで無効化されている場合があります。また、サーバー入口までしか測れず、実際のプロキシ通信が出口まで通る経路を反映しないこともあります。そのため、ICMPのパケットロスは補助指標にとどめてください。Clashの利用状況に近い方法は、ローカルプロキシポートを通して同じテストアドレスへ繰り返しリクエストすることです。

curl -x http://127.0.0.1:7890 \
  -o /dev/null -s \
  -w "connect=%{time_connect} total=%{time_total} code=%{http_code}\n" \
  https://www.gstatic.com/generate_204

例では、ClashのHTTPまたはMixedポートを 7890 とします。クライアントが 7897 や別のポートを使用している場合は、「設定」→「パラメータ設定」に表示される実際のポートを使ってください。連続実行時は total の変動、HTTPステータスコード、タイムアウトの有無を確認します。同じノードを50回テストして2回タイムアウトした場合、失敗率は4%です。このようなノードは、継続的で安定した接続を必要とする用途のデフォルトには向きません。

第3グループ：時間帯ごとに継続スループットを測る

信頼でき、容量にも余裕のある固定ファイルを選び、30〜60秒間継続ダウンロードします。開始直後の瞬間的なピークではなく、安定した時間帯の速度を記録してください。平日の午前と、20:00〜23:00の混雑時間帯にそれぞれ測定します。日中は70 Mbpsでも夜間に8 Mbpsまで落ちるノードより、常に35 Mbpsを維持するノードのほうが、長期的なデフォルトに適しています。

速度測定はサブスクの通信量を実際に消費し、ノードの負荷も増やします。数GBのファイルを頻繁にダウンロードする必要はありません。Web閲覧や1080p動画を確認するなら、100〜300 MBのサンプルで明らかな速度制限を見つけられることが多いでしょう。4K高ビットレート動画、システムイメージ、大規模リポジトリの取得では、より長い安定転送の観察が必要です。

第4グループ：入口、出口、宛先の位置を確認する

ノード名にある「香港」「日本」が、入口サーバー、実際の出口、完全な経路のすべてを示しているとは限りません。中継ノードは国内の入口へ接続した後、専用線で海外の出口へ転送することがあります。一方、インターネットへ直接接続するノードでは、端末から海外サーバーへ直接接続する場合があります。両者のURL Test値が似ていても、混雑時間帯の安定性や帯域上限は異なる可能性があります。

宛先サイトの位置も選択結果に影響します。東京のサービスへアクセスするなら、日本の出口は通常経路が短くなります。ヨーロッパにある自前サーバーへアクセスするなら、ヨーロッパの出口を選ぶことで、出口から宛先サイトまでの大陸間転送を減らせる場合があります。「ローカルから近い順」だけで並べ、出口からWebサイトまでの後半経路を無視すると、テスト遅延は低いのに実際の処理が遅い結果になりやすいでしょう。

TUNモードで数値は正常なのにアプリが重い場合の確認手順

Clashの遅延テストはカーネルが能動的に実行するため、カーネルがノード経由でテストアドレスへアクセスできることしか証明しません。アプリの通信が同じプロキシグループを通るかどうかは、システムプロキシ、TUNによる取り込み、DNS、ルールの適用、アプリ自身のプロキシ対応にも左右されます。テストが80 msでも、ブラウザが直接接続していたり、別のプロキシグループを使っていたりすることはあり、両者は矛盾しません。

現在のモードを確認。クライアントがルールモード、グローバルモード、ダイレクトモードのどれになっているか確認します。ルールモードでは接続一覧を開き、対象ドメインが想定したルールとプロキシグループに一致しているか確認してください。
システムプロキシを確認。Clash Verge Rev 2.3.xのような画面では、「設定」→「システム設定」またはホーム画面の「システムプロキシ」スイッチを確認します。カーネルだけを起動してシステムプロキシを有効にしていない場合、システムプロキシ設定に従うアプリでも自動的にClashを経由しません。
TUNの状態を確認。システムプロキシに従わないアプリを取り込む必要がある場合にTUNを有効にします。起動直後に停止するなら、ノード遅延を何度もテストするのではなく、サービスのインストール、管理者権限、仮想ネットワークアダプターの競合を確認してください。
DNSを確認。ドメインの名前解決失敗、Fake-IPマッピングの異常、LAN内DNSの乗っ取りは、Webページが長時間待機する原因になります。既知のIPアドレスへ直接アクセスしても、DNS問題を完全には排除できません。HTTPSでは正しいドメイン名と証明書が必要だからです。
接続の詳細を確認。接続一覧には、対象ホスト、ルール、プロキシチェーン、アップロード・ダウンロードのバイト数が表示されるはずです。テストしたノードと実際の接続で使われるノードが異なる場合は、まずルールまたはプロキシグループの選択を修正してください。
接続を再確立する。ブラウザのタブを閉じ、ダウンロードを一時停止してから開き直します。HTTP/2、HTTP/3、WebSocketの長時間接続は、切り替え前の経路を使い続けることがあります。

利用シーン別に優先すべき指標

利用シーン	優先指標	補助指標
一般的なWeb閲覧と検索	中央値の遅延、失敗率、DNSの安定性	ピーク帯域幅
動画と大容量ファイルのダウンロード	継続スループット、混雑時間帯の安定性	数十ミリ秒の遅延差
音声通話、リモートデスクトップ	ジッター、パケットロス、高遅延域	大容量ファイルのダウンロード速度
Git、パッケージ、イメージの取得	宛先サイトまでの経路、同時接続の安定性	1回のURL Testにおける最小値
長期的な自動選択	失敗率、許容差、切り替え頻度	近接ノード間のわずかな順位変動

日常的なWeb閲覧では、80 msと110 msの差より、失敗率0%と3%の差のほうが重要なことが多いでしょう。高画質動画では、70 msでも6 Mbpsしか維持できないノードより、150 msでも安定して60 Mbpsを提供するノードのほうが適しています。リモートデスクトップでは、平均90 msでも頻繁に500 msへ跳ねる接続は、安定した140 msより操作しにくくなります。

より合理的なノード選びでは、まずタイムアウトと高い失敗率のノードを除外し、次に利用シーンごとの安定性とスループットを比較し、最後に遅延で細かく順位付けします。url-test は品質が近いノード群から自動選択するのに適していますが、経路品質全体の評価を代替するものではありません。80 msと表示されたら、それは1回のテストサンプルであり、ノード性能の総合点ではないと考えてください。