Clashのノード速度測定の仕組み:低遅延ノードなのに実際は重い理由

一、遅延の数値はどうやって測定されるのか

Clashクライアントのノード一覧で速度測定ボタンを押すと、数百ミリ秒後に各ノードの横にミリ秒単位の数値が表示されます。この数値の仕組みは、そのノードを出口として、コアがテスト用アドレスへ1回のHTTPリクエストを送信するというものです。よく使われるテストアドレスはhttps://www.gstatic.com/generate_204で、これは204の空レスポンス(レスポンスボディ0バイト)を返すだけです。リクエスト送信からレスポンスヘッダー受信までの経過時間が、画面上に表示される「遅延」です。

この1回のリクエストを分解すると、所要時間は3つの区間で構成されます。端末からノードサーバーまでの接続確立(TCPハンドシェイク、TLS系プロトコルならさらにTLSハンドシェイクも加わる)、ノードサーバーからテストアドレスまでの接続と転送、そしてテストアドレスがレスポンスを生成して経路を戻ってくる区間です。つまり本質的には「小さなリクエストの往復所要時間」であり、ダウンロード速度でもなければ動画のビットレートでもありません。

url-testグループの自動速度測定とボタンでの手動測定は同じ仕組みで、定期的に自動実行される点だけが異なります。典型的な自動選択の設定例は次のとおりです。

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

ここでintervalは測定周期で、デフォルトは300秒ごとです。toleranceは許容差で、現在のノードよりこのミリ秒数以上速いノードがあった場合のみ切り替えが発生します。デフォルトは50ミリ秒で、遅延が近い2つのノード間で頻繁に切り替わる「ちらつき」を防ぐためのものです。この2つのパラメータは、後述するノード選定にも関わります。

二、遅延が低い=速いではない理由

1回の204リクエストのデータ量はわずか数百バイトで、これが測定するのは経路の「反応速度」であり、パイプの「太さ」はまったく測れません。実際の使用感を左右する以下の要因は、遅延の数値には一切反映されません。

帯域と単一接続のスループット

実際のダウンロード速度は、経路の残り帯域とTCP輻輳制御によって決まります。おおまかに言えば、単一のTCP接続のスループット上限は「送信中ウィンドウサイズ ÷ 往復遅延(RTT)」で近似できます。低遅延には確かに先天的な利点がありますが、それは帯域が十分でパケットロスがないことが前提です。遅延30ミリ秒でも空き帯域が5Mbpsしかない経路は、遅延200ミリ秒でも空き帯域300Mbpsある経路にダウンロードで確実に劣ります。ミリ秒の数値が良くても、データ転送が速いとは限りません。

パケットロス:見えない元凶

TCPはパケットロスが発生すると再送が必要になり、輻輳ウィンドウも縮小します。1%のパケットロス率だけでスループットは何度も半減します。一方、速度測定の小さな204リクエストは、たまたま一度もパケットロスに遭遇しないことが多く、結果として「問題なし」と表示されます。深夜・夜間帯の混雑する国際回線では、パケットロスは遅延よりも先に、そしてより深刻に悪化する傾向があります。

ジッター:安定性のもう一つの側面

遅延が上下に大きく変動する現象をジッターと呼びます。速度測定は1回のサンプルしか取らないため、ジッターは検出できません。動画視聴中の突然のバッファリング、ゲーム中のping飛び、音声通話の途切れなどは、多くがジッターや突発的なパケットロスによるもので、平均遅延とはほぼ無関係です。平均60ミリ秒でも時々400ミリ秒まで跳ね上がるノードは、常に150ミリ秒で安定しているノードより使用感が悪くなります。

夜間帯の混雑と通信事業者側の制限

多くの回線は日中は空いていて、20時から23時に混雑します。午後に速度測定してノードを選ぶ習慣があると、選んだ「最速ノード」が夜間の混雑に耐えられない可能性があります。また、一部の通信事業者は特定のポートやプロトコルに対して帯域制限(QoS)をかけることがあり、小さなリクエストの速度測定では検出できず、継続的な大容量通信で初めて発覚します。

ノードサーバー自体の負荷

ノードは共有リソースです。同一サーバーの利用者が増えるほど、CPUの暗号化・復号処理の待ち行列やネットワーク帯域の分配が厳しくなります。TLSや難読化などのプロトコルオーバーヘッドは、サーバーが混雑しているときにレスポンス時間をさらに拡大させます。このとき遅延の数値も悪化しますが、その悪化速度は実際の使用感の悪化より遅れて現れる傾向があり、ミリ秒数の上昇に気づく頃には、すでにしばらく重い状態が続いています。

