Clashノードの遅延テストの仕組み：パネルのミリ秒表示が実際の速度と一致しない理由

パネルのミリ秒表示は何を測定しているのか

Clash、Clash Meta（現在は mihomo と呼ばれることが多い）、およびそのコントロールAPIを利用するGUIクライアントでは、通常ノードのテスト結果がミリ秒単位で表示されます。この数値は「遅延」や「速度テスト」と呼ばれがちですが、従来のコマンドラインツールがサーバーに実行する ICMP Ping でも、ノードの利用可能な帯域幅を完全に測るテストでもありません。指定したプロキシノードを経由して HTTP リクエストを完了するまでの時間に近い指標です。

テストを開始すると、クライアントまたはコアは選択したプロキシノードを使ってテストURLへアクセスします。その過程には、プロキシサーバーへの接続、プロトコルのハンドシェイク、対象サイトへの出口接続、TLSハンドシェイク、HTTPリクエストの送信、レスポンスヘッダーの受信などが含まれる場合があります。コアのバージョン、テストURLのプロトコル、接続の再利用状況によって計測範囲は変わるため、同じノードをテストしてもクライアント間で表示結果が完全に一致するとは限りません。

一般的な遅延テストのリクエスト経路

1. クライアントが mihomo のコントロールAPIにノード遅延テストをリクエストします。
2. コアがローカルからノードサーバーへ接続します。たとえばサーバーのTCPまたはUDPリスニングポートです。
3. コアが Shadowsocks、Trojan、VLESS、Hysteria2 などのプロキシプロトコルに必要なハンドシェイクを完了します。
4. ノードサーバーが出口ネットワークからテストURLの対象サーバーへ接続します。
5. URLがHTTPSの場合は、TLSハンドシェイクを完了し、証明書も検証します。
6. 対象サーバーがHTTPレスポンスを返すと、コアが計測を停止し、ミリ秒単位の結果をクライアントへ通知します。

したがって、パネルに表示された80 msを「この端末からノードまでの物理的な往復遅延が80 ms」と直接解釈することはできません。ノードからテストサイトまでの経路やアプリケーション層のハンドシェイクも含まれる可能性があります。逆に、220 msと表示されてもダウンロード速度が遅いとは限りません。回線の帯域が十分で、パケットロスが少なく、輻輳制御が安定していれば、単一接続でも高いスループットを得られる場合があります。

システムのPingとの違い

ping は通常、ICMP Echoパケットを送信し、対象ホストから応答が返るまでの往復時間を測定します。多くのプロキシサーバーはICMPを制限したり、まったく応答しなかったりしますが、プロキシポートではTCPまたはUDP通信を正常に受け付ける場合があります。また、サーバーによってICMP用の経路や優先度が異なることもあります。そのため、コマンドラインのPingが45 msで、Clashパネルが110 msでも矛盾ではありません。

HTTP遅延テストは日常的なウェブリクエストに近いものの、あくまで小さなサンプルです。テストレスポンスは空、または非常に短い内容であることが多く、回線を継続的にはほとんど占有しません。「接続の確立にかかる時間」は分かりますが、接続後に毎秒どれだけデータを転送できるかは分かりません。

テストURLが結果を変える理由

テストURLは単なる飾りではありません。ノードの遅延値は、対象サイトの所在地、DNS解決、HTTP/HTTPSプロトコル、対象サーバーの負荷、CDNの振り分け、通信事業者の経路の影響を同時に受けます。同じノードでも、東京にあるテストサイトとフランクフルトにあるテストサイトへアクセスすれば、出口側の経路が大きく異なり、結果に数十から数百ミリ秒の差が出ることがあります。

204エンドポイントが疎通確認によく使われる理由

よく使われるURLには http://www.gstatic.com/generate_204、https://www.gstatic.com/generate_204、https://cp.cloudflare.com/generate_204 があります。これらのエンドポイントは正常時にHTTP 204を返し、本文を含まないため転送量が少なく、疎通や遅延を頻繁に確認する用途に適しています。

HTTP URLではTLSハンドシェイクを省くため、数値は接続と最初のHTTPレスポンスにかかる時間をより強く反映します。HTTPS URLでは証明書のネゴシエーションと暗号化ハンドシェイクが加わり、一般的なHTTPSサイトに近くなりますが、初回接続の数値は高くなることがあります。既存の接続が再利用されれば、2回目以降の結果が初回より低くなる場合もあります。ノードを比較する際は、URL、タイムアウト、クライアントのバージョン、ネットワーク環境を統一してください。

設定内のURLとタイムアウト値

