Clashの遅延テスト結果の見方：表示遅延と実際の使用感が異なる理由

Clashが表示する遅延は何を測定しているのか

クライアントのノード一覧に表示される45 ms、168 ms、timeoutなどの値は、通常ごく小さなHTTPまたはHTTPSリクエストに基づいています。Clashまたはmihomoはテストリクエストを指定されたプロキシノード経由で送信し、クライアントの既定値または設定ファイルで指定されたテスト先にアクセスして、有効な応答を受け取るまでの時間を記録します。この結果はノードが接続を確立できるか、ハンドシェイクが速いかを判断するのに適していますが、完全なダウンロード速度テストではありません。

HTTPSの遅延テストは、おおむねローカルアプリ、Clashの受け入れポート、プロキシノード、対象サイトという4つの段階を通ります。対象ドメインが未解決の場合は、先にDNSクエリも発生します。新しい接続では通常、プロキシサーバーとのTCP接続、プロキシプロトコルのハンドシェイク、テストサイトへのアクセス時のTCPおよびTLSハンドシェイクも含まれます。接続の再利用やDNSキャッシュの有無も、最終的な数値に影響します。

1. クライアントはテストリクエストを指定ノードに渡し、現在自動選択されている別のノードには渡しません。
2. ClashはShadowsocks、Trojan、VLESSなど、カーネルがサポートするプロトコルで接続を確立します。
3. プロキシノードは続けて、テストURLに対応するサーバーへ接続します。
4. 対象サーバーがHTTPレスポンスを返し、クライアントはそれを基に所要時間を算出します。

単純なネットワークPingではない

システムコマンド ping はICMPエコーを使用しますが、ClashのURL Testは通常、実際のHTTPまたはHTTPSリクエストを使用します。サーバーによってはICMPを制限しながら、プロキシプロトコルやWebトラフィックを許可している場合があります。逆に、Pingは低くてもプロキシのハンドシェイクに時間がかかることもあります。そのため、サーバーのPing値をClashに表示される遅延と直接同一視することはできません。

同じノードが2つのクライアントで70 msと130 msと表示されても、必ずしもカーネルの異常とは限りません。まずテストURL、タイムアウト時間、HTTPSの使用有無、接続の再利用、テスト時のローカルネットワークが同じかを確認してください。スマートフォンが5G、パソコンが有線ブロードバンドなら、2つの結果をそのまま比較するのは適切ではありません。

URL Testの経路と自動選択の仕組み

url-test はClashのプロキシグループの種類の1つです。グループ内のノードを定期的にテストし、その時点で遅延が低く利用可能なノードを選択します。一般的な設定では、204ステータスを素早く返すURLを使い、レスポンス本文が測定に与える影響を抑えます。以下は読みやすい設定例です。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300 はテスト間隔が300秒、つまり5分であることを示します。間隔は短ければよいとは限りません。10秒にすると余分な接続やログが増え、一時的な揺らぎでノードが頻繁に切り替わる原因にもなります。普段使いなら300～600秒から始め、モバイル回線の変動が大きい場合に適宜短縮するとよいでしょう。

tolerance: 50 は切り替えの感度を制御します。現在のノードが120 ms、別のノードが92 msなら差は28 msなので、通常はすぐに切り替える必要はありません。新しいノードが60 msまで下がり、差が60 msになれば、切り替える実益が大きくなります。許容値を設けることで、80 ms、95 ms、110 msの間を行き来して接続が中断されるのを抑えられます。

テストURLによって結果は変わる

テスト先がプロキシの出口から遠いほど、結果は通常高くなります。東京の出口から東京付近のテストサーバーへアクセスすれば35 ms程度でも、欧州の対象へアクセスすると220 msを超えることがあります。普段よく使うサービスがあるなら、安定していてレスポンス本文が小さく、経路も代表的なHTTPSアドレスを選ぶとよいでしょう。ただし、そのアドレスが長期的に正常アクセスできることを確認してください。

