Clash 振り分けグループ選定ガイド:url-test・fallback・load-balance の違いと使い分け

振り分けグループとは:判定グループと実行グループの関係

Clash や Clash Meta(mihomo)の設定ファイルでは、proxies セクションに具体的なプロキシノードを列挙し、proxy-groups セクションで「振り分けグループ」を定義します。振り分けグループとは、複数のノードや下位の振り分けグループをまとめて、一定のルールで実際にどれを使うかを決める論理的な単位です。rules セクションが最終的に指し示すのは特定のノードそのものではなく、振り分けグループの名前であることが多く、実際にどのノードにトラフィックが流れるかは実行時に振り分けグループが決定します。

現在主流の振り分けグループには4種類あります:select(手動選択)、url-test(自動速度判定選択)、fallback(フェイルオーバー)、load-balance(負荷分散)。4つとも同じフィールド構成(name、type、proxies)を共有していますが、判定ロジックは全く異なります。使い分けを誤ると「バックアップノードを設定したのに切り替わらない」「ノードが頻繁に切り替わる」といった問題が起きます。それぞれの発動条件を理解することが、安定したサブスクリプション設定を組む前提になります。

select:手動選択タイプの振り分けグループ

select は最も基本的なタイプで、速度判定やヘルスチェックは一切行わず、単純に複数のノードや振り分けグループを並べてクライアント画面上で手動切り替えできるようにするだけです。デフォルトでは proxies リストの先頭が表示され、切り替え後はクライアントが直前の選択を記憶します(実行時の状態として保持されるだけで、設定ファイル自体は変更されません)。典型的な用途はトップレベルの入口グループとして、「自動優先」と「特定ノードの直接指定」を自由に切り替えられるようにすることです。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動優先
      - 香港リレー
      - 日本専用線
      - DIRECT

速度判定や障害検知を行わないため、select グループに入れたノードがすでに使えなくなっていても、ユーザーが手動で切り替えるまでトラフィックはそのノードに流され続けます。そのため実運用では、素のノードを select にそのまま並べるのではなく、速度判定系の下位グループ(後述の url-test グループなど)を選択肢の一つとして加え、手動での制御性と自動フォールバックの両方を確保するのが一般的です。

url-test:自動速度判定と切り替え判定の仕組み

url-test グループは設定されたテスト用アドレスへ定期的にリクエストを送り、各ノードの応答遅延を記録した上で、現在最も遅延が低く、かつその差が許容範囲(トレランス)を超えているノードを自動的に選びます。中心となるフィールドは3つです:

• url:速度判定リクエストの宛先。通常はグローバルに到達可能な軽量なアドレスを使う;
• interval:速度判定の周期(秒)。短すぎるとノードへの負荷やバッテリー消費が増え、長すぎると障害の検知が遅れる;
• tolerance:許容差(ミリ秒)。新たに最速となったノードが現在のノードより許容差以上速くならない限り実際には切り替わらず、数ミリ秒程度のブレによるノードの頻繁な切り替わりを防ぐ。

proxy-groups:
  - name: 自動優先
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - 香港リレー
      - シンガポール専用線
      - 日本専用線

url-test は、ノード数が多く「速いものを使えればどれでもよい」という用途に向いています。日常的なブラウジングや動画視聴のように遅延に敏感だが特定の経路を固定する必要がない場合に適しています。限界としては、速度判定の結果はその瞬間のネットワーク状況しか反映しないため、実際の通信先サーバーとテストアドレスの経路が大きく異なる場合、選ばれた「最速」ノードが実際の用途では最速とは限らないことです。

fallback:フェイルオーバーの発動条件と検知遅延

fallback グループは proxies リストの順序どおりに順番へルスチェックを行い、先頭にあり検査を通過したノードを優先的に使用します。現在使用中のノードの検査が失敗した場合(タイムアウトや予期しない応答)にのみ、次に使えるノードへ順位どおりに切り替わります。url、interval の2つのフィールドでヘルスチェックを行う点は同じですが、判定ロジックは url-test と異なります。url-test は「どれが一番速いか」を比較するのに対し、fallback は「先頭のノードがまだ生きているか」を確認します。

