Clash 遅延テストの仕組み解説:パネル表示80msでも実際は重い理由

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

Clashコアを使うクライアントのプロキシページを開くと、各ノードの後ろにミリ秒数が表示されます。緑は速い、黄色は普通、赤はタイムアウトまたは利用不可を示します。この数値はクライアントが定期的に行う速度測定から来ており、業界では通常 URL Test と呼ばれます。仕組みは単純で、クライアントがこのノードを経由して固定のアドレスへHTTPリクエストを一度送り、リクエスト送信からレスポンスヘッダー受信までの経過時間を記録します。この経過時間がパネルに表示される数値です。

重要なのは、この測定が「短いリクエスト1回分の往復時間」しか測っていない点です。本文コンテンツをダウンロードするわけでもなく、Webページ閲覧時のような複数の同時接続をシミュレートするわけでもありません。これはネットワーク工程で言う RTT(Round-Trip Time、往復遅延時間) に近く、「パケットを送って確認応答が返るまでの時間」を測っているのであって、「ページを開いて全リソースの読み込みが完了するまでの時間」を測っているわけではありません。両者は関連しているように聞こえますが、実際の差はかなり大きくなり得ます。

補足:遅延数値は回線の応答速度の上限を反映するものであり、使用体感の下限を保証するものではありません。低遅延は必要条件ですが、十分条件ではないのです。

URL Testが測るのは接続時間、ページ読み込み時間ではない

この差がどこから来るのかを理解するには、実際のWebページ読み込みで何が起きているかを見る必要があります。一般的なWebページを開くとき、ブラウザは少なくとも以下のことを行います。

DNSでドメイン名を解決し、対象サーバーのIPアドレスを取得する
サーバーとTCP接続を確立する(3ウェイハンドシェイク)
HTTPSの場合は、さらにTLSハンドシェイクで暗号化パラメータを協議する
HTTPリクエストを送信し、サーバーからのレスポンスヘッダーと本文を待つ
HTMLを解析し、ページ内の画像・スクリプト・スタイルシートなどのリソースを並行してリクエストする
ブラウザがレンダリングし、ページが操作可能になるまで待つ

URL Testが測っているのは上記2~4番目のステップのごく一部にすぎず、しかもテスト対象は通常サイズが小さく応答の速い固定アドレス(専用の測定用エンドポイントなど)であり、サーバー負荷はほぼ無視できるレベルです。一方で普段アクセスするサイトや動画サイト、ゲームサーバーは負荷状況、地理的位置、CDNノードの分布がまったく異なります。同じプロキシ回線でも、テスト用アドレスへは80ms、別の対象へは200msということがあり、これは遅延数値が「誤って測定された」わけではなく、そもそも1つのサンプル点しか代表していないからです。

また、多くのクライアントの自動測定にはスロットリング機構があり、リソースへリクエストするたびにリアルタイムで測っているわけではありません。パネルに表示される数値は数十秒~数分前のスナップショットであることが多いのです。回線状況自体も変動し、特にピーク時間帯の中継ノードでは、5分前は80msでも今は300msに上がっている可能性があり、パネルはそこまでリアルタイムには更新されません。

パケットロス・帯域幅の限界・回線混雑が実体感を悪化させる仕組み

遅延数値以外にも、「使っていて重いかどうか」を直接左右する3つの変数があり、そのほとんどはこのミリ秒数には反映されません。

パケットロス率

TCPプロトコルは確認応答と再送によってデータの完全性を保証しており、パケットが回線上で失われると、送信側はタイムアウトを待ってから再送します。この待機は数百ミリ秒単位から始まります。低遅延だがパケットロス率が高い回線は、「Webページはすぐ開くが動画がよく止まる」「ゲームの遅延数値は正常だが突然カクつく」といった形で現れます。URL Testの単発の短いリクエストではパケットロス問題を見つけにくく、サンプル数が少なすぎてちょうどパケットロスの瞬間に当たらないためです。

帯域幅の限界

遅延は「応答が速いかどうか」を測るもので、帯域幅は「回線の太さ」を測るものです。遅延はわずか50msでも帯域幅が2Mbpsしかない回線では、Webページの表示はすぐに始まりますが、ファイルのダウンロードや高画質動画の視聴では明らかに詰まり、プログレスバーの進みが遅くなります。これは完全に独立した2つの指標で、パネル上の遅延数値は帯域幅の限界に対して無反応です。

回線混雑