• テスト先の安定性：対象サイトのレート制限や障害により、すべてのノードが同時にタイムアウトすることがあります。
• HTTPとHTTPS：HTTPSはTLS接続のコストも含むため、普段のWebアクセスに近い測定になります。
• DNSの解決経路：nameserver、fake-ip、redir-hostの設定が異なると、初回テストの所要時間も変わることがあります。
• 出口の場所：同じプロキシノードでも、地域の異なる対象へアクセスすると、経路の長さや混雑度が変わります。
• キャッシュの状態：初回テストにはDNSやハンドシェイクのコストが含まれ、直後の2回目は低い値になることがあります。

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

動画再生には継続的なスループットが必要ですが、遅延テストで送受信するデータはごくわずかです。あるノードが45 msで小さなリクエストを完了できても、継続的な帯域幅が2 Mbpsしかないことがあります。再生ビットレートが約15 Mbpsの4K動画では、バッファの消費速度がダウンロード速度を明らかに上回り、頻繁に停止します。一方、180 msでも80 Mbpsを安定して出せるノードなら、ページの初回表示は少し遅くても、大容量ファイルや動画には向いている可能性があります。

遅延・帯域幅・パケットロス・ジッターの4指標

たとえば、あるノードを5回連続で測定して48、52、51、49、55 msだった場合、平均は約51 msで変動も小さいと判断できます。別のノードが35、280、62、410、44 msなら、最低値は35 msでもジッターは非常に大きくなります。ノード一覧が直近の35 msだけを表示すると、その後のリクエストで頻繁に遅くなる問題を見落としてしまいます。

パケットロスは特にTCP転送で顕著に現れます。TCPはデータが届かなかったことを検出すると再送し、輻輳ウィンドウを縮小することがあります。基本の往復遅延が60 msしかなくても、2～5%のパケットロスが継続すれば、ダウンロード速度は鋸歯状に変動します。UDPの音声やゲーム通信は通常、完全な再送を待たないため、音声の欠落、位置情報の遅延、画面の突然のジャンプとして現れます。

サーバー負荷と時間帯も重要

プロキシサーバーのCPU、メモリ、接続数、上流帯域幅が上限に近づくと、小さな検査リクエストは素早く返っても、大容量通信は制限されます。20:00～23:00の夜間はネットワーク間の混雑もよく発生します。昼間は70 msでも、夜間には90～400 msの間で変動することがあります。午前中に1回測定しただけでは、夜間の実際の使用感を判断できません。

サービス側が出口アドレスごとに行う振り分けも速度を変えます。同じノードからテストURLへは素早くアクセスできても、動画サービスでは遠いCDNへ割り当てられることがあります。出口によっては対象サイトの速度制限にかかる場合もあります。この場合、問題はプロキシ出口から対象サービスまでの区間にあり、端末からプロキシサーバーまでの区間とは限りません。

再現可能な手順で実際の使用感を判断する

信頼性の高い判断方法は、絶対的に最も低い数値を探すことではありません。同じ端末、同じネットワーク、同じ時間帯で複数回測定し、結果を比較します。テスト前にはクラウドストレージの同期、システム更新、大容量ファイルのダウンロードを一時停止し、バックグラウンド通信で帯域幅を使い切らないようにしてください。スマートフォンで測定する場合はWi-Fiかモバイル回線のどちらかに固定し、自動切り替えを避けます。

手順1：遅延を5回連続で測定する

1. クライアントのプロキシまたはノード画面を開き、比較したい同じプロキシグループを見つけます。
2. テストURLを変えずに5回連続で実行し、各回の間隔を約10秒空けます。
3. 最低値、最高値、おおよその平均値を記録し、最後の1回だけを見ないようにします。
4. 5回の結果が82、87、79、91、84 msなら比較的安定しています。60、320、75、timeout、180 msなら、まずジッターとパケットロスを調べるべきです。

