Clashの遅延テスト値はどう決まる？60msのノードでも動画が止まる理由

遅延の数値は実際に何を測っているのか

Clash、Clash Meta（mihomo）および各種GUIクライアントで遅延テストを実行すると、コアは通常、指定したプロキシノード経由でテストURLへアクセスし、リクエスト開始から有効な応答を受け取るまでの時間を記録します。よく使われるのはHTTP 204を返す軽量なURLで、例えば https://www.gstatic.com/generate_204 です。画面に表示される60msは、この短いリクエストが素早く完了したことを示すもので、ノードが毎秒どれだけデータを転送できるかを表しているわけではありません。

1回のテストには、プロキシ接続の確立、対象ドメインの名前解決、対象サーバーとのTCP接続、TLSハンドシェイク、HTTPリクエストとレスポンスが含まれる場合があります。どの段階まで測定するかは、コアのバージョン、プロトコル実装、接続の再利用状況、テストの入口によって異なります。クライアントによってはmihomoの外部コントロールAPIで単一ノードをテストします。一方、設定の url-test グループやプロバイダーのヘルスチェックは、コアが一定間隔で実行します。どちらもミリ秒単位の値を出力しますが、実行タイミングや接続状態が完全に同じとは限りません。

ネットワークの往復時間そのものではない

システムの ping は通常、ICMPエコーを使ってネットワーク層の往復時間を測定します。一方、Clashの遅延テストはプロキシプロトコルとHTTPリクエストの経路を通ります。ノードがICMPを禁止していてもHTTPSプロキシは正常に動作する場合があります。逆に、ICMPは低遅延でもプロキシサーバーの負荷が高く、認証や暗号化処理に時間がかかることもあります。そのため、コマンドラインの ping が35ms、クライアント表示が68msでも、矛盾ではありません。

端末からノードまで：家庭のブロードバンド、Wi-Fi、通信事業者の出口回線が最初の遅延を生みます。
プロキシのハンドシェイク：Trojan、VLESS、Shadowsocks、Hysteria2などは、通信方式とハンドシェイクの手順がそれぞれ異なります。
ノードからテストサイトまで：出口回線が後半のルーティングを決め、遠回りすれば数値は直接上昇します。
テストサイトの応答：対象サーバーの場所、負荷、速度制限、CDNの振り分けも結果に反映されます。
瞬間的な状態：パケットロスによる再送、CPUの割り込み、無線干渉は、特定の1回だけに影響することがあります。

60msのノードでも動画が止まる理由

動画再生には継続的なスループットが必要です。一般的なビットレートで見ると、1080p動画は安定して5～10Mbps、4Kコンテンツは20～40Mbpsほど必要になることがあり、ピーク時はさらに高くなります。遅延テストが取得するのはごく小さなレスポンスで、数十ミリ秒で終了します。そのため、数十MB転送した後にノードが速度制限、パケットロス、輻輳を起こすかどうかは分かりません。

帯域幅不足：最初の応答は速くても、その後のデータが流れない

あるノードがハンドシェイクを60msで完了しても、共有出口回線の空き帯域が混雑時間帯には2Mbpsしかないことがあります。数百KBだけを取得するWebページなら反応が速く見えますが、動画のバッファがデータを消費し続けると、再生速度にダウンロード速度が追いつかず、頻繁に停止します。これは典型的な「低遅延・低スループット」です。

逆に、遠距離にある180msのノードでも、安定して50Mbpsを提供できれば、再生開始時の応答は少し遅くても、バッファリング後は連続再生できる可能性があります。遅延は操作時の待ち時間に影響し、スループットは大容量ファイルや動画へ継続的にデータを送り込めるかを左右します。両者は別の指標です。

ジッターとパケットロス：平均値に隠れるピーク

5回連続の結果が58ms、61ms、63ms、420ms、タイムアウトだったとしても、クライアントによっては直近の値やフィルタリング後の値だけを表示します。ユーザーには61msと見えていても、実際の経路には明らかなジッターが存在する可能性があります。TCPはパケットロスが起きると再送し、輻輳ウィンドウを縮小します。UDPベースの通信も、回線品質が下がれば復旧処理の負荷が増えます。動画の分割データでは、速度が大きく上下する形で現れます。

