Clash 策略グループ url-test・fallback・load-balance の違いと設定方法

Clash と Clash Meta(mihomo コア)の proxy-groups には、手動選択の select のほかに、3種類の自動策略グループタイプ url-test、fallback、load-balance が用意されています。いずれもグループ内のノードに対して定期的にヘルスチェックを行いますが、その結果の使われ方はまったく異なります――一方は最速ノードを選ぶため、もう一方は接続可能なノードを確保するため、残りは通信を複数ノードに分散させるためのものです。この違いを理解せずにネットの設定例をそのまま流用すると、「自動測速を設定したはずなのに、なぜか同じ遅いノードを使い続けている」といった混乱が起きがちです。本記事ではタイプ別にパラメータを解説し、そのまま使える YAML の書き方を紹介します。

3種の自動策略グループが解決する課題は異なる

まず前提として、これら3種の策略グループはいずれもグループ内に少なくとも2つ以上の有効なノードがある場合に意味を持ちます。ノードが1つしかないグループでは select と実質的な違いはありません。核心的な違いは「どのノードを選ぶか」の判断ロジックです。

• url-test:グループ内の各ノードに定期的に測速リクエストを送り、遅延が最も低い1つを現在の出口として選択します。目標は「常に最速の経路を使う」ことです。
• fallback:設定内のノードの順序に従って可用性を順にチェックし、最初に検証をパスしたノードを使用します。現在のノードが失敗したときのみ次のノードへ切り替えます。目標は「接続可能なノードを確保する」ことで、速さより安定性を重視します。
• load-balance:「どれが最良か」を判断せず、アルゴリズムに従ってリクエストをグループ内の複数ノードに分散させます。目標は「通信を分散させる」ことで、単一ノードへの長期的な負荷集中や狙った制限を避けます。

どのタイプを選ぶかは、遅延・安定性・負荷分散のどれを重視するかによって決まり、3つは互いに代替できるものではありません。

url-test:遅延優先の自動経路選択

url-test は最も一般的な自動策略グループタイプで、「手元に複数のノードがあり、手動切り替えはせず常に遅延が最も低いノードを使いたい」という場面に適しています。典型的な書き方は次のとおりです。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港01
      - シンガポール02
      - 日本03
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

主なフィールドの説明:

• url:測速リクエストの宛先アドレス。通常は海外からアクセス可能な軽量なエンドポイントを使い、リクエストが成功すればノードは有効、応答時間が遅延値とみなされます。
• interval:測速の周期で単位は秒。周期が短すぎるとノードへの検査負荷が増え、長すぎると遅延変化への切り替えが遅れます。一般的には 180〜600 の範囲がよく使われます。
• tolerance:許容差で単位はミリ秒。新たに測定した遅延が現在のノードよりこの許容差以上低くなった場合のみ切り替えが発生します。許容差を設けることで、遅延が数ミリ秒単位で揺れるだけで出口が頻繁に切り替わり、接続が繰り返し途切れることを防ぎます。
• lazy:true の場合、そのグループが実際に使用されているときのみ定期測速を実行し、選択されていない間は検査を止めることで不要なリクエストを減らします。

fallback:可用性を確保するための予備切り替え

fallback の位置づけは「主・予備」であり、「最良を選ぶ」ものではありません。proxies リストの順序に従って先頭から検査を行い、現在使用中のノードが接続可能である限り、後方にある遅延の低いノードへ自発的に切り替えることはありません。現在のノードの検査が失敗した場合のみ、順に次の有効なノードを探します。設定例は次のとおりです。

proxy-groups:
  - name: 予備リンク
    type: fallback
    proxies:
      - メインノード-上海中継
      - 予備ノード-東京直結
      - 予備ノード-ソウル直結
    url: http://www.gstatic.com/generate_204
    interval: 180

fallback には tolerance パラメータがありません。遅延の高低を比較するのではなく、「つながる」か「つながらない」かだけを判断するためです。このタイプは接続の安定性を重視し、ノードが頻繁に切り替わってほしくない場面――例えば長時間バックグラウンドで動作するダウンロードタスクやセッション維持が必要なサービス――に適しています。リストの順序がそのまま優先順位となるため、最も安定していて重視するノードを先頭に置きます。

load-balance:複数ノードへの負荷分散

load-balance は「最良を選ぶ」のではなく、リクエストをグループ内の複数ノードに分配します。スペックの近い複数ノードを同時に運用し、単一ノードへの長期的な高負荷を避けたい場面で使われます。設定例:

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

strategy は割り振りアルゴリズムを決定し、代表的なものは2種類です。

• consistent-hashing:送信元アドレスと宛先アドレスのハッシュ値に基づいてノードを割り振ります。同じ接続セッションは有効期間内に同じノードを使い続けるため、セッション維持が必要な場面(出口 IP の一致に依存するログイン状態のサイトなど)に適しています。
• round-robin:順番に従って交互に割り振り、新しい接続は順に次のノードへ渡されます。分配はより均等になりますが、同じ宛先が常に同じノードを通ることは保証されません。

load-balance も定期的にノードの可用性を検査し、無効になったノードは一時的に割り振り対象から外され、回復後に再び組み込まれます。url-test との本質的な違いは、url-test が常に「現在最良」の1つのノードだけを使うのに対し、load-balance は複数ノードを同時に使ってリクエストを分担する点です。

パラメータ早見表とよくある誤解

陥りやすい落とし穴:

1. fallback グループ内のノード順序を逆に書いてしまい、遅延の高い予備ノードが優先的に使われてしまう――fallback は遅延を比較せず、リスト順序と現在のノードが失効しているかどうかしか見ません。
2. tolerance を 0 に設定すると、url-test グループは新しい測速で1ミリ秒でも速いノードがあれば即座に切り替わってしまい、出口が頻繁に変動します。最低でも 30〜50 ミリ秒程度の許容差を残すことを推奨します。
3. load-balance に遅延差の大きいノードを混在させる(例:高遅延の中継ノードと低遅延の直結ノードを同じグループに入れる)と、分散したことで単一の最良ノードを選ぶよりも体感が悪化することがあります。スペックの近いノードを組にするのが適しています。
4. interval を短く設定しすぎる(例:10秒以内)と、ノードへの検査リクエストが頻発し、一部のサービス提供元や自前ノードのサーバー側がレート制限をかける可能性があります。120秒以上を推奨します。

3種の策略グループはどう選ぶべきか

一言でまとめるなら、遅延を優先するなら url-test、安定性を優先するなら fallback、分散を優先するなら load-balance です。実際の運用では3つを組み合わせることもできます――例えば url-test グループを日常の出口とし、別に安定した直結ノードを数個並べた fallback グループを用意して、長時間接続が必要な場面(ダウンロードツールやリモートデスクトップなど)向けにルールで個別に振り分ける、といった方法です。策略グループのタイプを決めたうえで、ルールセットと組み合わせて異なるドメイン・アプリを異なる策略グループに振り分けることで、完結した分流ロジックになります。策略グループ自体は「このカテゴリの通信をどのノード(群)に流すか」という問題を解決するものです。