Clash のポリシーグループ選び方:url-test・fallback・load-balance を徹底解説

設定ファイルにおけるポリシーグループの位置づけ

Clash のノード振り分けは proxy-groups という設定セクションに依存しています。proxies に列挙された個々のノードを「論理的な出口」としてまとめ、ルールセクション rules が参照するのは特定のノードではなく、このポリシーグループの名前です。これにより、プロバイダやノードを変更する際は proxies と proxy-groups だけを書き換えればよく、ルール自体は一行も触る必要がありません。

各ポリシーグループは type を1つ指定する必要があり、これがクライアントが「このグループ内でどうノードを選ぶか」を決めます。よく使われるのは select(手動選択)、url-test(自動速度測定)、fallback(フェイルオーバー)、load-balance(負荷分散)の4種類です。select は最もシンプルで完全に手動切り替えのため本稿では扱いません。残りの3つはいずれも「自動判定」ロジックを持ち、誤用されやすい代表格でもあるので、以下で1つずつ解説します。

url-test:遅延に基づく自動速度測定

url-test は3つの自動タイプの中でもっとも一般的です。その動作は次のようにまとめられます:クライアントが一定周期でグループ内の各ノードに対して1回 HTTP リクエストを送り(宛先は url フィールドで指定)、往復の遅延を記録し、その時点で最も遅延が低いノードへ常にトラフィックを流します。

主要フィールドの説明:

• url:測定先の URL。海外から到達可能で応答が速いアドレスを指定するのが一般的で、接続確認によく使われる軽量なエンドポイントなどが該当します;
• interval:測定周期(秒)。300 秒(5分)前後が一般的で、短すぎるとノード側の負荷が増え、長すぎると遅延変化への追従が遅れます;
• tolerance:切り替えの許容差(ミリ秒)。新しいノードの遅延が現在のノードよりこの許容差以上低くならない限り、実際には切り替えは行われません。これにより2つのノード間で遅延が僅差で揺れて接続が頻繁に再構築される事態を防ぎます;
• lazy(Clash Meta/mihomo 対応):有効にすると、実際にリクエストが発生したときにのみ速度測定が走るようになり、トラフィックの有無にかかわらず周期的に空測定を続けることがなくなります。長時間起動しっぱなしで接続数が少ない用途に向いています。

適した場面は明確です:プロバイダが提供するのが同質な中継ノード群(たとえば同一回線の複数出口)で、どの経路を通るかは気にせず遅延が最も低ければよい、という場合です。欠点もそこにあります——url-test は遅延しか見ておらず、パケットロス率や実際のスループットは判断材料に入りません。遅延は低いのに帯域制限がきついノードがあっても、速度測定の段階ではまったく見抜けません。

fallback:順序探索によるフェイルオーバー

fallback のロジックは url-test とは完全に異なります。遅延の高低を比較するのではなく、proxies リストに書かれたノードの順序に厳密に従って可用性を1つずつ確認します。最初のノードが接続できる(探索リクエストが成功する)限りそれを使い続け、現在使用中のノードの探索が失敗したときだけ、次に接続できるノードへ順位どおりに切り替わります。

つまり fallback は本質的に「主・副」の意味合いを持ちます——あらかじめノードの順序を計画し、最も使いたいメインノードを先頭に、バックアップノードをその後に並べておく必要があります。主要フィールドは url-test とほぼ同じ(url、interval、tolerance)ですが、切り替えの判断基準が「遅延の差」ではなく「接続できるかどうか」であるため、fallback における tolerance の役割は限定的です。

典型的な用途:安定した自前ホストのノードをメインとして使い、プロバイダのノードを1~2個バックアップとして残しておき、通常は自前ノードを優先的に使い、自前ノードに問題が起きた(切断された、規制されて到達不能になった)ときだけ自動的にバックアップ経路へ移る、というケースです。この「主があり副もある、必要に応じて引き継ぐ」というニーズには url-test より fallback のほうが適しています——url-test はバックアップノードが一度でも遅延が低く測定されただけで切り替わってしまいますが、fallback はメインノードが通じている限り動きません。

load-balance:接続を分散する負荷分散

load-balance が解決するのは別種の課題です。グループ内の複数ノードの性能が近く、すべて利用可能な場合に、全トラフィックを1つのノードに集中させず、並行接続を複数ノードに分散させたいというケースです。核となるフィールドは strategy で、よく使われる値は2種類あります:

