Clash Meta の load-balance ポリシーグループ：一貫性ハッシュとラウンドロビンを YAML で設定する

load-balance が扱うトラフィックのイメージ

ポリシーグループは、ルール側から見るとひとつの名前にまとまった「出口の束」です。select はユーザーが手で選んだ一本を使い続け、fallback はリスト上から生きている先頭へ寄せ、url-test は測定結果で勝者を入れ替えます。一方 load-balance は、同一グループに属する複数プロキシを並行して利用し、接続やフローを分散します。ダウンロードや多タブ閲覧のように同時接続が増える状況で、一本あたりのピークを下げたいときの選択肢になります。

分散のしかたは strategy で決まります。round-robin は順番どおりに割り振るイメージで、全体としては均等に近づきやすい反面、リクエストごとに出口 IP が変わりやすいため、サービス側が IP を強く見る場合は副作用が出ます。consistent-hashing は、宛先のアドレスやホスト名などをハッシュに載せてノードを決める方式が中心で、同じサイトへの接続が同じ中継に寄りやすくなります。ログインセッションや API のレート制限、ゲームのリージョン判定などでは、まず consistent-hashing を検討するのが無難なことが多いです。

consistent-hashing と round-robin の使い分け

strategy	向いている場面	注意点
consistent-hashing	同一ドメインへの長めのセッション、SaaS・銀行・開発者向け API、IP を変えたくないストリーミング検証など。	ノードを増減するとハッシュ空間が変わり、一部宛先の割当が入れ替わることがあります。
round-robin	短い GET を大量にばらまきたい、総スループット優先で IP の一貫性が問題にならないバッチ用途など。	接続ごとに別出口になりやすく、WebSocket や OAuth の途中で経路が不安定に見えることがあります。

ステップ1：YAML の proxy-groups に定義を足す

購読で proxies: がすでにある前提で、実在するプロキシ名だけを proxies: 配下に列挙します。名前は購読更新で変わりうるため、UI 上の表記と一字一句そろえる必要があります。グループの name はルールから参照するので、絵文字や記号を多用すると他端末でコピペしづらくなる点にだけ注意してください。

# Illustrative proxy-groups — replace names with your subscription
proxy-groups:
  - name: "LB-DOWNLOAD"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

url と interval は、url-test／fallback と同様にヘルスチェック用のプローブ先と周期を指定する文脈で使われます。テスト先がブロックされると全候補が不健康扱いになりかねないので、自宅回線やプロバイダのフィルタに合わせて URL を選びます。lazy: true は、グループが実際に選ばれるまで積極的に全体を測り回さない挙動を期待する設定で、ノード数が多いプロファイルでは起動直後の負荷を抑えやすいです。UDP を意図的に避けたい場合は環境によって disable-udp などのフラグが用意されていることがあり、公式の設定例に追随してください。

入れ子グループ：冗長性だけ別立てにする

proxies の要素には単一プロキシだけでなく、別のポリシーグループ名も置けます。たとえば負荷分散の下層に地域別の select を置く、あるいは上層を fallback にして「まず load-balance のプール、ダメなら別系統へ」という二段構えにする、といった合成が可能です。その場合でも名前解決やルール順の整合を崩すと想定外の経路に落ちるので、MATCH より手前に用途別ルールを置く方針は他の記事と同様です。ルールセットの更新タイミングは rule-providers の path と interval で整理できます。

ステップ2：rules からポリシー名を指す

ルールの最後の列（ポリシー列）に、proxy-groups の name と同じ文字列を書きます。例では LB-DOWNLOAD です。

# Example rules fragment — order matters (first match wins)
rules:
  - DOMAIN-SUFFIX, example-cdn.net, LB-DOWNLOAD
  - DOMAIN-SUFFIX, large-file.host, LB-DOWNLOAD
  - MATCH, GLOBAL

評価は上から順に一本だけマッチします。意図せず広いルールが先にあると、load-balance グループに届かないので、分割したいドメインは具体的な行を上へ、緩い GEOIP や MATCH は下へ、という並べ方が安全です。IPv6 だけ別経路にしたい等の要件がある場合は、ルールタイプと DNS の挙動をセットで確認してください。DNS 周りの切り分けは 接続できない症状と DNS が参考になります。

運用：ログ確認とつまずきどころ

反映後は、接続ログでマッチしたルール名・ポリシー名・実ノードが期待どおりかを見ます。負荷分散が効いているように見えても、実際は短周期で url-test グループへ寄っている、といった別ルールの取りこぼしがないかを疑います。大きなファイルの取得で途中から遅くなった場合、片方のノードだけ帯域枯渇していないか、ヘルスチェック URL 自体がタイムアウトしていないかも切り分けポイントです。

consistent-hashing で「特定サイトだけ別ノードに載せ替わった」現象は、クリーンアップ後に候補リストの順序やメンバーが変わったときに起きやすいです。安定を最優先するなら、分散に載せるメンバーを品質の近い少人数に絞り、増減は計画的に行う方がトラブルが少ない傾向があります。

チェックリスト

よくある質問

consistent-hashing と round-robin はどちらをデフォルト想定すればよいですか？

用途を切らないなら、まず consistent-hashing から試すのがおすすめです。宛先単位で同じノードに寄せやすく、人間が感じる「急に別国からアクセスされた」系の不整合を減らしやすいからです。総量だけ測りたいベンチや、IP を気にしない短いフェッチなら round-robin を検討します。

自動選局の url-test とは併用できますか？

別々のグループとして併存は可能です。例として、普段のブラウザは url-test の「自動最速」グループへ流し、大容量取得だけ load-balance に寄せる、といった用途分離がわかりやすいです。同じトラフィックに二重の自動切替を重ねすぎると挙動が追いにくくなるので、命名とルールを単純に保つことが重要です。

購読を更新したら動かなくなりました

ノードの改名・削除に load-balance 側が追随していない典型例です。購読マージや カスタム proxies の合成を使っている場合も、最終的に解決される名前を確認してください。固定のグループ名を維持し、中身のリストだけ整えると運用が楽です。

まとめ

load-balance は、複数出口を同時に使って負荷を散らすためのポリシーグループです。consistent-hashing は宛先との対応を安定させやすく、round-robin は順番割付で均等化しやすい一方、IP の揺れに弱いユースケースがあります。proxy-groups に追記し、rules のポリシー列に同じ name を指す——この二点ができれば基本的な取り付けは完了です。ヘルスチェック URL とルール順だけは長期運用で必ずずれるので、定期的にログを見る習慣を続けてください。

GUI だけのプリセットに縛られると、「分散したいのに常に一本に寄る」「ルールの順序がブラックボックスでデバッグできない」といった壁に当たりやすいです。商用クライアントによってはプロファイルの差分が見えにくく、アップデートで対応コアが遅れることもあります。

設定ファイルを丁寧に読めるスタックでは、ポリシーグループとルールの関係をそのまま追跡でき、load-balance のような高度な型も文脈の中で扱えます。YAML が長くなっても名前付けと配置の意図を保ちやすいので、成長するルールセットに向いています。Clash はオープンに設定を扱いやすく、load-balance を含むポリシーグループや DNS、TUN まで一つの文脈で設計できるため、中長期のホームプロキシとして扱いやすいです。

自分のルールで挙動を確かめたい方は、 Clash を無料ダウンロードして試してみてください。