ジッターを判断するときは最低値だけを見ないでください。10回連続で測定し、大半が55～70msで、1回だけ90msだったノードは、最低42msでも最高680ms、さらに2回タイムアウトするノードより、通常は制御しやすい状態です。ゲーム、音声通話、リモートデスクトップは特にピーク値の影響を受けます。

テストサイトと動画サイトは同じ出口経路を通るとは限らない

テストURLはノードに近いCDNへ接続できても、実際の動画サービスは別の地域へ振り分けられることがあります。ノードからテストサイトまでは6ホップでも、動画CDNへは大陸をまたいで遠回りするかもしれません。どちらも443番ポートを使っていても、自律システム、ピアリング、輻輳ポイントはまったく異なる場合があります。

地域制限の解除状況も、配信先のノードを変えます。米国と表示された出口がGoogleのテストURLには素早くアクセスできても、動画サービスからデータセンターネットワークと判定され、負荷の高いCDNへ割り当てられることがあります。一方、遅延が少し高い住宅回線の出口のほうが、適切なコンテンツ配信エッジを取得できる場合もあります。緑色の数値だけで並べ替えると、この違いを見落とします。

端末側の回線とクライアントモードも影響する

混雑したチャンネルの2.4GHz Wi-Fiでは再送が起こりやすく、ノードテストは正常でも、大容量通信になると問題が拡大します。
TUNモードでシステム通信を引き受けた後、MTU設定が適切でないと、フラグメント化やパケットロス、一部サイトの読み込み停止が起きることがあります。
ブラウザーがQUICを使っている一方で、現在のノードや回線のUDP対応が弱いと、動画接続が頻繁にフォールバックする可能性があります。
ルールによってテストURLはプロキシへ送られていても、動画ドメインは別のポリシーグループへ振り分けられている場合があります。その場合、2つの結果を直接比較できません。
端末のCPU使用率が高い、またはプレーヤーのハードウェアデコードが無効になっている場合も「動画がカクつく」状態になりますが、プロキシのダウンロード速度に異常があるとは限りません。

テストURL、キャッシュ、接続の再利用が結果を変える仕組み

テスト先は十分に小さく、明確な応答を返し、長期的にアクセスできる必要があります。204を返すURLは本文を含まないため、ダウンロード量が結果へ与える影響を抑えられます。ただし「影響を抑える」ことと「すべてのWebサイトを代表する」ことは別です。地域の異なるURLを選ぶと、同じノードでも数十～数百ミリ秒の差が出ることがあります。

同じテストURLで比較してこそ横並びの意味がある

ノードAをGoogleの204で測って70ms、ノードBを別の国内CDNで測って25msだったとしても、この2つの数値を直接順位付けすることはできません。対象サーバーが異なり、ルーティングの終点も違うからです。一括テストでは、すべての候補ノードに同じURLへアクセスさせ、同じタイムアウトを設定し、できるだけ同じ時間帯に実行してください。

主な用途が海外の開発サービスへのアクセスなら、安定したHTTPS 204 URLを1つ用意して初期選別に使えます。特定の動画プラットフォームが中心なら、実際の再生や、そのサービスの静的リソースを使ったテストも追加してください。ログインが必要なURL、大きなページを返すURL、頻繁にリダイレクトするURLはヘルスチェックに入れないでください。認証、リダイレクト、ページサイズがデータを乱すためです。

キャッシュで帯域幅が増えるわけではない

DNSキャッシュは名前解決を1回省略でき、TLSセッション再開はハンドシェイクの負荷を減らし、HTTP接続の再利用は再接続を省くことがあります。連続してテストを実行すると、2回目以降が1回目より低くなるのは珍しくありません。これは短い接続の準備コストが下がったことを示すだけで、ノードの出口回線が増強されたわけではありません。

クライアントやコアのバージョンによって、接続プール、ヘルスチェック、一括テストの処理方法が異なる場合があります。数十ノードを同時にテストすると、端末のスレッドスケジューリング、DNSクエリ、ルーターのNATテーブルも余分な変動を生みます。再確認が必要なら、2～5秒間隔で対象ノードを個別に測るほうが、全量テストを何度も実行するより参考になります。

タイムアウトは「無限の遅延」ではない

タイムアウトを5000msに設定して結果がtimeoutになった場合、リクエストが5秒以内に完了しなかったことしか分かりません。ノード障害、テストURLの遮断、DNS失敗、TLSエラー、一時的なパケットロスなどが原因として考えられます。まず既知のアクセス可能なテストURLへ切り替え、ノード自体がオフラインかどうかを判断してください。