GUIクライアントではメニュー名がそれぞれ異なりますが、通常は「プロキシ」→「プロキシグループ」→「遅延テスト」から測定画面を開けます。一部のクライアントでは「設定」→「パラメータ設定」にテストURLとタイムアウト時間があります。変更前に元の値を控え、アクセスできないアドレスが原因ですべてのノードが失敗表示になるのを避けてください。

手順2：継続的なスループットを測定する

遅延が比較的安定しているノードを2～3個選び、それぞれで30秒以上の実ダウンロードまたは動画再生を行います。見るべきなのは開始直後のピークではなく、安定した速度です。たとえばダウンロード速度が最初は18 MB/sまで上がっても、5秒後から1.2 MB/sで推移するなら、そのノードの持続スループットは1.2 MB/sに近いと考えられます。比較時は同じ対象ファイル、同じ時間帯を使い、マルチスレッド処理同士で帯域幅を奪い合わないようにしてください。

動画が主な用途なら、同じ解像度の固定コンテンツをそれぞれ再生し、60秒間バッファが継続的に増えるかを確認します。1080p動画の必要ビットレートはエンコード方式や内容によって変わるため、「再生できた」だけでは判断できません。4Kコンテンツでは、より高い持続スループットと回線の安定性が求められます。測定中にノードを頻繁に手動切り替えすると既存接続が中断されるため、各ラウンドを個別に完了させてください。

手順3：用途に応じて選ぶ

• Web閲覧：遅延が安定し、ハンドシェイクが速いノードを優先し、帯域幅は普段の用途を満たせば十分です。
• 動画・ダウンロード：持続スループットと混雑時間帯の安定性を優先して比較し、最低遅延にこだわる必要はありません。
• 音声・ゲーム：パケットロス、ジッター、UDPの利用可否を重視し、平均遅延だけで判断しないでください。
• リモートターミナル：操作は往復遅延の影響を受けやすいため、連続測定で変動の小さい経路を選びます。
• モバイル回線：エレベーター、地下鉄、基地局の切り替えで結果が大きく変わるため、実際に使う場所で測定してください。

TUNモード、DNS、ローカルネットワークが結果に与える影響

TUNモードはより多くのシステム通信を引き受けますが、プロキシサーバーの帯域幅を自動的に向上させるものではありません。TUNを有効にすると、アプリの通信が従来のシステムプロキシ経由から仮想ネットワークアダプター経由に変わる場合があり、DNSハイジャック、ルーティングテーブル、MTU、ファイアウォール規則も処理に関わります。そのため、有効化前後の遅延差はログと実際の接続経路を合わせて判断し、単純にカーネル性能の問題と決めつけないでください。

まずローカルWi-Fiのジッターを除外する

ローカルルーター自体が不安定なら、すべてのノードが影響を受けます。まず有線接続とWi-Fiを比較するか、端末をルーターの近くに移動して測定してください。2.4 GHz帯は混雑した環境で干渉を受けやすく、5 GHz帯は近距離での高速通信に向いていますが、壁による減衰は大きくなります。すべてのノードが同時に80 msから500 msへ上昇した場合は、サブスクリプションをすぐに変更せず、先にローカル回線を確認してください。

DNSの遅さは初回接続を遅らせる

サーバーアドレスやテストアドレスにドメイン名を使う場合、DNSクエリの速度が初回接続に影響します。解決結果に問題があったり、上流DNSがタイムアウトしたりすると、クライアントは実際のプロキシハンドシェイクを開始する前に数秒待つことがあります。Clashの fake-ip モードはドメインに予約アドレスを割り当て、内部で実際のドメインへマッピングしますが、最終的には上流での名前解決とプロキシ出口への接続を正常に完了する必要があります。

切り分けでは、mihomoのログにDNS timeout、connection refused、i/o timeoutが繰り返し出ていないか確認します。特定のテストドメインだけ失敗する場合は、別の安定した小さなレスポンスのアドレスに置き換えて比較します。すべてのドメインで失敗する場合は、nameserver、ネットワーク権限、システム時刻を確認してください。TLS証明書の検証には正確な時刻が必要なため、システム日時が大きくずれているとHTTPSテストが直接失敗することがあります。