三、速度測定の結果から読み取れること

遅延の数値も無意味ではありません。重要なのは正しく読み取ることです。

timeoutと「遅い」は別物です。速度測定でtimeoutと表示される場合、タイムアウト時間(デフォルトで約5秒)内にレスポンスが得られなかったことを意味し、よくある原因はノードのダウン、入口の遮断、プロトコルのハンドシェイク失敗です。このようなノードは「遅いノード」ではなく「利用不可」として扱うべきです。

数回連続で測定し、単発の値ではなく変動を見る。50、55、52ミリ秒なら安定していますが、80、300、150ミリ秒なら変動が大きい状態です。後者は最小値が良くても、実際の使用感は悪くなることが多いです。

ダッシュボードで履歴曲線を見る。metacubexdやYacdなどのダッシュボードでは各ノードの遅延履歴を確認できます。曲線が滑らかであることは、数値が低いことよりも信頼できる指標です。

テストアドレスの経路上の得意・不得意を意識する。gstaticへの速度が速いことは、よく見る動画サイトやゲームサーバーへの速度が速いことを意味しません。それらは全く異なる国際出口を経由している場合があります。速度測定に通ったことは、あくまで「そのテストアドレスまでの経路が通っている」ことを示すだけです。

四、より信頼できるノード選定方法

実際の通信で再検証する。候補ノードを2〜3個に絞ったら、それぞれ10分ほど接続してみます。高ビットレートの動画を視聴する(プレーヤーの統計情報にある接続速度が分かりやすい指標)、マルチスレッドの速度測定を1回実行する、シングルスレッドの大容量ファイルダウンロードが安定しているか確認する。この3項目すべてに合格したノードだけが本当に使えるノードです。
夜間帯にもう一度測定する。20時から23時の間に上記の実測を繰り返します。空いている時間帯は速いのに混雑時に落ちるノードは、自動選択グループの上位ではなく、控えとして格下げしてください。
単発の値ではなくジッターを見る。連続で5〜10回速度測定し、最大値と最小値の差を記録します。差が小さいほど安定しています。安定性を重視する用途では、ふらつく低遅延より安定した中程度の遅延を選ぶべきです。
ポリシーグループに切り替え判断を任せる。日常的な閲覧は適切な許容差を設定したurl-testに任せ、安定性が求められる用途(リモートデスクトップ、オンライン会議)では、メインノード障害時のみ切り替わるfallbackを使います。

proxy-groups:
  - name: 安定優先
    type: fallback
    proxies:
      - メインノード
      - 控えノード
    url: https://www.gstatic.com/generate_204
    interval: 120

「万能ノード」を探すのではなく、用途ごとに振り分ける。ダウンロードには帯域の大きいノードを、ゲームや通話には低遅延・低ジッターのノードを、それぞれ別のポリシーグループで受け持たせれば、互いに干渉しません。

注意

速度測定の間隔を短くしすぎないでください。intervalを数十秒に設定すると「常に監視している」感覚になりますが、実際の効果はごくわずかです。測定ごとにノードとテストアドレスへ余分なリクエストが発生し、頻度が高すぎると対象サーバーのレート制限を誘発する可能性もあります。300秒前後が無難な値です。

五、よくある質問

遅延30ミリ秒のノードで、4K動画を見るとバッファリングするのはなぜ?

4K動画に必要なのは25Mbps以上の継続的なスループットであり、低遅延ではありません。遅延が良好でも帯域が不足していたり、パケットロス率が高い場合は、バッファリングが発生します。第四節の方法でスループットを測定すべきで、ミリ秒数だけを見ても意味がありません。

同じノードなのに、スマホでは速く、パソコンでは遅いのは速度測定が不正確だから?

必ずしもノードの問題とは限りません。両方の端末からノードまでの経路は同じなので、ボトルネックはパソコン側にある可能性があります。Wi-Fi信号が弱い、ローカルのファイアウォールがブロックしている、あるいはTUNモードのオーバーヘッドなどです。TUNモードは仮想ネットワークアダプタを経由する転送処理が1段増えるため、性能の低い端末ではスループットが落ちることがあり、これは遅延テストとは無関係です。

速度測定が全部緑なのに、それでもウェブページが開けないのはなぜ?

速度測定が検証するのは「テストアドレスまで」の区間が通っているかどうかだけで、ルールマッチングの誤りやDNS解決の異常はチェック対象外です。このような問題はよくある質問ページを参照し、システムプロキシのオン/オフ、ルールモード、DNS設定の順に確認してください。