Clashのノード遅延測定の仕組み｜URL Testと実際の通信速度が一致しない理由

1. URL Testが測るのはリクエストの応答時間。ダウンロード速度ではない

Clash Nyanpasuなどのクライアントでノードの横に表示されるミリ秒の数値は、通常、コアのURL Testによるものです。指定したプロキシ経由でテストURLにアクセスし、確認が完了するまでの時間を記録します。ノードサーバーに通常のICMP Pingを送るテストでも、大容量ファイルをダウンロードして転送速度を算出するテストでもありません。「このノードは速いか」を判断する前に、画面に表示されているのがどの種類の測定結果か確認しましょう。

一般的な軽量HTTPSチェックでは、プロキシへの接続、プロキシプロトコルのハンドシェイク、接続先との通信、TLSハンドシェイク、HTTPレスポンスなどが処理されます。DNS解決をどちら側で行うか、接続を再利用できるか、コアのバージョンや遅延の計測設定なども最終的な数値に影響します。そのため、画面上の180 msを単純に「自分の端末からノードサーバーまでの往復時間」と捉えることはできません。

まず単位を確認：msは時間、MB/sやMbpsは転送速度を表します。短いリクエストで送受信するデータはわずかなので、その結果から回線が継続的に処理できる通信量は分かりません。

「速度測定」の3種類が分かること

サーバーでICMPが禁止されていても、プロキシサービスは正常に使える場合があります。逆に、Pingに応答してもプロキシポートが利用できるとは限りません。Clashのノードを調べるときは、Pingだけを見るよりURL Testのほうがプロキシ経由の通信状況を把握できます。ただし、実際の用途に応じたテストも必要です。

2. 低遅延なのにダウンロードが遅い理由：ハンドシェイク・帯域幅・混雑の違い

遅延は通信の応答を待つ時間、帯域幅は単位時間あたりに転送できるデータ量を表します。小さなテストへの応答はヘッダー程度で済むため、回線の帯域幅が低くてもすぐ返ってくることがあります。一方、数百MBのファイルをダウンロードすると、回線の速度制限、共有回線の混雑、接続先サーバーの制限が結果に表れます。

例で見る測定結果の違い

以下は判断方法を説明するための例であり、特定のサービスで実測した結果や速度を保証するものではありません。同じ端末、同じテストURL、同じ時間帯で測定したとします。

大容量ファイルのダウンロードが目的なら、ノードBを試す価値があります。短いリクエストが中心なら、負荷が低いときはノードAのほうが応答が速い可能性がありますが、最大所要時間を見ると安定性の確認も必要です。1.2 MB/sは約9.6 Mbps、9.0 MB/sは約72 Mbpsです。比較する前に、バイトとビットの単位をそろえましょう。

• Webページの初回表示：DNS、接続時のハンドシェイク、最初のバイトが届くまでの時間、複数のリソース取得に左右されるため、遅延が重要です。
• 大容量ファイルのダウンロード：継続的なスループット、パケットロス後の再送、サーバー側の制限が重要です。
• 動画再生：十分かつ安定したスループットが必要です。一時的に速度が出ても、バッファリングが途切れないとは限りません。
• リアルタイム通信：平均遅延に加え、ジッター、パケットロス、実際に使うUDP経路も確認しましょう。

夜間の混雑時には遅延が増え、スループットも低下することがよくあります。ただし、継続的に通信して初めて問題が表れる場合もあります。回線が空いているときに一度測った80 msでは、その後10分間の負荷までは分かりません。

3. テストURLとタイムアウトで順位が変わる理由

テストURLによって「どこまで測るか」が決まる

URL Testはプロキシの入口への接続だけで完了するわけではなく、プロキシの出口からテスト先までの経路も測定に含まれます。テスト用ドメインを変えると、接続先のCDN、DNSの解決結果、TLSの動作、出口からのルーティングが変わる可能性があります。あるノードからテストサイトまで近くても、コードホスティングサービス、動画配信サービス、社内システムにも近いとは限りません。

軽量テスト用URLでは、レスポンス内容が結果に影響しにくいようHTTP 204を返すものがよく使われます。たとえば https://www.gstatic.com/generate_204 はテスト先の候補になりますが、すべての出口やネットワーク環境で使えるとは限りません。ログインやCAPTCHAが必要なページ、頻繁にリダイレクトされるページは、汎用のテスト先にしないでください。