mihomoのurl-testとヘルスチェックの読み方

url-test ポリシーグループは、グループ内のノードを定期的に検査し、その時点で遅延が低い利用可能なノードを選ぶ傾向があります。自動選択には適していますが、リアルタイムの帯域幅制御機能ではありません。ヘルスチェックで55msを返したノードが、その後の混雑時間帯に輻輳しても、動画速度が落ちたことを検知してコアが即座に切り替えるわけではありません。

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

proxy-providers:
  airport-main:
    type: http
    path: ./providers/airport-main.yaml
    url: https://example.net/subscription.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: true
      expected-status: 204

ここで interval: 300 は300秒ごとに検査する設定、timeout: 5000 は1回のヘルスチェックのタイムアウトを5000msにする設定です。tolerance: 50 は遅延が近いときの頻繁な切り替えを抑えます。現在のノードと候補ノードの差が数十ミリ秒程度なら、接続を維持したほうが切り替えを繰り返すより安定することが多いためです。lazy: true は、ポリシーグループが実際に使われていない間の不要な検査を減らします。

間隔を5秒まで短くしないでください。プロバイダーに80ノードある場合、5秒ごとに全ノードを探測すると、小さなリクエストを継続的に発生させ、サーバー側のレート制限に触れる可能性もあります。デスクトップでの日常利用なら、まず300秒から始めるのが無難です。回線状況の変化が激しい場合は60～120秒を試し、ログとリソース使用量を確認してください。

外部コントロールAPIで単一ノードを再確認する

mihomoでよく使われる外部コントロールの待受アドレスは 127.0.0.1:9090 です。アクセスキーを設定している場合は、指定したノードに対して遅延テストを実行できます。ノード名とテストURLは、あらかじめURLエンコードしてください。

curl -H "Authorization: Bearer local-secret" "http://127.0.0.1:9090/proxies/HK-A-01/delay?timeout=5000&url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204"

リモート確認のために9090番ポートを直接インターネットへ公開しないでください。デスクトップではループバックアドレスでの待受を維持します。LANから操作する必要がある場合はアクセスキーを設定し、システムファイアウォールで送信元アドレスを制限してください。プロキシポートも区別が必要です。一般的な 7890 はmixed-port、9090 はコントロールAPIで、役割が異なります。

実際の使い心地に近いノード判定方法

信頼できる選定手順は、最低値を探すことではなく、段階的に絞り込むことです。まず遅延と可用性で明らかな障害ノードを除外し、次に継続スループット、ジッター、目的のサイトを確認します。最後に倍率や地域も考慮して決定します。すべてのノードを限界まで使う必要はなく、実際の用途を判断できる指標をそろえれば十分です。

ステップ1：連続測定し、1回だけの最速値を追わない

同じHTTPSテストURLを固定し、タイムアウトを5000msに設定します。
候補ノードを5～10回連続で測定し、各回の間隔を2秒以上空けます。
最低値だけでなく、中央値、最高値、タイムアウト回数を記録します。
タイムアウトが連続する、数百ミリ秒単位で大きく変動する、または頻繁に切断されるノードを除外します。

例えば、ノードAの結果が75～88msに集中している一方、ノードBは最低48msでも、残りが60～530msに分散しているとします。Web閲覧ならどちらも使えるかもしれませんが、会議やゲームではAを優先します。中央値が安定し、極端な値が少ないほうが、偶然出た最低値より通常は有用です。

ステップ2：20～30秒の継続ダウンロードを行う

信頼できる速度テストサイトや大容量ファイルの配布元を選び、現在のポリシーグループ経由で20～30秒間ダウンロードします。一瞬のピーク値ではなく、速度が安定するかを確認してください。開始直後に18MB/sまで上がって5秒後に700KB/sへ落ちるノードは、瞬間的な帯域幅はあっても継続性能が不足しています。6MB/sで安定するノードのほうが、実際の高画質動画では扱いやすいことが多いです。

テストでは契約回線の通信量を消費します。倍率2.0のノードで500MBをダウンロードすると、課金上は1GBとして計算される場合があります。通信量に制限がある場合は、テスト時間を短くするかファイルサイズを小さくしてください。数十ノードすべてで完全な速度テストを行う必要はありません。

