Clash 振り分けグループの選び方:url-test・fallback・load-balance の違いを徹底解説

振り分けグループとは:通信の分岐点

Clash の設定ファイルでは、rules が「どの通信をどこに振るか」を決め、proxy-groups が「その通信を受けたグループが最終的にどのノードから出るか」を決めます。手動で切り替える select グループのほかに、Clash カーネル(mihomo を含む)は自動系のグループを3種類用意しています。url-test、fallback、load-balance です。いずれも手動でノードを切り替える必要はありませんが、自動化の考え方はまったく異なります。遅延を見るもの、生死を見るもの、振り分けをするものという違いです。

先に結論から言うと、普段使いで手間をかけたくないなら url-test。明確な主力ノードがあり、障害時のフェイルオーバーだけ欲しいなら fallback。複数回線の帯域をまとめて使いたいなら load-balance です。

url-test:遅延が最も低いノードを採用

url-test は最もよく使われる自動振り分けグループです。仕組みは2段階です。interval 秒ごとに、グループ内の各ノードがそれぞれ url で指定したアドレスへ検査リクエストを送り、往復時間を記録します。新しい通信がこのグループに来ると、カーネルは直近の測定で最も遅延が低く、かつ検査に通ったノードへ振り分けます。

使い勝手を左右する重要なパラメータが2つあります。

tolerance:許容差(ミリ秒単位)。候補ノードが現在のノードよりこの値以上速くならない限り、切り替えは発生しません。複数ノードの遅延が近いとき、許容差がないと切り替えが頻発し、接続が何度も再構築されてしまいます。
lazy:有効にすると、そのグループに通信があるときだけ測定を行います。無効にすると interval ごとにバックグラウンドで常時測定を続けます。ノード数が多いサブスクリプションでは有効にしておき、無駄な測定通信を減らすのがおすすめです。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港01
      - 香港02
      - 日本01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 100
    timeout: 5000

よくある誤解をここで解いておきます。遅延が低い=速いではありません。204検査は小さなリクエストの往復時間を測っているだけで、回線の応答速度を示すもので、帯域の大きさとは無関係です。大きなファイルのダウンロードが遅い場合、ノードの選択が悪いのではなく、そのノード自体の帯域が狭いだけということも多いです。

適した用途:同じ地域に品質の近いノードが複数ある場合、日常のブラウジングや動画視聴、通常のダウンロードなどは自動選択に任せて問題ありません。mihomo では expected-status で期待するレスポンスステータスコードを指定でき、想定外のステータスが返れば検査失敗と判定されるため、「接続はできるが応答が異常」な回線を検出できます。

fallback:主力が落ちたときだけ切り替える

fallback は遅延を比較せず、繋がるかどうかだけを判定します。動作は proxies リストの順序に厳密に従い、リストの先頭からヘルスチェックに通った最初のノードを常に使用します。現在のノードが max-failed-times 回連続で失敗すると利用不可とみなされ、通信は自動的に次のノードへ落ちます。先頭側のノードが復旧すれば、自動的に元へ切り戻ります。

proxy-groups:
  - name: フェイルオーバー
    type: fallback
    proxies:
      - 専用線メイン
      - 予備中継A
      - 予備中継B
    url: http://www.gstatic.com/generate_204
    interval: 120
    max-failed-times: 3

url-test との本質的な違いはここにあります。url-test は「使えるノード」の中から最速のものを選びますが、fallback は順序しか見ません。予備ノードの遅延が低くても、自ら切り替えることは絶対にありません。これはよくある状況にぴったり合います。主力が高価だが安定した専用線で、予備が普通の回線というケースでは、普段は1ミリ秒たりとも通信を予備側に流したくないものです。

ヘルスチェックの間隔が障害検知の速さを決めるため、fallback の interval は url-test より短く設定できます。たとえば120秒程度です。これより短くしてもあまり意味はなく、検査通信とログのノイズが増えるだけです。

load-balance:複数回線に通信を振り分ける

前の2つのグループは常に1つの出口ノードしか持ちませんが、load-balance はグループ内の複数ノードを同時に稼働させます。新しい通信ごとに strategy で指定した方式で異なるノードへ振り分けられます。

consistent-hashing(デフォルト):宛先アドレスをハッシュ化し、同じサイトへの通信は常に同じノードに固定されます。サイト側から見ると出口 IP が安定するため、日常の混在利用に向いています。
round-robin:通信ごとにノードを順番に切り替えます。マルチスレッドのダウンロードツールが一度に数十本の接続を張るような場合、通信が均等に分散され、複数回線の帯域を合算できます。

