ノードの遅延値はどう測定される？URLテストの仕組みと実際の通信速度との違い

1. パネルのミリ秒表示はダウンロード速度ではない

Clashクライアントのプロキシ画面に表示される120 msは、通常、コアが指定ノード経由でURLへのプローブを実行した結果です。これは「このプロキシ経路で今回の小さなリクエストを完了するまでの時間」を示すもので、「1秒間にどれだけダウンロードできるか」を表す値ではありません。手動テスト、サブスクリプションのノードヘルスチェック、url-testによる自動選択では、測定先やタイムアウトの設定が異なる場合があります。比較する前に、まず測定元を確認しましょう。

遅延はミリ秒、スループットはMbpsやMB/sで表します。たとえばノードAの測定値が80 ms、ダウンロード速度が2 MB/sで、ノードBが160 ms、15 MB/sの場合、小さなリクエストを頻繁に行う用途にはA、大きなファイルのダウンロードにはBが向いている可能性があります。数値は指標の違いを説明するための例であり、実回線の測定結果や性能を保証するものではありません。

2. url-testのリクエストはどのように進むか

たとえば、プロキシ経由でhttps://www.gstatic.com/generate_204にアクセスする場合、処理の流れはクライアントのコア → プロキシサーバーまたはプロキシチェーン → 測定先サイト → レスポンスの返送となります。このURLは通常HTTP 204を返します。継続的なスループット測定に使うような大きなレスポンス本文がないため、軽量な疎通確認に適しています。

1. 接続先と接続情報を準備する。プロキシサーバーのアドレスを解決し、測定先のドメイン名またはアドレスを準備します。名前解決がローカルとリモートのどちらで行われるかは、プロトコル、DNS設定、接続経路によって異なります。
2. プロキシへの接続を確立する。ノードのプロトコルに応じて、TCP接続、TLS、WebSocket、またはUDPベースのトランスポートのハンドシェイクが行われる場合があります。プロトコルによって必要な処理は異なります。
3. 測定先への経路を確立する。プロキシの出口から測定先サイトへ接続します。HTTPSの測定先ではサイトとのTLSハンドシェイクも発生しますが、これはプロキシプロトコル自体で使われるTLSとは別の層です。
4. リクエストを送り、レスポンスを待つ。測定先サイトがリクエストを処理し、レスポンスがプロキシ経路を通って戻ると、コアが今回の測定結果を記録します。

この4段階を、すべてのバージョンで共通する固定の計測式と考えないでください。オリジナル版Clash、Clash Meta（現在のmihomo）、各バージョンでは、リクエスト方法、接続の再利用、再測定の有無、遅延の記録方法が異なる場合があります。DNSキャッシュによって実際の処理時間も変わります。特定の数値の理由を調べる場合は、クライアントとコアのバージョンを記録し、該当バージョンの実装を確認してください。

初回と2回目以降で結果が異なる理由

初回のアクセスでは、DNSクエリや新規接続が発生することがあります。その後の測定結果は、キャッシュ、セッション再開、サーバー負荷の変化などの影響を受ける場合があります。毎回接続を新しく作る設定でも、すべての状態が初期化されるわけではありません。初回が240 msで、その後が130 msだったとしても、この2つの数値だけでノードが「急に速くなった」とは判断できません。

3. 測定先によってノードの順位は変わる

URLテストで測定するのは、「ノードからこの測定先まで」の経路です。測定先サイトのCDN、地域ごとの振り分け、通信事業者間の接続状況は、実際に利用するサイトとは異なる場合があります。測定先への応答が速いノードでも、コードリポジトリ、動画CDN、業務サービスへの経路が遠回りになることがあります。その結果、パネルの遅延値が低いのにWebページの表示が遅い、という状況が起こり得ます。

測定先を変更するときは、レスポンスのステータスと現在のコアのヘルスチェック条件を確認してください。ログインが必要なページ、リダイレクトが続くページ、アクセス制限のあるページは、安定したプローブ先には向きません。expected-statusを設定している場合、想定と異なるステータスコードは失敗と判定されることがあります。測定に失敗するたびに回線断と決めつけないでください。

4. 同時接続、混雑、パケットロスで差が広がる理由

小さなリクエストでは持続的な帯域幅を測れない

レスポンス本文がほとんどないリクエストはすぐに完了します。そのため、長時間のダウンロードで生じる輻輳ウィンドウの拡大、帯域制限、継続的なパケットロス、共用出口の負荷までは確認できません。夜間の混雑時でも、100 ms前後で小さなリクエストを完了できる一方、高画質動画を安定して再生できないことがあります。

全ノードの同時テストも相互に影響する

一括テストでは、短時間に複数の接続が作成されます。複数のノードが同じ入口や中継回線、さらには同じ出口を共有していることもあります。その場合、ローカルのWi-Fi、ルーターの接続処理能力、通信事業者側の上り回線も測定に影響します。バックグラウンドで大容量ファイルをアップロードしていると、キューイングによって遅延が大幅に増えることがあります。

• 大容量ファイルのアップロード、クラウドストレージの同期、ほかの速度テストをいったん停止します。
• 一括測定の結果から候補を2～3個選び、それぞれ個別に再測定します。
• 候補ノードごとに最低5回測定し、中央値、最大値、失敗回数を記録します。
• 普段利用する時間帯に再測定します。日中の結果だけでは、夜間の混雑時の状態はわかりません。