mihomo の設定では、url-test 型のプロキシグループにテストURL、チェック間隔、許容差を指定できます。次の設定では、300秒ごとに候補ノードを確認します。新しいノードが現在のノードよりわずかに速いだけの場合、tolerance によって頻繁な切り替えを抑えられます。

proxy-groups:
  - 自動選択
    type: url-test
    proxies:
      - 東京-01
      - シンガポール-01
      - ロサンゼルス-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval: 300 はチェック間隔が300秒であることを示し、ユーザーのリクエストごとに再測定するという意味ではありません。tolerance: 80 の単位はミリ秒で、ノード切り替えに必要な差を確保します。lazy: true は、プロキシグループが使用されていないときに能動的なチェックを減らせることを示します。対応状況は、利用中の mihomo コアのバージョンとクライアントが生成する設定を確認してください。

コントロールAPIから単一ノードをテストすることもできます。一般的なリクエスト形式は GET /proxies/ノード名/delay で、timeout と url のクエリパラメータを付けます。GUIクライアントの「遅延をテスト」ボタンは、通常この処理を内部で実行しています。コントローラーが 127.0.0.1:9090 で待ち受けている場合、リクエストは信頼できるローカルプログラムだけがアクセスすべきです。LANからの操作を有効にする場合は、アクセスキーを設定し、ファイアウォールで許可する送信元も制限してください。

低遅延ノードでも遅くなる理由

低遅延とは、テスト時点で短いリクエストがすばやく返ったことを示すだけです。ウェブ閲覧、動画再生、クラウドストレージのダウンロード、オンライン会議には、スループット、ジッター、パケットロス、同時接続数、DNSの結果、対象サイトへの出口経路も関係します。どこか一つでもボトルネックがあれば、「パネルは60 msなのに実際の読み込みは遅い」という状況が起こります。

帯域制限と共有回線の混雑

ノードは数十バイトの204レスポンスをすばやく返せても、利用可能な帯域が5 Mbpsしかない場合があります。理論上、5 Mbpsは約0.625 MB/sです。500 MBのファイルをダウンロードするには、プロトコルのオーバーヘッドや速度変動を考慮しなくても少なくとも約800秒かかります。ノードの入口または出口を多数のユーザーが共有している場合、深夜には80 Mbps出ても、夜間は同じ経路が8 Mbpsまで低下することがあり、短い遅延テストにはその差がすぐ表れないことがあります。

帯域は単一接続の制限を受けることもあります。複数接続のダウンロードでは速く見えても、単一接続の動画再生では安定しない回線があります。反対に、総帯域は十分でも短時間のバースト後に速度制限がかかる回線もあります。評価では、ダウンロード開始直後のピークだけでなく、30〜60秒間の速度推移を記録してください。

パケットロス、ジッター、TCP再送

平均遅延だけでは、リクエストごとの変動は分かりません。5回連続の結果が62、65、61、64、180 msでも、平均値はそれほど高くありません。しかし5回目の急増は、ゲーム、音声通話、リモートデスクトップに影響します。回線に2%のパケットロスがあると、TCPはデータを再送し、輻輳ウィンドウを調整します。大容量ファイルのスループットは大幅に低下する可能性がありますが、204テストが一度正常に返れば、表示は緑色の数値のままです。

UDPを使う通信ではジッターがより表面化しやすくなります。ゲームやリアルタイム音声は通常、失われたパケットの再送を待たないため、20〜40 ms程度の遅延変動が続くだけでも、位置のワープ、音声の途切れ、入力反応の不安定さとして現れることがあります。この用途では、1回だけの最低値ではなく、一定時間内の最大遅延、ジッターの範囲、パケットロス率を確認してください。

ノードから対象サイトへの出口が異なる

テストURLの応答が速くても、すべてのサイトが同じ出口を通るとは限りません。ノードからCloudflare、Google、GitHub、動画配信CDN、企業向けサービスへの経路はそれぞれ異なる場合があります。シンガポールのノードが現地CDNへは45 msで接続できても、米国東部にある業務サーバーへのアクセスは230 msを超えることがあります。動画サイトでは、ノードの出口IPに応じて異なるCDNエッジへ割り当てられることもあり、実際の経路が遅延テストの経路と完全に異なる場合があります。

特定サイトの問題を調べるときは、全体の遅延テストを繰り返すのではなく、そのノードを通して対象サービスへ直接アクセスしてください。ブラウザーの開発者ツールにある「ネットワーク」パネルでは、DNS、接続、TLS、最初のバイトを待つ時間、コンテンツのダウンロードにかかった時間を確認できます。ファーストバイトまでが短く、コンテンツのダウンロードだけが遅いなら、問題はスループットに近いと考えられます。接続段階ですでに時間がかかっているなら、ハンドシェイク、経路、パケットロスを確認してください。