• consistent-hashing:リクエスト先アドレスに基づいて一貫性ハッシュを行い、同一の宛先ドメイン/IP は高確率で同じノードに固定的に振られます。これによりノード切り替えによる接続断が減り、セッションの継続性が求められる場面(動画再生、大容量ファイルのダウンロード中など)に向いています;
• round-robin:ラウンドロビン順に新規接続を各ノードへ順番に割り振ります。分散はより均等になりますが、同じ宛先アドレスへの前後2回のリクエストが別々のノードに振られることもあります。

load-balance も url と interval によるヘルスチェックに対応しており、利用不可と判定されたノードは一時的に割り振りプールから除外され、復旧後に再び組み込まれます。強調しておきたいのは、load-balance が分散するのは「接続数」であり、リアルタイムの帯域という意味での「帯域幅」ではないという点です。グループ内のあるノードの帯域上限がそもそも低ければ、そのノードに割り振られた接続は依然として遅くなります。負荷分散は単一ノードの性能不足を補ってはくれません。

3つのタイプ、どう選ぶか

3つを並べて比較すると、選び方は一言に要約できます——解決したいのが「最速を選ぶ」「主・副を守る」「並行接続を分散する」のどれかを見極めることです。

• グループ内のノードの回線が近く、純粋に遅延を最適化したい → url-test を使う;
• 明確なメインノードとバックアップノードがあり、通常はメインを優先し障害時のみ切り替えたい → fallback を使う;
• グループ内のノード数が多く、並行接続を分散して単一ノードへの負荷集中を避けたい → load-balance を使う;
• 自分で手動切り替えするだけで自動ロジックは不要 → 最も基本的な select を使う。

実際の設定では、これらのタイプはしばしば入れ子で使われます。外側で select を使い、ユーザーが「自動速度測定」「固定回線」「全ノード手動選択」の間で切り替えられるようにし、内側の「自動速度測定」の選択肢自体を1つの url-test グループにする、という構成です。これにより自動化を保ちながら、手動でのフォールバックの柔軟性も失われません。

そのまま使える設定例

以下は3つのタイプそれぞれの最小構成例です。proxies 内のノード名を必要に応じて書き換えれば、そのまま config.yaml の proxy-groups セクションに貼り付けて使えます。

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

  - name: "主・副切り替え"
    type: fallback
    proxies:
      - "自前メインノード"
      - "プロバイダのバックアップ1"
      - "プロバイダのバックアップ2"
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "均等分散"
    type: load-balance
    proxies:
      - "ノードA"
      - "ノードB"
      - "ノードC"
      - "ノードD"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

Clash Meta(mihomo)コアはこれに加えて max-failed-times(何回連続で探索に失敗したら利用不可と判定するか。偶発的なネットワークの揺れによる誤判定を減らすためのもの)と lazy パラメータをサポートしています。クライアントが Meta コアのルールセットに対応していると明記されていれば、これら2つのフィールドを追加してさらに調整できます。オリジナルの Clash コアはこれらのフィールドを認識しないため、記述してもエラーにはなりませんが効果もありません。

よくある誤りとトラブル対処のヒント

ポリシーグループを設定する際によく踏む落とし穴:

1. 遅延の差が大きいノードを同じ load-balance グループに混在させる——負荷分散は遅延を選ばないため、遅いノードにも普通に接続が割り振られ、体感は url-test より悪くなることがある;
2. fallback グループ内のノード順序を逆に書いてしまい、メインノードが後ろに置かれ、普段優先的に使われるのがバックアップ回線になってしまう;
3. url-test の tolerance を小さすぎる値(0 や 5ms など)に設定する——ノードの遅延はそもそも変動するものであり、許容差が小さすぎると頻繁な切り替えを招き、接続が何度も途切れる;
4. 測定先の url に日本国内から直接到達できるアドレスを選んでしまい、すべてのノードで測定される遅延が近くなり、ノードの優劣を区別する意味がなくなる。

ポリシーグループのタイプとパラメータをうまく組み合わせておけば、ルールセクションの記述はずっと楽になります——ルールは「どのポリシーグループを通すか」だけを考えればよく、具体的にどのノードを通すか、いつ切り替えるかは、ポリシーグループ自身の判断ロジックに委ねられているからです。これこそが Clash の振り分け体系においてルールとノードを分離する本質的な価値です。