MTUの問題は大容量通信でだけ表面化することがある

小さな遅延リクエストが成功しても、大きなパケットが正常に通るとは限りません。TUNやVPNの多重化、特殊なブロードバンド環境では、MTUが不適切だとフラグメンテーションやブラックホールが発生することがあります。小さなWebリクエストは使えても、大容量ファイルの転送だけ停止するケースです。TUNを有効にした後に大容量通信だけ異常が出るなら、TUNを無効にしたシステムプロキシモードと比較し、クライアントのMTU設定、別のVPNが同時に動作していないか、ルーティングが二重に処理されていないかを確認してください。

よくある誤解と設定のポイント

誤解1：遅延が最も低いノードが必ず最速

最低遅延は、ある短いリクエストがその時点で速く完了したことを示すだけです。動画やダウンロード用のノードを選ぶなら、少なくとも30～60秒の持続スループット測定も行ってください。ノード間の遅延差が20 msでも、安定速度に40 Mbpsの差があるなら、大容量通信では後者のほうが重要になることが多いです。

誤解2：1回のtimeoutでノードが無効だと判断する

1回のタイムアウトは、テストサイトの障害、DNSクエリの失敗、ローカルネットワークの切り替え、一時的な混雑が原因かもしれません。3～5回連続で測定し、別のテストURLとも比較して初めて、ノードの障害とテスト先の障害を区別できます。1つのノードだけが継続して失敗する場合は、ノードのアドレス、ポート、プロトコルパラメータ、サブスクリプションの更新日時を確認してください。

誤解3：テスト間隔は短いほど正確

間隔が短すぎるとリクエスト数が増え、自動グループが一時的な変化に過敏になります。一般家庭のネットワークでは、まず300秒間隔と30～100 msの許容値を使い、ノード数や利用状況に応じて調整するとよいでしょう。リアルタイム通信で安定した接続が必要な場合は、自動グループの頻繁な切り替えを避けてください。既存のTCPセッションは通常、新しいノードへシームレスに移行しません。

誤解4：TUNを有効にすればあらゆる停止問題が解決する

TUNの主な役割は通信を引き受ける範囲を広げることであり、回線を高速化するスイッチではありません。サーバーの混雑、出口の速度制限、遠隔CDNへの経路問題は、TUNを有効にしても自動的には解消しません。まず通信がClashに入っていないのか、それともプロキシ経由にはなっているものの転送品質が低いのかを確認し、そのうえでモードを調整してください。

実際の使用感に近い結論

Clashの遅延値は、「指定したURLへの小さなリクエストを現在のノードが完了するまでの時間」と捉えることができます。接続できないノードやハンドシェイクが明らかに遅いノードを素早く除外し、url-test の自動選択にも利用できますが、動画が滑らかに再生できるか、ダウンロード速度がどれほど出るか、ゲームが安定するかを単独で判断することはできません。

実際に選ぶときは、まず5回測定した遅延の変動を確認し、次に30～60秒の持続スループットを測定し、最後に普段使う時間帯で対象サービスを検証します。Web閲覧やリモートターミナルでは安定した低遅延、動画やダウンロードでは持続帯域幅、ゲームや通話ではパケットロス・ジッター・UDP経路を重視します。これらを分けて測定してこそ、「数十msと表示されるのに止まる」本当の原因を説明できます。

すべてのノードが同時に遅くなった場合は、ローカルWi-Fi、テストURL、DNS、システム時刻、夜間の混雑を順に確認します。1つのノードだけ異常なら、そのノードのサーバー負荷、出口経路、プロトコル設定を調べてください。この順番で切り分けるほうが、遅延テストを何度も更新したり、理由なくモードを切り替えたりするより問題を見つけやすくなります。