Clashの遅延テストの見方：測定値と実際の通信速度が異なる理由

まず遅延・スループット・安定性を区別する

まず遅延で明らかに使えないノードを除外し、速度は実際の用途で判断しましょう。Clashの一覧に表示される80 msは、通常、1回の接続テストにかかった時間です。ダウンロード帯域を示すものでも、動画を途切れず再生できる保証でもありません。ノードAが80 ms、ノードBが160 msでも、Aのダウンロード速度がBの2倍とは限りません。

「速さ」を3つの指標に分けると、原因を特定しやすくなります。Webページでは接続確立と最初の1バイトを受信するまでの時間、ファイルのダウンロードでは継続的なスループットを確認します。ビデオ会議やゲームでは、パケットロスやジッターに加え、実際に使われるUDP経路も重要です。1回のHTTPテストで分かるのは、その一部にすぎません。

たとえば、10 MiB/sでダウンロードを続ける速度は約83.9 Mbit/sです。MiBは1024²バイトとして計算します。通信事業者は接続帯域をMbit/sで表すことが多く、ダウンロードツールではMB/sやMiB/sが使われます。単位を確認してから数値を比べましょう。約8倍の単位差を回線障害と取り違えずに済みます。

Clashの遅延テストでリクエストが通る経路を理解する

まず、クライアントがどの種類のテストを行うか確認しましょう。多くのClashクライアントは、コアのURL遅延テストを利用します。指定したノード経由でテストURLにアクセスし、リクエストの完了時間を測定する方式です。ノードサーバーにICMP pingを送るだけのテストでも、大容量ファイルをダウンロードし続けるテストでもありません。

URLテストで行われる処理

1. コアがノードへの接続を準備し、必要に応じてノードサーバーのドメイン名を解決します。
2. プロキシサーバーに接続し、使用するプロキシプロトコルのハンドシェイクを行います。
3. プロキシ経由でテストサイトにアクセスします。HTTPSの場合はTLSハンドシェイクも行われます。
4. テストのレスポンスを受け取り、コアまたはクライアントが結果を表示します。

計測の開始・終了地点、接続の再利用方法、結果の表示方法は、コアやクライアントのバージョンによって異なります。クライアントに表示されたミリ秒の数値を、すべてWebページ全体の読み込み時間と解釈しないでください。テスト時のキャッシュや既存の接続、テスト先で追加の名前解決が必要かどうかも結果に影響します。

操作時は、まずクライアントの接続ログを開いてから対象のWebページを再読み込みします。対象ドメイン、適用ルール、プロキシグループの経路を確認し、出口を特定してから遅延を比較しましょう。TUNを有効にしても通信の取り込み方法が変わるだけで、ノードの帯域が増えたり、HTTPテストがUDPの性能テストになったりするわけではありません。

テストURLとタイムアウト条件を統一する

ノードを比較する前に、テストURL、ネットワーク環境、測定時刻をそろえましょう。よく使われるテストURLhttps://www.gstatic.com/generate_204は、非常に小さなHTTP 204レスポンスを返すため、短いリクエストの接続確認に適しています。レスポンスが小さいからこそ、大容量ファイルの転送能力は判断できません。

テストURLは、インターネット全体の速度を測る中立的な基準ではありません。テスト先の設置場所、CDNの振り分け、出口ネットワーク間の接続状況、アクセス制限によって結果は変わります。ある経路でこのURLへの応答が90 msでも、実際のサービスへのアクセスに300 msかかることはあり、矛盾ではありません。

条件をそろえて比較する

• 同じWi-Fiまたは有線ネットワークを使い、OSのアップデートやクラウドストレージの同期を一時停止します。
• 比較するノードを2つ選び、同じHTTPSテストURLを使います。
• 各ノードで約5秒間隔を空けて10回測定し、成功回数と遅延の中央値を記録します。
• 手動テストのタイムアウトを5000 msに統一します。クライアントで変更できない場合は、実際の既定値を記録してください。
• その後、実際に使うWebサイトでも確認します。テストURLを変えた結果を、元の測定記録に混ぜないでください。