• ノードを比較するときは、URL・プロトコル・タイムアウトをそろえる。
• 特定のWebサイトを調べるときは、そのサイトへの実際のリクエストもテストし、汎用テストの数値だけで判断しない。
• 複数ノードのテストが一斉に失敗したら、まずテストサイト自体にアクセスできるか確認する。
• 応答しやすいURLに変更して、実際のサービスで起きている問題を「ノードは正常」と見せかけない。

タイムアウトは待機時間の上限であり、ノードの遅延値ではない

たとえば、テストの待機上限が3000 msと10000 msの場合、チェック完了まで4200 msかかるノードは前者では失敗し、後者では有効な結果が返る可能性があります。待機時間を延ばしても、結果が返る可能性が高まるだけで回線が速くなるわけではありません。クライアントに「タイムアウト」と表示されても、ノードが永久に使えなくなったとは限りません。今回のテストが設定された条件内で完了しなかったことを示しています。

失敗の原因には、DNS解決、TLS、接続拒否、テスト先の制限なども考えられるため、コアのログと照らし合わせて切り分けましょう。クライアントの手動テスト、プロキシグループのヘルスチェック、providerのヘルスチェックでは、異なる設定が使われることがあります。画面上の設定を1つ変更すればすべてのテストに反映されるとは限りません。

4. mihomoのurl-testプロキシグループを設定する

url-testプロキシグループは、テスト結果に基づいて候補のプロキシを自動選択します。「遅延の低さを優先する」処理をコアに任せたい場合に便利です。以下は設定例です。完全な設定ファイルのproxiesに、「香港入口A」と「日本入口B」という名前のプロキシがすでに定義されているものとします。まず設定をバックアップし、クライアントが対応する設定編集またはオーバーライド機能で統合してください。この断片を完全なサブスクリプション設定として直接読み込むことはできません。

proxy-groups:
  - name: 遅延自動選択
    type: url-test
    proxies:
      - 香港入口A
      - 日本入口B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300：チェック間隔は300秒です。300ミリ秒ではありません。
• tolerance: 50：切り替えの許容差は50ミリ秒です。わずかな遅延差による頻繁な切り替えを抑える設定で、タイムアウト値ではありません。
• lazy: true：グループを使用していない間は、定期的なテストを止められます。その場合、バックグラウンドで常に最新の測定値が保持されるわけではありません。
• proxies：定義済みのプロキシ名またはプロキシグループ名を指定します。設定内の名前と正確に一致させてください。

このグループは、ルールまたは上位のプロキシグループから選択されたときに限り、該当する接続の出口選択に使われます。グループを作成しただけで参照していなければ、ブラウザーの通信が自動的にそのグループ経由になることはありません。すでに始まっているダウンロードや長時間接続は、通常、ポリシーを変更しても別のノードへシームレスに移行しません。新しい接続を作成してから確認してください。

自動選択は帯域幅の順位付けではありません：url-testはテスト時の遅延を基準に経路を選択します。大容量ファイルを自動でダウンロードして、各ノードの継続的な帯域幅を測定する機能ではありません。ダウンロード速度を比較する場合は、手動選択グループでノードを固定して個別に測定してください。

候補ノードがproxy-providers由来の場合は、providerのhealth-check設定も確認してください。プロキシグループのテストとは役割も設定も異なります。サブスクリプションの更新で直接編集した内容が上書きされることがあります。設定を維持するには、現在のクライアントが対応するオーバーライド機能を使い、読み込み後に実際に適用された設定を確認してください。

5. 条件をそろえて再現可能なノード比較を行う

1. ネットワーク環境をそろえる。同じ端末を使い、同じWi-Fiまたは有線接続で測定します。端末の帯域幅が使われないよう、システム更新、クラウドストレージの同期、大容量ダウンロードを一時停止してください。
2. 実際の通信経路を確認する。接続一覧で、対象ドメインに適用されたルールと、最終的に選択されたプロキシを確認します。ルールモードではテストサイトが直接接続される一方、遅延テストは候補ノード経由になることがあります。この2つの結果をそのまま比較することはできません。
3. 候補ノードを固定する。測定中に自動選択グループが切り替わらないよう、一時的に手動選択を使います。ノードを切り替えるたびに新しい通信を開始し、必要に応じて進行中のダウンロードを停止して再開してください。
4. 軽量テストを繰り返す。各ノードを約5秒間隔で5回測定し、成功回数、中央値、最大値を記録します。最も速かった1回だけを採用しないでください。
5. 実際の用途でも測定する。同じダウンロードURLを使い、単一接続で約30秒間転送して、速度が安定したときの値を確認します。複数接続での結果は別に記録し、単一接続の結果と混ぜないでください。
6. 時間帯を変えて再測定する。日中と夜間の混雑時にそれぞれ測定します。夜間だけ大きく速度が落ちる場合は、クライアントの再インストールを繰り返すより、回線負荷や経路の混雑を疑いましょう。