ローカル処理、DNS、TUNモード

TUNモードでは、より多くのシステム通信を引き受け、設定に従ってDNSの横取り、ルーティング判定、プロトコルスタック処理を行います。性能が正常な端末では、これらの処理が主なボトルネックになることは通常ありません。ただし、古い端末、高いCPU使用率、サードパーティ製セキュリティソフトのフィルタリング、複数の仮想NICが重なる環境では、実際の使用感が低下することがあります。この場合、パネルの遅延テストはコアが直接実行するため、ブラウザーやゲームとまったく同じシステム経路を通るとは限りません。

DNS設定によっても「ノードの遅延は正常なのにサイトが遅い」状態が起こります。たとえば、ドメインがノードの出口から遠いCDNアドレスに解決されると、接続自体は成功しても不適切な地域を迂回することがあります。fake-ip モードを使う場合は、実IPを必要とするLAN機器、企業ドメイン、特殊なアプリがフィルタールールに追加されていることも確認してください。DNS設定を変更した後は設定を再読み込みし、OSやブラウザーのDNSキャッシュを消去してから再テストします。

より信頼できるノード評価の方法

ノード選びは、接続性、応答、安定性、スループット、対象サービスの5つの観点に分けて考えます。まずパネルの遅延で、利用できないノードや明らかに遠回りするノードを除外し、その後に継続的なテストを行います。単純にミリ秒の小さい順に並べるより、実際の利用目的に合った判断ができます。

ステップ1：条件を固定して繰り返し測定する

1. 実行中のダウンロード、クラウドストレージの同期、システムアップデートを停止します。
2. 有線接続または同じWi-Fi帯域に固定し、テスト中にモバイル回線へ切り替えないでください。
3. すべての候補ノードで同じHTTPS 204 URLを使用します。
4. 3〜5秒間隔で5回連続テストし、最小値、最大値、失敗回数を記録します。
5. 普段使う時間帯と夜間のピーク時間帯にそれぞれテストし、少なくとも2組の結果を残します。

たとえば、ノードAの5回の結果が78、81、79、83、80 ms、ノードBが55、210、62、タイムアウト、58 msだったとします。ノードBは最低値こそ小さいものの、変動と失敗が目立ちます。ウェブがたまに速く開いても、タイムアウトのリスクはなくなりません。継続利用では、ノードAのほうが安定することが多いでしょう。

ステップ2：条件を管理したダウンロードテストを行う

提供元が安定していて、テストが許可されているHTTPSファイルを選び、30〜60秒間ダウンロードします。各ノードで同じファイル、同じダウンロードツール、近い時間帯を使い、テストサイト側の速度制限をノードの制限と誤認しないようにします。安定した区間の速度を記録し、開始直後1〜2秒のキャッシュによるピーク値は採用しません。

速度の単位も統一してください。クライアントに40 Mbpsと表示される場合、理論上は約5 MB/sです。1バイトは8ビットだからです。TCP、TLS、プロキシプロトコルのオーバーヘッドを考慮すると、実際のファイル書き込み速度は通常やや低くなります。システムモニターがMB/s、速度テストのページがMbpsを表示している場合、数字をそのまま比較すると8倍の誤差が生じます。

ステップ3：用途に合わせて対象サービスをテストする

• ウェブと開発：普段使う検索サイト、コードリポジトリ、パッケージレジストリ、ドキュメントサイトをテストし、ファーストビューと小さなファイルのリクエストを確認します。
• 動画：10分間連続再生し、画質の切り替え、バッファリングの回数、ピーク時間帯の安定性を確認します。
• リモートワーク：会議、リモートデスクトップ、社内サービスをテストし、ジッターと一時的な切断を重点的に記録します。
• ゲーム：対象サーバーの地域を優先してテストし、汎用的な204 URLだけでなく、UDPの利用可否、パケットロス、ゲーム内遅延を確認します。
• 大容量ファイル：単一接続と複数接続の速度を少なくとも60秒観察し、周期的に速度がゼロまで落ちないか確認します。

ステップ4：簡単なスコア表を作る

平均遅延、最大遅延、失敗回数、継続ダウンロード速度、対象サービスでの結果をそれぞれ記録します。ウェブ用途では遅延と安定性の比重を高くし、大容量ファイルのダウンロードではスループットを重視します。ゲームや通話では、平均ダウンロード速度よりパケットロス、ジッター、最大遅延が重要になることが多いでしょう。

遅延に異常がある場合の確認手順

すべてのノードが突然タイムアウトする場合は、まず端末側とサブスクリプションの状態を確認します。特定の地域または1つのノードだけが異常なら、サーバーや経路を疑います。最初からDNS、TUNのプロトコルスタック、ルールセットを次々に変更すると、問題の範囲がかえって分かりにくくなります。