タイムアウトは待機時間の上限であり、速度の目標値ではありません。timeoutと表示された場合、制限時間内にリクエストが完了しなかったか、接続・名前解決・TLSなどの処理でエラーが起きたことを示します。3000 msを10000 msに変更して数値が表示されても、長く待てば成功する場合があると分かるだけで、回線が速くなったわけではありません。

「すべてのノードがタイムアウトするのにWebページは開ける」場合は、まずログのエラー内容を確認し、テストURLと、クライアントが想定したコアを実際に使っているかを調べましょう。「テストは正常なのに特定のWebサイトが開けない」場合は、タイムアウトをすぐ延長するのではなく、そのサイトに適用されるルール、DNS、出口のアクセス制限、認証状態を確認してください。

遅延は低いのにダウンロードが遅い原因を調べる

帯域制限と共有回線の混雑を確認する

少量のデータを送るだけのテストなら、ノードの帯域が5 Mbit/sに制限されていても、遅延は良好に見えることがあります。しかし5 Mbit/sの理論上限は約0.625 MB/sで、プロトコルのオーバーヘッドを差し引くとさらに低くなります。この場合、遅延が十数ミリ秒低いノードを探し続けても、大容量ファイルのダウンロードは改善しにくいでしょう。

夕方の混雑時間帯にも同様の現象が起こります。共有出口は小さなリクエストにはすばやく応答できても、十分な帯域を継続して提供できないことがあります。同じファイルを09:00と21:00にダウンロードし、夜だけ継続速度が大幅に低下する一方で、ローカル回線の直接測定が正常なら、プロキシ経路や出口の混雑を優先して疑いましょう。

パケットロスと再送を確認する

少量のパケットロスは、個々の遅延測定には表れないことがあります。しかし、長時間の接続では再送が繰り返され、送信ウィンドウが縮小する原因になります。短いリクエストが10回連続で成功しても、長時間の転送が安定している証明にはなりません。ダウンロード速度が何度もゼロ近くまで落ちないか、接続が再確立されないか、OSのネットワークツールでTCP再送が増えていないかも確認しましょう。

中継ルーターがICMP応答を制限していると、経路の測定でパケットロスがあるように見える場合もあります。特定の中継地点へのpingだけで障害と判断せず、最終的な接続先、実際の通信の失敗、継続転送時の状態も確認してください。HTTPテストの失敗率を、回線の実際のパケットロス率として扱うことはできません。

接続先のサイト、端末、ローカルネットワークを確認する

• ダウンロード可能な別の大容量ファイルを試し、特定サイトの速度制限やCDNキャッシュの違いを切り分けます。
• 有線接続で再測定するか、ルーターの近くで測定してWi-Fiの干渉を切り分けます。
• タスクマネージャーやアクティビティモニタで、CPU使用率が継続して上限近くになっていないか確認します。
• ほかの端末からのアップロードを一時停止します。上り帯域を使い切ると、確認応答や操作リクエストもキューに入って遅れることがあります。

動画の再生開始が遅い場合、マニフェストの取得、セグメント配信サーバー、アカウントの地域設定、デコード処理などが関係していることもあります。クライアントに表示される遅延の数値だけでは、再生までの経路全体を把握できず、各処理が正常だとも判断できません。

手順を統一して実際の速度を記録する

まずノードを手動で1つ固定し、実際に使うサービスを開きます。測定中は自動選択グループによる出口の切り替えや、全ノードの同時速度テストを避けてください。ノードやルールを変更した場合は、古いページを閉じて新しい接続を作成します。すでに確立された接続は、新しい出口へすぐに切り替わるとは限りません。

curlでリクエストの所要時間を分けて確認する

以下のコマンドは、ローカルのHTTPまたはmixedプロキシポート127.0.0.1:7890を経由してサンプルサイトにアクセスします。まずクライアントで実際のポートを確認してください。7890以外の場合は、ローカルの設定に合わせて変更します。Windowsではcurl.exeを使うと、PowerShell環境によって同名コマンドの動作が異なる問題を避けられます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output response.html --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