プロキシ回線はしばしば複数段の中継を経由し、いずれかの中継サーバーの負荷が高すぎたり、上流帯域幅が多数のユーザーに占有されたりすると混雑が発生します。混雑の典型的な症状は、時間帯によって遅延が激しく変動し、ピーク時に悪化し、深夜に改善することです。クライアント起動直後の1回だけの遅延測定を見て回線品質を判断すると、誤った結論に至りやすくなります。

現象	遅延数値の表示	実際の原因
動画が止まる、バッファリングの輪が回り続ける	「緑色」の低遅延を維持していることがある	パケットロスによるTCP再送、または帯域幅がビットレートに不足
Webページは瞬時に開くがファイルのダウンロードが遅い	遅延は正常	帯域幅の限界で、遅延とは無関係
日中は普通だが深夜に突然速くなる	時間帯によって数値が異なる	負荷変動による回線混雑
パネルにタイムアウト/赤色表示	数値が異常または欠落	ノードの障害、または測定対象自体に到達不能

実体感に近い自己診断方法

パネルの遅延だけでは不十分なので、実際の利用シーンに近いいくつかの検証方法を組み合わせて、回線が本当に使えるかを判断できます。

1. 複数の実際の対象へ手動で速度測定する、自動測定だけを信じない

多くのClashクライアントは単一ノードやグループの再測定を手動で行う機能をサポートしており、設定で測定用アドレスを自由に指定できます。デフォルトの測定アドレスを実際によく使うサービス(よく訪れるサイトのトップページなど)に変更すれば、そのサービスへの実際のアクセス時間に近い数値が得られます。同じノードで一般的な測定用アドレスと実際にアクセスしたい対象アドレスをそれぞれ測定して差を比較すれば、その回線が「全般的に速い」のか「測定対象に対してだけ速い」のかを判断できます。

2. ログページで接続の過程を観察する、数値だけを見ない

クライアントのログページ(または接続ページ)には、実際の接続ごとの対象アドレス、使用ノード、ルールのマッチ結果が記録されます。実際に重いページを開いたときにログを確認すれば、そのアクセスがどのノードを経由したか、頻繁に再接続していないか、ルールの誤判定で低速回線に振られていないかを確認できます。これはプロキシページの遅延数値だけを見るより、問題箇所の特定に役立ちます。

3. OS標準ツールで基本的なネットワーク診断を行う

ping -c 20 対象のドメインまたはIP
tracert 対象のドメインまたはIP   # Windowsはtracert、macOS/Linuxはtracerouteを使用

連続20回のpingでパケットロス率(出力中のpacket loss)が分かり、一度きりの遅延数値より回線の安定性を反映できます。ルートトレースを行えば、どのホップからパケットが明らかに遅くなったり失われたりしているかが分かり、問題がローカルネットワーク・中継ノード・対象サーバー側のどこにあるかを判断する手掛かりになります。

4. 時間帯を変えて再テストする

回線混雑を疑う場合は、同じ回線を異なる時間帯(夜9時のピーク時と深夜2時など)でそれぞれ測定してみましょう。遅延やパケットロスの表示に明確な差があれば、問題が回線の負荷にあり、回線自体の設定ミスではないと基本的に判断できます。

5. 端末側の干渉要因を除外する

結論を出す前に、システムプロキシが正しく有効になっているか、他のプロキシソフトと競合していないか、TUNモードが正常にトラフィックを引き継いでいるかを確認しましょう。これらの設定面の問題も「重い」という症状として現れますが、回線品質とは無関係なので、まず先に除外すべきです。

注意:複数のノードで、複数の時間帯にわたって高遅延や高パケットロスが測定される場合は、サブスクリプション自体の回線品質の問題である可能性が高く、クライアント設定を繰り返し調整するより、ノードを変えるかサブスクリプション提供元に連絡する方が効果的です。

よくある疑問

2つのクライアントで同じノードを測定したのに遅延数値が違うのはなぜ?

測定用アドレス、タイムアウトのしきい値、測定頻度のデフォルト設定が異なるため数値に差が出るのは正常な現象で、どちらかが「より正確」というわけではありません。

遅延がずっと緑色なのに動画がよく止まる、どうすればいい?

まずパケットロスと帯域幅の限界を疑いましょう。pingを何度も実行してパケットロス率を観察し、そのノードの帯域幅に速度制限がないか確認して、必要なら別のノードグループに切り替えてみてください。

自動測定の更新間隔はどれくらいで、もっと頻繁にできる?

多くのクライアントは設定で自動測定の間隔を調整できますが、頻度を上げすぎると不要なネットワークリクエストが増えるだけなので、基本的にはデフォルトのままか少し短くする程度で十分で、リアルタイム更新を追い求める必要はありません。