すべてのノードがタイムアウトになる

1. 現在の設定が正常に読み込まれ、プロキシ一覧に選択可能なノードが存在することを確認します。
2. 現在のネットワークからテストURLを解決できるか確認し、別の信頼できるHTTPS 204 URLへの変更も試します。
3. システム時刻が正確であることを確認します。時刻のずれによってTLS証明書の検証に失敗することがあります。
4. クライアントのログを確認し、timeout、connection refused、TLS handshake、DNSエラーを重点的に探します。
5. システムプロキシまたはTUNモードをいったん無効にしてから再度有効にし、古いプロセスと仮想NICの状態が解放されていることを確認します。
6. サブスクリプションを更新し、ノードのアドレス、ポート、認証情報に変更がないか確認します。

多くのGUIクライアントには「設定」→「ログ」または「コア」→「ログ」という入口があります。メニュー名はクライアントのバージョンによって異なります。mihomo のログレベルを info にすれば、通常は接続段階を確認できます。ハンドシェイクの詳細を調べる必要がある場合だけ一時的に debug を使い、確認後は元に戻してください。ログが急速に増え続けるのを防げます。

特定のノードだけがタイムアウトする

まずプロキシグループで同じ地域の別ノードへ切り替えます。他のノードが正常なら、問題はそのノードのサーバー、ポート、プロトコルパラメータ、入口回線に集中している可能性があります。同じサーバーが複数のポートを提供している場合は個別にテストできますが、プロトコル、SNI、トランスポート層、テストURLを同時に変更しないでください。どの変更で接続が復旧したのか分からなくなります。

TrojanやTLSを使用するノードでは、サーバー名と証明書が正しく一致している必要があります。WebSocketノードではHostとパスにも依存します。Hysteria2、TUICなどのUDP方式は、ローカルネットワークやファイアウォールによるUDP制限の影響を受けることがあります。これらのパラメータはサブスクリプションが提供する設定を基準にし、遅延の数値を下げるためだけに削除しないでください。

遅延は正常なのにブラウザーが遅い

1. ブラウザーの通信が想定したプロキシグループを実際に通っているか確認します。クライアントの接続一覧で、対象ドメイン、ルール、出口ノードを確認できます。
2. ルールモードで対象ドメインが誤って DIRECT または別のプロキシグループへ振り分けられていないか確認します。
3. ブラウザーのDNSキャッシュを消去し、独自のプロキシ設定を使用している可能性のある拡張機能を無効にしてから、もう一度テストします。
4. システムプロキシとTUNモードを比較します。一方のモードだけで異常が起きる場合は、ポートの競合、仮想NIC、ルーティングテーブルを確認してください。
5. 汎用的な遅延URLではなく対象サイトをテストし、接続段階とコンテンツのダウンロード段階にそれぞれどれだけ時間がかかるかを確認します。

よく使われるローカルポートには、HTTPプロキシの 7890、SOCKS5プロキシの 7891、混合ポートの 7890、外部コントローラーの 9090 があります。ただし、サブスクリプションやクライアントによって値は異なります。ブラウザーの手動プロキシ、システムプロキシ、サードパーティ製ネットワークツールには、現在実際に使われているポートを指定してください。2つのプログラムが同じポートを同時に待ち受けると、コアの起動に失敗し、ログにアドレスがすでに使用中である旨が表示されることがあります。

遅延の数値から実用的な判断を導く

Clashパネルの遅延は、短いリクエストを測る指標です。端末からノードまでの経路、プロキシプロトコルの処理、ノードの出口からテストサイトまでの経路、さらにTLSやHTTPのやり取りを一つの数字にまとめています。接続性の確認や同じ条件での比較には便利ですが、帯域、ピーク時間帯の混雑、パケットロス、ジッター、対象サイトへの経路、ローカルのネットワークスタックまではカバーできません。

実際にノードを選ぶときは、1回だけの最低値を追うより、テスト条件をそろえることが重要です。5回連続で90 ms前後を保つノードは、50〜300 msの間を変動し、ときどきタイムアウトするノードより長期利用に向いていることが多いでしょう。ダウンロード用途では30〜60秒のスループットテストを加え、ゲームや会議ではパケットロスとジッターも確認して初めて、用途に合った判断ができます。

クライアントがURL-Testによる自動選択に対応している場合は、近い地域のノードを同じグループにまとめ、固定したテストURL、適切な300秒のチェック間隔、一定の許容差を設定できます。セッションを安定して維持する必要があるサービスでは、手動ノードまたはヘルスチェック付きのフェイルオーバー戦略を選ぶと、わずかな遅延変化による頻繁な切り替えを避けられます。