この場合、time_connectが主に示すのはローカルプロキシへの接続時間であり、リモートノードの遅延ではありません。time_appconnectとtime_starttransferは、リクエスト開始からの累積時間です。それぞれ独立した所要時間として足し合わせることはできません。このコマンドは同じURLのリクエスト処理を比較するのに適していますが、帯域測定には使えません。

開始直後のピークではなく、継続ダウンロードを測る

1. アクセス権があり、約30秒間ダウンロードを続けられるサイズのファイルを選びます。
2. 単一接続か複数接続かを固定します。2つのノードを比べる際に条件を混在させないでください。
3. 開始から数秒間の変動を除き、速度が安定した区間の値と停止回数を記録します。
4. 各ノードで3回ずつ測定し、間隔を空けます。一時的なキャッシュの結果を長期的な性能と取り違えないようにしましょう。

以下は判断方法を示すための記録例です。本サイトでの実測値ではなく、特定ノードの品質を示すものでもありません。どちらも10回のテストを行い、ダウンロード方法とファイルは同じ条件にしています。

この条件では、大容量ファイルのダウンロードにはノードBが適しています。短いリクエストの応答を重視する場合は、実際のサイトで最初の1バイトを受信するまでの時間や失敗の有無も比較しましょう。すべての用途に共通する遅延の基準値はありません。

url-testによる自動選択でできること・できないこと

mihomoのurl-testプロキシグループを使う場合も、自動選択の基準は指定URLのテスト結果であり、帯域の順位ではありません。以下は既存の設定に追加する設定例です。ノード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秒ごとに確認する設定であり、テストのタイムアウトではありません。
• tolerance: 50は切り替えの許容範囲を設定し、数十ミリ秒の変動による頻繁なノード切り替えを抑えます。ダウンロード速度を制限する設定ではありません。
• lazy: trueを設定すると、使用していないグループの定期チェックを省略できます。未使用時も常に最新のテスト結果が保持されるわけではありません。

この設定例は、該当する項目に対応したmihomo環境で使用できます。クライアントのオーバーライド、サブスクリプションのマージ、画面上の設定によって、最終的な設定が変わる場合があります。実際に読み込まれた設定とログを確認してください。変更前に動作する設定を別途保存し、次回のサブスクリプション更新でローカルの変更が上書きされないようにしましょう。

ダウンロード中の出口を安定させたい場合は、手動選択グループでノードを固定できます。切り替え頻度を下げると動作を予測しやすくなりますが、すべての長時間接続が切断されない保証はありません。ノード自体の稼働状況、クライアントの接続処理、接続先サイトの状態も影響します。

症状に合わせて最終確認する

遅延は低いのにWebページが重い

まずブラウザーの接続が通るプロキシグループの経路を確認し、次に開発者ツールのネットワークパネルを調べます。DNS、接続、応答待ち、コンテンツのダウンロードの各段階を切り分けましょう。特定のリソースドメインだけ極端に遅い場合は、別のルールで異なる出口に送られていないか確認してください。トップページのドメインに対するテスト結果を、すべてのサブリソースに当てはめないでください。

遅延は高いのにダウンロードは速い

まずテスト先への経路が遠回りしていないか確認し、そのうえで継続的なスループットを調べます。長距離の経路は往復時間が長くなることがありますが、利用可能な帯域が十分でパケットロスが少なければ、ダウンロードは速いままです。大容量ファイルのダウンロードでは、ミリ秒の数値が大きいという理由だけで候補から外す必要はありません。

遅延が大きく変動し、ときどきタイムアウトする

同じ時間帯に、有線ネットワークとWi-Fiを比較し、アップロード中のタスクを一時停止してから10回テストします。ローカルネットワークが安定しているのに候補ノードがすべて同時に変動する場合は、回線を確認してください。1つのノードだけが不安定なら、そのプロキシ経路を調べます。テストサービス自体の異常を全ノードの障害と誤認しないよう、実際に使うサイトでも確認しましょう。

確認するのは3点です。実際に使う出口、短いリクエストの安定性、継続転送時の速度です。まずこの3点を測定してから、ノードの変更、ルールの調整、ローカルネットワークの確認を行いましょう。遅延の数値は原因の範囲を絞る目安です。最終的には実際の用途での動作を基準に選びます。