たとえば5回の結果が90、92、95、98、800 msの場合、中央値は95 msですが、一度大きく跳ね上がった点にも注意が必要です。5回中2回失敗したなら、成功した3回の最小値だけで比較するべきではありません。Web操作やリアルタイム通信では、平均遅延だけでなく、ジッターやパケットロスも影響します。

5. url-testの自動選択は最速ダウンロードを意味しない

url-testは、プローブの結果に基づいて使用する出口を自動選択するプロキシグループです。大容量ファイルを自動でダウンロードして帯域幅を比較する機能ではなく、動画、会議、ソフトウェア更新といった現在の用途を判断するものでもありません。selectは手動選択、fallbackは優先順に利用可能な出口を探す方式です。これらのグループ名を、すべて「通信速度の最適化」と捉えないようにしましょう。

既存のurl-testグループを確認する際は、まず以下のフィールドを確認してください。例はフィールドの意味を示すもので、完全なサブスクリプション設定ではありません。設定ファイル全体を置き換える用途には使えません。使用できるフィールドは、実際に使うコアのバージョンに従ってください。

type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true

• interval: 300：定期チェックの間隔は300秒です。ページをリクエストするたびに再測定する設定ではありません。
• tolerance: 50：切り替えの許容差をミリ秒単位で設定し、小さな差による頻繁な切り替えを抑えます。タイムアウトの上限ではなく、帯域幅を向上させる設定でもありません。
• lazy: true：グループが使われていない間、定期チェックを省略できます。アクティブ状態の判定方法は、使用中のコアの実装によって異なります。そのため、パネルの結果が直近の測定値とは限りません。

サブスクリプションのproxy-providersに、独自のhealth-checkが設定されている場合もあります。プロキシプロバイダーのヘルスチェックとプロキシグループのテストは、単純に1対1で対応するものではありません。クライアントからの手動テストで別の設定が使われることもあります。調査時はプローブURL、結果の時刻、設定の出所をあわせて確認し、古い結果を現在の状態と取り違えないようにしてください。サブスクリプションの更新でローカル設定が上書きされる場合があるため、継続的に設定を調整する際はクライアントが対応するオーバーライド機能を使いましょう。

6. パネルの表示だけでなく実際のリクエストで確認する

まず出站モードをルールモードにし、プロキシ画面で候補ノードを固定します。そのうえで接続ログを確認し、対象リクエストに適用されたルール、プロキシグループ、最終的な出口を特定します。システムプロキシが適用されるのは、それを参照するアプリだけです。ターミナルのツールはシステムプロキシを使わない場合があります。TUNモードは通信を取り込む範囲を広げますが、回線の帯域幅を自動的に向上させるものではありません。

mixed-port経由で再現可能なテストを行う

以下のコマンドはmacOSのターミナル向けで、クライアントのmixed-portが7890であることを前提としています。最初にクライアントの設定画面でポートを確認してください。異なる場合は実際の値に変更します。-xはローカルのHTTPプロキシを明示し、ターミナルがシステムプロキシを使うかどうかに依存しません。--noproxy ""を指定すると、既存のプロキシ除外リストによって対象へ誤って直接接続するのを防げます。

curl --noproxy "" -x http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -sS -o /dev/null \
  -w 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

ここでのtime_connectは、主にローカルプロキシとのTCP接続にかかった時間です。time_appconnectは関連するセキュアなハンドシェイクが完了した時点までの累積時間、time_starttransferは最初の1バイトを受信するまでの累積時間です。それぞれが重複しない個別の区間ではなく、コアが記録するパネルの測定値とも直接対応しません。このテストは条件を固定してリクエストを再確認するためのもので、異なる実装が同じ数値を表示すべきだと証明するものではありません。

実際のサービスと持続的なスループットを測る

1. 普段利用するサイトを開き、複数のページを続けて表示して、初回表示、ログイン、リソースの読み込みが正常か確認します。
2. アクセス権があり、テストが許可された一定の配布元から同じファイルをダウンロードします。同時接続数をそろえ、30～60秒間の安定した速度を確認します。
3. 測定時刻、ネットワーク環境、ノード、失敗回数、安定した速度を記録します。ノードを切り替えて同じテストを繰り返し、複数のダウンロードテストを同時に実行しないでください。

単位換算に注意してください。8 Mbpsは約1 MB/sです。実際のアプリケーションのスループットはプロトコルのオーバーヘッドにも左右されます。速度測定サイトのMbps表示とブラウザーのダウンロード画面にあるMB/s表示は、数値をそのまま比較できません。

7. 遅延は低いのに接続できない場合の確認手順

1. 測定結果が最新か確認する。ノードを1つ選んで手動で再測定し、測定先と時刻を記録します。キャッシュされた結果や、定期チェックが実行されていない可能性を先に除外します。
2. リクエストがそのノードを経由しているか確認する。接続画面で適用されたルールと最終的な出口を確認します。ドメインによってはDIRECTに一致するか、別のプロキシグループに振り分けられている場合があります。
3. 通信の入口を確認する。システムプロキシが有効か、アプリが独自のプロキシを使用していないか確認します。TUNモードの場合は、権限、ルーティング、ほかのVPNの影響も確認してください。
4. 接続先とDNSを確認する。プローブに到達できても、実際のサービスのドメインに接続できるとは限りません。ログで名前解決の失敗、接続タイムアウト、TLSエラーを確認します。問題が起きるたびにDNS設定をすべて変更するのは避けましょう。
5. TCPとUDPを切り分ける。HTTPSの小さなリクエストに成功しても、UDP転送が使えるとは限りません。ゲーム、音声通話、QUICでは、プロトコルの対応状況と実際の経路を別途確認してください。