Clash 策略グループ比較:url-test・fallback・load-balance はどんな場面に向く?

01・出発点

3種類の策略グループは同じ課題を解決するものではない

Clash や Clash Meta(mihomo コア)の設定ファイルに初めて触れると、proxy-groups の type フィールドを「とりあえず自動モードを選んでおけばいい」というスイッチのように扱い、 うまくいかなければ別のタイプに変えて試す、というやり方をしてしまいがちです。この試行錯誤自体は動きますが効率が悪く、 タイプの選択を間違えるとむしろ別の落とし穴にはまることもあります。たとえば低遅延を狙っていたのに「使えればOK」に近い fallback を選んでしまい、遅延が改善しない。あるいは帯域の負荷を分散させたかったのに url-test を選んでしまい、 結局は測定結果が最速の1〜2ノードに通信が集中してしまう、といった具合です。

3つの中核的な違いは、まず一文でまとめると次のようになります。

• url-test:「どれが一番速いか」を重視し、継続的に測定して遅延が最も低いノードへ自動的に切り替える。
• fallback:「どれが使えるか」を重視し、設定順に最初の健全なノードを使う。最速を積極的に追求しない。
• load-balance:「どう分けるか」を重視し、並行するリクエストをアルゴリズムで複数ノードに分散させる。単一の最適解を求めるものではない。

以下ではそれぞれの判定ロジックと主要パラメータを分解していきます。ロジックを理解すれば、タイプ選びは基本的に試行錯誤に頼らずに済むはずです。

02・url-test

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

url-test はグループ内の各ノードに対して周期的に HTTP リクエストを送信し(送信先は url パラメータで指定)、応答時間をそのノードの遅延値として記録した上で、 現在の通信を遅延が最も低いノードに切り替えます。「パネル上に自動測定ノードの遅延が表示される」といったUI機能の 裏側で最もよく使われる実装であり、多くの人が最初に触れる自動策略グループはこのタイプであることが多いです。

主要パラメータの説明:

tolerance は見落とされがちですが体感に直結するパラメータです。許容差を設定しないと、 2つのノードの遅延差が1ミリ秒でもあれば切り替えが発生し、頻繁な切り替えは長時間接続(動画再生やダウンロードなど)の 切断・再接続を招きます。50ms 前後の許容差を設定するのは、クライアントに「差が微妙なら切り替えない」と伝えることに等しく、 接続の安定性を得る代わりに理論上の絶対最適は多少犠牲にする、というトレードオフになります。

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

向いている場面:遅延に敏感で、単一ノードで帯域要件を満たせる用途。たとえばウェブブラウジング、 チャットアプリ、ゲームの高速化など。url-test は積極的に分散を行わず、通信は基本的にすべて同じ「現在最適な」ノードを 通ります。この点は load-balance とは正反対です。

03・fallback

fallback:可用性を優先するバックアップ機構

fallback もグループ内のノードに対して健全性チェックを行いますが、判定ロジックは 「最速を選ぶ」ではなく「順番に最初の使えるノードを探す」というものです。設定内の proxies リストの並び順がそのまま優先順位になります。クライアントは先頭のノードから試し、そのノードが健全性チェックを 通過している限り(同じく url パラメータで接続を判定)、そのまま使い続けます。 後方のノードの遅延が低くても、それを理由に切り替えることはありません。現在のノードが不可用と判定された場合のみ、 順に次のノードを試します。

proxy-groups:
  - name: 安定バックアップ
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 180
    proxies:
      - メインノード-専用線
      - バックアップ-香港
      - バックアップ-日本

向いている場面:明確な「第一候補ノード」がある場合(専用線、自前の中継サーバー、社内ネットワークの出口など)。 それが切断された時だけ自動的にバックアップ経路へ切り替えたいが、複数ノード間で頻繁に遅延を比較させたくない、 というケースに向いています。速度より接続の安定性が優先される場面によく見られ、長時間の接続維持が必要な リモート会議や、パケットロスに敏感な音声通話、または特定の1本の経路しか信頼しておらず他のノードは緊急用の バックアップに過ぎない、といった状況でも使われます。

注意点として、interval は健全性チェックの頻度を決めます。間隔を長く設定しすぎると、 ノードが既に使えなくなっていてもクライアントが気づかず、一定時間接続失敗が続くことがあります。逆に短すぎると 不要な検査トラフィックとコストが増えます。一般的には 120〜300 秒程度が比較的バランスの良い範囲です。

04・load-balance

load-balance:通信を分散させる負荷分散

load-balance の目的は「最適な1ノードを選ぶ」ことではなく、異なる接続リクエストを グループ内の複数ノードに分散させ、通信が長期的に単一の出口へ集中することを避けることです。 strategy パラメータで分配アルゴリズムを決めます。よく使われるのは次の2種類です。

• consistent-hashing(コンシステントハッシュ):接続元アドレスなどの情報からハッシュ値を計算してノードを割り当てる方式。同じ送信元からの接続は高い確率で同じノードに固定され、セッション維持が必要な場面に向く。
• round-robin(ラウンドロビン):新しい接続を順番に次のノードへ割り当てる方式。分配はより均等になるが、同じ送信元からの接続が常に同じノードへ行くとは限らない。

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

向いている場面:単一ノードの帯域や同時接続数が上限に達しやすい場合。たとえば複数デバイスで同じサブスクリプションを 共用している、ダウンロードタスクが多い、あるいはノード自体に同時接続数の制限がある、といったケースです。 通信を複数ノードに分散させることで単点にかかる負荷が下がり、全体のスループットは1ノードの帯域上限に頭を抑えられる のではなく、複数ノードの帯域の合計に近づきやすくなります。

05・比較

3タイプのパラメータと使用シーン一覧

実際の設定ファイルでは、この3タイプは組み合わせて使うことができ、「どれか1つを選んで最後まで使う」ものではありません。 たとえば fallback を最も外側の総合入口として置き、バックアップ経路自体がさらに url-test グループになっていて、 複数の海外ノードの中から最速を選ぶ、という構成があります。また、ダウンロードツールだけを個別に振り分けるルールを 別途用意し、それを load-balance グループに向けることで、大容量ファイルのダウンロードが1つのノードの帯域を 占有し、他のアプリの利用体験に影響するのを防ぐ、という設計もよく見られます。このような階層設計は単一の策略グループより 実際の利用シーンに近く、他人が共有している複雑な設定ファイルを見るとよく登場する構造です。

もう一つ見落とされがちな点として、url パラメータが指す検査用アドレス自体が不安定だったり 帯域制限を受けていたりすると、3種類の策略グループの判定結果に直接影響します。url-test は実際より高い遅延を 測定してしまい、fallback はノードを誤って不可用と判定する可能性があり、load-balance の健全性チェックも 正確でなくなります。軽量で応答が速く、広く到達可能な検査用アドレスを選ぶことは、この3種類の自動策略グループが いずれも正常に機能するための前提条件であり、「自動選択の結果がおかしい」といった問題を調査する際には、 検査用アドレス自体の可用性もチェックリストに入れておくべきです。