proxy-groups:
  - name: フェイルオーバー
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - メイン専用線
      - バックアップ専用線-A
      - バックアップ専用線-B

fallback は明確な優先順位があり「必要がない限りメイン経路を切り替えたくない」場合に向いています。例えば安定しているがコストの高い専用線を先頭に置き、速度は平凡だが安定性で勝るバックアップノードを後ろに置くことで、メイン経路が本当に切れたときだけ切り替わり、単発の遅延上振れで無駄に切り替わることを防げます。注意点として、fallback のヘルスチェック間隔が障害検知の遅延を決めます。検知周期を長く設定しすぎると、メイン経路が故障してもしばらくトラフィックが使えないノードに流れ続け、短く設定しすぎると検査リクエストの頻度が増えてしまいます。

load-balance:負荷分散の2つの戦略

load-balance グループは「唯一最適な1つを選ぶ」ことを目指すのではなく、リクエストを複数のノードに分散させます。複数の経路で帯域の負荷を分担し、1つのノードが長時間すべてのトラフィックを負担する状況を避けたい場合によく使われます。strategy フィールドで分散アルゴリズムを指定し、主に2つの値があります:

• consistent-hashing:リクエストの宛先アドレスに対して一致性ハッシュを行い、同じ宛先ドメイン/IP は常に同じノードに振り分けられます。セッション維持が必要な場合(固定の出口 IP でなければ正常にログインできないサイトなど)に適しています;
• round-robin:リクエストを順番に異なるノードへ割り振ります。分散はより均等になりますが、同じ宛先でもリクエストごとに異なるノードに振り分けられる可能性があり、出口 IP の一致性が求められる用途には向きません。

proxy-groups:
  - name: 負荷分散
    type: load-balance
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    proxies:
      - 専用線-A
      - 専用線-B
      - 専用線-C

load-balance グループにもヘルスチェックがあり、使えなくなったノードは自動的に振り分け対象から除外されます。帯域や遅延が近い同質な経路が複数並存し、負荷分散が目的で優劣を選ぶ必要がない場合に適しています。経路間の品質差が大きい場合に安易に負荷分散を使うと、リクエストが品質の悪いノードにランダムに振り分けられてしまい、体感は url-test より不安定になります。

よく使われる組み合わせと実践のポイント

実際の設定では単一のタイプだけを使うことは少なく、階層的に組み合わせるのが一般的です。トップレベルに select グループを置いてユーザーが手動で介入できるようにし、その下に異なる戦略の子グループを複数配置し、rules がドメイン/IP のルールに従って具体的な子グループへ振り分けます。よくある構成は次のとおりです:

proxy-groups:
  - name: アウトバウンド戦略
    type: select
    proxies:
      - 自動優先
      - フェイルオーバー
      - DIRECT

  - name: 自動優先
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [専用線-A, 専用線-B, 専用線-C]

  - name: フェイルオーバー
    type: fallback
    url: "https://www.gstatic.com/generate_204"
    interval: 180
    proxies: [メイン専用線, バックアップ専用線-A]

選定は次の考え方で判断できます。「普段は自動で最速を選び、多少の切り替わりは許容する」なら url-test。「明確な主・副の順序があり、メイン経路をむやみに離れたくない」なら fallback。「複数の経路でトラフィックを一緒に受け止めたい」なら load-balance。「ユーザーに手動の切り替えスイッチを与えたいだけ」なら select。この4つは互いに入れ子にできます。例えば url-test グループを select グループの選択肢の一つにすれば、自動優先を保ちつつ単一ノードを手動指定する退路も残せます。

また、振り分けグループの判定はプロキシ層の接続性と遅延のみを対象としており、ルールが実際にマッチしているか、DNS 解決が正しい出口を経由しているか、TUN モードでシステムのルーティングテーブルが有効になっているかといった他の要素は関知しません。振り分けグループを切り替えても問題が解決しない場合は、まず rules セクションが本当に対象のトラフィックをこのグループへ向けているかを確認し、それからテストアドレスや許容差のパラメータが適切かを見直すとよいでしょう。段階的に切り分けていくほうが、複数のフィールドを一度に変更するより問題箇所を特定しやすくなります。