proxy-groups:
  - name: 負荷分散
    type: load-balance
    proxies:
      - ノードA
      - ノードB
      - ノードC
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: round-robin

代償もはっきりしています。接続ごとに出口 IP が異なる点です。ネットバンキング、決済、ログイン認証など IP の一致性に敏感な場面では、出口が頻繁に変わると不正アクセス判定に引っかかりやすく、再認証を求められたり、最悪ログインが一時的に制限されたりします。安全策としては、こうしたドメインだけルールで固定ノードや直接接続に振り、それ以外の通信を負荷分散グループへ流すのが無難です。

3種類の振り分けグループの選び方

観点	url-test	fallback	load-balance
判断基準	遅延が最も低い	リストの順序、先頭から使える最初のノード	戦略に応じて接続単位で振り分け
同時刻の出口	単一ノード	単一ノード	複数ノードが並行動作
切り替えの契機	測定結果の差が許容差を超えたとき	現在のノードのヘルスチェック失敗時	新しい接続が発生するたび
典型的な用途	日常ブラウジングで自動的に速いノードを選びたい場合	主系・待機系の冗長構成	マルチスレッドダウンロードによる帯域の合算
主な弱点	遅延しか見ておらず帯域は測っていない	予備が速くても自発的には切り替わらない	接続ごとに出口 IP が変わる

一言でまとめると、ノードの品質が近くて手間をかけたくないなら url-test、ノードに明確な優先順位があり障害時のフェイルオーバーだけ欲しいなら fallback、スループットを重視し出口 IP の変動を受け入れられるなら load-balance です。迷ったらまず url-test を1つ作れば、日常のほとんどのニーズをカバーできます。

組み合わせ方とよくある落とし穴

振り分けグループは相互に入れ子にできて、グループ名自体を合法的なメンバーとして参照できます。よくあるのは自動系のグループを select グループの中に入れ、rules は最外層のグループだけを参照する書き方です。

proxy-groups:
  - name: メインプロキシ
    type: select
    proxies:
      - 自動選択
      - フェイルオーバー
      - DIRECT
  - name: 自動選択
    type: url-test
    proxies:
      - 香港01
      - 香港02
      - 日本01
    url: http://www.gstatic.com/generate_204
    interval: 300

普段は「自動選択」を使い、出口を固定したいときはクライアントのプロキシページで「フェイルオーバー」や DIRECT に手動で切り替えれば、ルールファイルは一切変更不要です。mihomo ユーザーはさらに use フィールドで proxy-providers を参照でき、サブスクリプション内のノードをまとめてグループに取り込み、filter の正規表現で絞り込むことで、ノード名を1つずつ列挙する手間を省けます。

Clash Verge Rev での設定方法

設定ページで対象の設定を右クリックし「ファイルを編集」を選べば、YAML を直接編集できます。保存すると自動的にホットリロードされます。プロキシページに切り替えれば、各振り分けグループが現在選択しているノードとリアルタイムの遅延が一目でわかり、変更後すぐに確認できます。

変更はサブスクリプション更新で上書きされます

サブスクリプションから生成された設定ファイルを直接編集した場合、次回サブスクリプションを更新すると変更は上書きされてしまいます。長期的にカスタマイズしたい場合は、Clash Verge Rev の設定ページにあるマージ(オーバーライド)機能を使い、振り分けグループの設定は拡張設定側に書き、サブスクリプション本体には書かないようにしてください。

interval は小さいほど良いわけではない

検査間隔を短くしすぎると、数十から百以上のノードが次々と検査アドレスへリクエストを送るため、CPU・バッテリー・通信量がすべて消費され、ログもヘルスチェックの記録で埋まってしまいます。日常使いなら300秒前後が妥当な起点です。fallback はやや短くしても構いませんが、60秒未満は推奨しません。

検査アドレス自体の安定性が重要

3種類のグループはいずれもヘルスチェックに依存しています。検査リクエストはノード経由で送られ、アドレスに到達できなければそのノードは失敗と判定されます。長期的に安定した204検査用アドレスを1つ選んでおきましょう。ある日突然グループ全体が「タイムアウト」した場合は、まず検査アドレス自体の不調を疑い、その次にノードを疑うのが順番です。

グループ名の参照は一致させる

rules で参照するグループ名は、proxy-groups の name と完全に一致させる必要があります。スペース1つ余分に入っているだけでもマッチに失敗します。設定変更後はログページを確認しましょう。読み込みエラーが出れば問題の行がそのまま示されます。