Clashの遅延数値の見方:
数十msなのにカクつく理由

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

Clashクライアントを開くと、ノード一覧の右側に表示されるミリ秒の数字は、内核が各ノードに対して行う1回のネットワーク探測から得られたものです。具体的には、クライアントがそのノード経由で接続を確立し、設定内のtest-url(デフォルトの多くはhttp://www.gstatic.com/generate_204のような軽量なエンドポイント)に対して1回HTTPリクエストを送り、リクエスト送出からレスポンス受信までの時間を記録します。この時間が遅延として表示されます。

このプロセスで発生するのはDNS解決(対象がドメイン名の場合)、TCP/TLSハンドシェイク、そして1回のごく小さなHTTP往復の3つだけです。実質的なコンテンツはダウンロードせず、対象エンドポイントは通常204の空レスポンスか数バイトのテキストしか返さないため、テスト全体で帯域幅はほとんど要求されません。つまり遅延の数値が示しているのは「このノードにつないで一往復するまでの時間」であり、「このノードが動画視聴や大容量ダウンロードに耐えられるか」とは別の話なのです。

遅延が低いのに実際はカクつく理由

30msや50msといった数字を見て、そのノードが「速い」と決めつけてしまうのは最もよくある誤解です。実際のカクつきは、遅延テストがまったく捉えられない次のような要素から発生することが多いです。

• パケットロスとジッター:遅延テストは1回の探測にすぎず、1回成功したからといって持続的に安定しているとは限りません。ノードがある瞬間には速く応答しても、実際にブラウジングや動画再生をしている数十秒間に断続的なパケットロスが発生し、映像がカクついたり読み込みが止まったりする一方、遅延リストの更新時にはたまたま正常な値が測定されている、ということが起こります。
• 帯域幅と出口の混雑:遅延探測のリクエストサイズはほぼゼロで、速度制限や混雑を引き起こしません。しかし動画を開いたりファイルをダウンロードしたりするには持続的なスループットが必要で、ノードの出口帯域が限られていたり多数のユーザーで共有されていたりすると、実際の速度は遅延数値が示す「速さ」よりはるかに低くなります。
• ターゲットサーバーと着地品質:test-urlは通常、海外大手企業の軽量エンドポイントであり、実際にアクセスしたいウェブサイトやアプリのサーバーとはネットワーク経路がまったく異なる場合があります。テスト経路が快適であっても、実際にアクセスするターゲットへの経路が快適であるとは限りません。
• プロトコル層の違い:プロキシプロトコルによって、小パケットのテストと持続的な大容量トラフィックでの挙動が異なります。低遅延なシーンで有利なプロトコルでも、不安定なネットワークや高並行のシーンでは切断・再接続が起きやすいことがあります。

test-url・タイムアウト・並行測定の仕組みが数値に与える影響

遅延の数値は一度きりの計算で固定されるものではなく、複数の設定可能な仕組みによって決まります。これらを理解すれば、目の前の数値が信用できるかどうか判断しやすくなります。

test-url:誰の経路を測っているか

プロキシグループ設定内のurl(ドキュメントによってはtest-urlとも表記)フィールドが探測先を決定します。多くのサブスクリプションではデフォルトで海外の軽量検出エンドポイントを指定しており、こうしたエンドポイントは世界各地から応答が良好なため、測定される数値は概して低め・見栄えの良いものになります。特定の地域やサービスのサイトを主に利用する場合、その経路はデフォルトのテスト対象とは全く異なる可能性があり、数値が良くても目的のサイトが同じように速いとは限りません。

interval:再測定の頻度

プロキシグループのinterval(秒単位)は自動速度測定の間隔を決めます。一般的には300秒前後に設定されていることが多いです。つまりリスト内の数値は数分前のスナップショットである可能性が高く、ネットワーク状況は常に変化しているため、数値には遅延(タイムラグ)があり「今この瞬間」の実態を反映しているとは限りません。

tolerance:許容範囲内では切り替えない

toleranceフィールド(ミリ秒単位)は、自動選択型プロキシグループの切り替え許容差を定義します。新しく測定された遅延が現在のノードよりわずかに良い程度で、その差が許容範囲内であれば、クライアントはノードを切り替えません。これにより頻繁なジッターによる接続の再構築を防いでいます。リストに明らかに遅延の低いノードがあるのに自動選択が「反応しない」ように見えるのは、これがtoleranceのルールに従って動作しているためで、測定できていないわけではありません。

timeoutと並行探測

探測リクエスト自体にはタイムアウト制限があり、しきい値を超えると即座にタイムアウトと判定されます(通常は失敗または極端に高い数値として表示)。同じバッチのノードは並行して速度測定されることが多く、ローカルのネットワークやCPU、並行数の設定が不適切だと、短時間に大量の並行リクエストが互いにリソースを奪い合い、測定結果が全体的に高めに出たり不安定になったりします。この場合、1回の測定結果はあまり参考にならないため、複数回測定して傾向を見ることをお勧めします。

遅延数値を正しく読み解く3つのアクション

1. 単発値ではなく傾向を見る:手動で複数回速度測定を実行し(多くのクライアントはリフレッシュボタンや個別ノードの右クリック測定をサポート)、同じノードの異なる時点での変動幅を観察します。変動が小さいノードは平均値がやや高くても、実際の体感は安定していることが多いです。
2. 実際の場面で検証する:遅延数値が問題なければ、実際によく使うウェブサイトを開いたり、小さなファイルのダウンロードテストを行ったりして、読み込み速度やカクつきの有無を体感で確認します。この一手が数値を見るより直接的です。
3. 「自動選択グループ」と「手動選択」を区別する:プロキシグループが自動選択型(url-testタイプ)であれば、すでにintervalとtoleranceに基づいてノードを選別しています。手動グループの場合、数値はあくまで参考であり、最終的にはノードを変更するかどうかは実際の使用感で判断すべきです。

数値は良いのに体感が悪い場合の追加チェック

遅延数値が長期的に低いのに、ページの読み込みが遅い、動画のバッファリングが頻発する、ダウンロード速度が上がらないといった場合は、次の順序で確認しましょう。

• 別のノードに切り替えて同種の比較テストを行い、単一ノードの問題かサブスクリプション全体の共通問題かを判断します。
• TUNモードが有効になっているか、ルール分岐が大容量トラフィックのアプリを適切なプロキシグループに正しく振り分けているか確認します(過負荷になり得る同一ノードに全部流していないか)。
• 現在の時間帯がネットワークのピーク時間かどうかを確認します。一部の経路では夜間のピーク時にユーザーが集中して帯域を奪い合うことがあり、こうした混雑は遅延探測の小パケットテストには反映されません。
• ローカルのネットワーク自体に問題がないか確認します。まずプロキシを使わない状態でローカルのネット速度とパケットロスをテストし、ローカル環境が原因の見せかけの問題を排除します。

ノードを選ぶ際に見るべき複合的な指標

遅延を最初のふるい分けの目安として使い、唯一の判断基準としないことが大切です。以下の観点も合わせて総合的に判断するとより確実です。

• 遅延の安定性:複数回測定した際の変動幅は、単発の数値より重要です。
• プロトコルと暗号化方式:不安定なネットワークや高並行のシーンでの耐障害性はプロトコルによって異なり、同じバッチ内でプロトコルが揃っている場合に比較する意味があります。
• 着地地域と経路:同じノードでも時間帯やアクセス先サイトによって挙動が大きく変わることがあり、長期的な観察のほうが単発の判断より信頼できます。
• 実際のスループットテスト:可能であれば実際のダウンロードや速度テストを行い、帯域が遅延数値による「好印象」と一致しているかを直接検証します。

遅延テストは、明らかに異常なノードやタイムアウトするノードを素早く排除するための便利なふるい分けツールですが、日々の使用感を決めるのは常に帯域幅・パケットロス率・経路の混雑状況を総合した結果です。これらを分けて見ることで、見栄えの良いミリ秒の数字に惑わされずに済みます。