ステップ3：目的のサービスを直接測定する

動画：1080pまたは4Kコンテンツを5分間再生し、バッファリングの進み方と画質が自動的に下がるかを確認します。
開発：Gitの取得、パッケージインデックス、コンテナイメージを試し、対象リポジトリへの経路が正常か確認します。
ゲーム：実際のゲーム内遅延、パケットロス、混雑時間帯の安定性を確認し、Webの速度テストで代用しません。
会議：10分間通話を続け、音声の途切れと上り回線の品質を確認します。ダウンロードが速くても、アップロードが安定しているとは限りません。
リモートデスクトップ：ウィンドウを素早く動かして文字を入力し、ピーク帯域幅より操作時のジッターを重視します。

ステップ4：Clashのルールが同じノードを選んでいるか確認する

遅延テストの対象はノードまたはポリシーグループですが、実際のWebサイトの通信は先にルールへ照合されます。設定で DOMAIN-SUFFIX,example-video.com,MEDIA が MEDIA グループに一致し、手動テストでは PROXY グループを選んでいるなら、どれほど良い数値でも動画の結果は説明できません。

rules:
  - DOMAIN-SUFFIX,example-video.com,MEDIA
  - DOMAIN-SUFFIX,example-cdn.net,MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

切り分けるときはクライアントの接続画面を開き、再生を開始してからドメインで絞り込み、適用されたルール、ポリシーグループ、最終的なノードを確認します。一般的なデスクトップクライアントでは、通常「接続」→「ドメインを検索」→「接続の詳細を展開」という流れです。設定を変更する場合は「設定」→「現在の設定を編集」から進みます。クライアントによってメニュー名は多少異なりますが、確認すべき3項目は同じです。対象ドメイン、適用ルール、実際の出口です。

遅延に異常があるときの切り分け手順

まず問題を端末、ローカルネットワーク、ノード、対象サイトの4層に分けます。赤い数値を見ただけで、すぐにクライアントを再インストールしないでください。次の順番で確認すると、原因を素早く絞り込めます。

ローカルネットワークを確認：有線接続と5GHz Wi-Fiでそれぞれ測定し、無線の混雑を切り分けます。
テストURLを切り替え：元のURLがすべてタイムアウトする場合は、別の安定した204 URLで相互確認します。
DIRECTと比較：テストサイトへ直接アクセスしても遅いなら、ローカルの通信事業者または対象サイトに問題がある可能性があります。
コアのログを確認：timeout、DNS、TLS、connection resetなどのエラーを検索します。
システム時刻を確認：時刻がずれているとTLS証明書の検証に失敗し、ノードが利用できないように見えることがあります。
同時ダウンロードを一時停止：オンラインストレージ、システム更新、クラウド同期が上りまたは下り帯域を使い切っていないか確認します。
TUNパラメーターを確認：問題がTUNモードで発生した場合だけ、システムプロキシモードでも測定して結果を比較します。

すべてのノードが同時に80msから800msへ上昇したなら、まずローカルネットワークとサブスクリプションサービスの入口を確認します。特定地域だけに異常があるなら、その地域の回線または出口に問題があることが多いです。遅延は正常なのに特定サイトだけ遅い場合は、ルール、DNS、対象CDN、地域制限の解除状況を調べます。

まとめ：遅延を本来の位置づけで見る

Clashの遅延テストが答えるのに適しているのは、主に2つの問いです。今このノードからプロキシ経由でテストURLへアクセスできるか、そして短いリクエストの完了速度がどの程度か。可用性の確認や初回の順位付けには役立ちますが、帯域幅、動画画質、ゲームのパケットロス、混雑時間帯の安定性を単独で予測するものではありません。

60msと表示されたら、「短いリクエストへの応答が速い」と理解し、「ノードは必ず高速だ」とは考えないでください。複数回の測定における変動、20～30秒の継続スループット、目的のサービスでの実際の結果、ルールが選んだノードを確認します。遅延、帯域幅、ジッター、パケットロス、地域、倍率、プロトコルが組み合わさって使用感を決めるため、1つの数値だけで結論は出せません。

Clashノードを引き続き確認する

現在のプラットフォームに合ったクライアントをインストールし、ガイドに従ってサブスクリプションを取り込み、ルールの適用先とDNS設定を確認します。

ダウンロードページへガイドを見る