CLASH 公式サイト · clashoffice.com
    高度な機能 2026-05-05 · 7分で読める

    負荷分散とフェイルオーバー:複数ノードのスマートなスケジューリング

    ポリシーグループ(proxy-groups)は「手動選択」だけではありません。url-testfallbackload-balance の3種類により、Clash が自動的にノードを選び、故障したサーバーを回避できるため、手動での切り替えの手間が省けます。

    4種類のポリシーグループの比較

    種類動作適した用途
    select手動選択で、クリックしたノードのみを使用特定のノードを固定して使いたい場合
    url-test定期的に速度測定し、遅延が最小のノードへ自動切り替え常に現在最速の回線を使いたい場合
    fallbackリストの順序で最初の利用可能なノードを使用し、現在のノードが故障した場合のみ次に切り替え明確な主系・待機系ノードの優先順位がある場合
    load-balance戦略に基づき複数ノードにリクエストを分散し、接続の負荷を分担ノード数が十分にあり、帯域幅の負荷を分担したい場合

    左右にスワイプして表全体を見る

    url-test:自動的に低遅延を追いかける

    url-test は設定された間隔でグループ内の全ノードに速度測定リクエストを送信し、遅延が最小のノードへ自動的に切り替えます。手動で速度測定ボタンをクリックする必要はありません。

    # config.yaml の一部 proxy-groups: - name: "自動選択" type: url-test proxies: [HK-01, SG-02, JP-03] url: "https://www.gstatic.com/generate_204" interval: 300

    url は速度測定時にリクエストする対象アドレスで、通常はレスポンスが軽いアドレスを使用します。interval は測定間隔(秒)で、頻繁すぎると不要なリクエストが増えるため、通常は数分に1回程度で十分です。

    fallback:主系・待機系のフェイルオーバー

    fallbackproxies リストに書いた順序で前にあるノードを優先的に使用します。現在使用中のノードの速度測定が失敗(利用不可)すると、リスト内の次に利用可能なノードへ自動的に切り替わり、主系ノードが復旧するまで続きます。「どのノードの回線が良く、どれが待機系か」を明確に把握している場合に適しています。

    load-balance:負荷を分散する

    load-balance は「最も良い1つを選ぶ」ことを目指すのではなく、異なるリクエストを複数のノードに分散させます。一般的な割り当て戦略には、接続の一致性ハッシュ(同一の宛先は常に同じノードを使用し、セッション断を防ぐ)とラウンドロビンがあります。複数のノードがあり、それらがある程度安定していて、帯域幅と接続数の負荷を分担したい場合に適しています。

    ヒント:これら3つの自動化タイプは互いに入れ子にして参照できます。例えば、まず url-test で香港のノードを「香港自動選択」というグループにまとめ、そのグループを他の地域グループと一緒に最外層の手動選択グループに入れることで、「まず地域を選び、グループ内では自動最適化」という効果を実現できます。

    よくあるチューニングの提案

    ポリシーグループを使い始めたら、いくつかの細部にも注意すると、自動スケジューリングの効果を期待に近づけられます。

    • 速度測定アドレスは軽量な対象を選ぶ:url フィールドには、レスポンスボディが非常に小さく帯域幅をほとんど消費しないアドレス(例:204ステータスを返すヘルスチェックエンドポイント)を使うことを推奨し、速度測定自体が過剰なトラフィックを消費しないようにします。
    • interval を適切に設定する:間隔が短すぎると、頻繁な速度測定リクエストでノードに負担をかけすぎてしまい、長すぎると故障の発見が遅れます。数分に1回が一般的な折衷案です。
    • tolerance(許容差):一部の実装では許容差の値を設定でき、新しいノードの遅延が現在のノードよりその差分以上低くなった場合のみ切り替えが発生し、遅延が閾値付近で揺れ動く際の頻繁な切り替えを防ぎます。
    • グループ内のノード数:load-balance グループ内のノード数が少なすぎると分散効果が目立たず、十分なノード数があってこそ「負荷分担」の価値が真に発揮されます。

    よくある質問

    なぜ url-test グループのノードが頻繁に切り替わるのか?

    これは通常、複数のノードの遅延が非常に近く、毎回の速度測定のわずかな変動だけで「最低遅延」の順位が変わってしまうためです。interval を適切に大きくするか、tolerance 許容差を使った設定にすることで、この頻繁な切り替えを効果的に減らせます。

    fallback グループのノードがすべて利用不可と表示される場合はどうすればいいか?

    まず速度測定アドレス自体が正常にアクセス可能かを確認してください。測定対象のアドレスがファイアウォールにブロックされていると、すべてのノードが誤って利用不可と判定されます。より安定していてアクセス数の少ない測定アドレスに変更するのも一つの方法です。

    select、url-test、load-balance を組み合わせて使えるか?

    もちろん可能で、むしろ推奨されるやり方です。ノードを地域ごとに複数の url-test サブグループに分け(例:「香港自動選択」「日本自動選択」)、最外層に select グループを置いて地域を手動で選ぶことで、手動制御の柔軟性を保ちながらグループ内の自動最適化の利便性も享受できます。

    まとめ

    1〜2個のノードしかない場合は、select による手動切り替えで十分です。ノード数が増えたら、url-test は手動での速度測定と切り替えの手間を省き、fallback は明確な主系・待機系関係がある場面に適し、load-balance は品質が近い複数のノードに負荷を分散させるのに適しています。

    読み終わったら試してみませんか?

    5大プラットフォームのインストーラーはダウンロードページに掲載されています。チュートリアルページの手順に沿って進めればすぐに使えます。

    ダウンロードページへ
    ブログ一覧に戻る
    まだ Clash をダウンロードしていませんか?タップして公式ダウンロードページへ