curlで指定したローカルHTTPプロキシをテストする

以下のコマンドは、設定のmixed-portが7890で、ローカルからの接続が許可され、別途プロキシ認証が設定されていないことを前提としています。ポート番号が異なる場合は、現在適用されている設定を確認してください。Windows PowerShellでは、同名のコマンドエイリアスによる引数の解釈違いを避けるため、curl.exeを使用できます。

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --connect-timeout 5 --max-time 10 --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

上記の出力先の指定はmacOSとLinux向けです。Windowsでは/dev/nullをNULに置き換えてください。--connect-timeout 5は接続時の待機上限、--max-time 10はリクエスト全体の最大時間を10秒に設定します。時間の単位は秒です。このコマンドで測定できるのは、curlがローカルプロキシ経由でリクエストしたときの挙動であり、コアのURL Testに表示されるミリ秒と完全に一致するとは限りません。

測定結果は接続一覧とあわせて確認してください。ローカルHTTPプロキシがリクエストを受け取った後も、コアは現在のモードとルールに基づいて出口を選びます。--proxyを指定しただけでは、比較対象として選んだリモートノードが使われているとは限りません。

6. よくあるトラブル：タイムアウトから動画の再生停止まで

すべてのノードが突然タイムアウトする

まず、現在のネットワークから基本的なサービスにアクセスできることを確認します。次に、サブスクリプションにあるサーバーアドレスを名前解決できるか、テスト先にアクセスできるか、ログに接続拒否やTLSエラーが出ていないかを調べます。別の安定した軽量HTTPS URLでも確認できます。一度にすべてのノードで失敗しても、全ノードが同時に使えなくなったとは限りません。すぐに設定をすべて削除するのは避けましょう。

60 msと表示されるのにWebページの表示に数秒かかる

まずWebページの通信が実際にそのノードを経由しているかを確認し、次にブラウザーが古い接続を再利用していないか確認します。Webページは多数の外部リソースを読み込むことがあり、特定ドメインの名前解決やリクエストの滞留だけでページ全体の表示が遅くなる場合があります。ブラウザーの開発者ツールにあるネットワークパネルを使えば、最初のバイトを待っている時間とコンテンツのダウンロード時間を区別でき、ハンドシェイク・サーバーの応答・データ転送のどこに問題があるかを調べられます。

速度テストは正常なのに動画が途切れ続ける

Clashの遅延だけで判断せず、動画サービス側の通信速度やバッファ量などの統計を確認してください。メディアCDNとテストサイトでは経路が異なる場合があり、出口が特定のサービスに対して制限されている可能性もあります。HTTPテストは成功しても、実際の通信でUDPやQUICを使う場合は、その経路が利用できるか個別に確認してください。HTTPSのテスト1つで、すべてのプロトコルが使えるかは分かりません。

TUNを有効にすると数値や実際の通信が変わる

TUNで変わるのは通信を取り込む方法であり、回線の帯域幅が直接増えるわけではありません。切り替えの前後で、DNSの取り込み、ルーティング、ほかのプロキシソフトとの競合を確認してください。コア自身が行うノードテストと、アプリからTUN経由でコアに入る通信は、ローカルの経路が完全に同じとは限りません。実際の接続記録をもとに違いを判断しましょう。

7. ノード選びは、まず接続できるか、次に安定性、最後に用途を確認

普段使うノードは、3段階で判断できます。まず目的のサービスにアクセスできるかを確認し、次に繰り返し行ったテストの成功率とばらつきを比較します。最後にWeb閲覧、ダウンロード、動画など、用途に応じたテストを行います。150 msでも安定しているノードのほうが、50 msが出ることはあっても頻繁にタイムアウトするノードより、継続して使いやすい場合があります。

• Web閲覧・オフィス作業：連続したリクエストの所要時間と、実際のサービスを利用できる成功率を確認します。
• ダウンロード・更新：接続先と接続数をそろえ、継続的な速度を確認します。
• 動画・オンライン会議：バッファリング、ジッター、パケットロスに加え、使用するプロトコルでの実際の通信状況を確認します。

URL Testは「指定した接続先に対する、軽量な到達性・遅延チェック」と捉えれば、1つの数値に惑わされにくくなります。テストURL、タイムアウト、プロキシグループを変更する前に、元の条件と測定結果を記録してください。変更は一度に1項目に絞ることで、改善が設定変更によるものか、回線負荷がたまたま変わったためかを判断しやすくなります。