本稿のゴールと前提
ここでは proxies: に実ノード（購読由来でも手動でも可）が並んでいる前提で、その上に載るポリシー・グループだけを扱います。ドメイン集合や国情報でどこをプロキシに送るかは GEOIP／GEOSITE 分流、ルールの当たり順の話は ルール順・優先度の稿 に譲ります。いま知りたいのは「そのプロキシ欄に、複数ノードをどう割り当てるか」というレイヤーです。
url-test は測定結果に基づきだいたい一つに寄せやすく、fallback はリスト順に生きている先頭へ寄せます。対して load-balance は、戦略に応じて負荷を複数出口に振るか、フローのキー（先の集合など）から一貫して同一出口を選ぶ方向の挙動を期待します。混同しやすいので、まずは用途で型を分けると YAML が読みやすくなります。
load-balance の考え方（url-test／fallback との違い）
ざっくり言うと、「最速の一匹を選ぶ」なら url-test、「主回線が死んだら予備へ」なら fallback、「複数線を同時に使う設計」や「接続先ごとに出口を固定して振れ幅を抑える」なら load-balance を検討します。ここで言う「固定」は、アプリケーションのセッション管理とは別物で、あくまでプロキシ選択アルゴリズムの安定性の話です。銀行アプリや厳しい CAPTCHA 環境では、単一ノードの select の方が摩擦が少ない場面もあります。
整理：load-balance は「冗長化」とは別次元です。ノードが同時多発で不安定なときは、fallback や url-test と組み合わせた二段構え（入口の自動選択／出口の分散）も検討されますが、プロファイルが複雑になるのでログでの検証をセットにしてください。
ステップ1：round-robin で順番に振る
strategy: round-robin は、新しい接続（やフロー単位の割当）を候補リストの順にローテーションしやすい挙動です。体感としては「負荷をならして使いたい」「単一ノードへの集中を避けたい」というモチベーションが近いです。一方で、同じウェブサイトへの再読み込みや複数タブが別の出口に乗ると、表示上の地域やクッキー周りで挙動がブレることがあるので、想定トラフィックで試すのが安全です。
次のスケッチでは、環境に合わせて NODE-* を実在のプロキシ名に置き換えてください。利用中の Mihomo 版で廃止・追加キーがないか、公式ドキュメントもあわせて確認するのが確実です。
# Sketch — round-robin; replace proxy names; align with your core version
proxy-groups:
- name: LB-ROUND-ROBIN
type: load-balance
strategy: round-robin
proxies:
- NODE-A
- NODE-B
- NODE-C
購読の自動更新でノード名が変わると、このリストへ書いた文字列参照が静かにズレる典型パターンは url-test 時と同じです。更新直後に YAML の実名と GUI 表示を突き合わせてください。購読まわりの切り分けは 購読更新の 403／タイムアウト稿 も参考になります。
ステップ2：consistent-hashing で「同じ先は同じ出口」に寄せる
strategy: consistent-hashing は、入力（多くのケースでは転送先のアドレスや識別子を材料にしたハッシュ）から候補集合への写像を一貫させる方式です。結果として、同じ接続先に対しては同じプロキシが選ばれやすいため、ロードバランシングの文脈では「ある種の粘着」のように語られることがあります。ただしハッシュ環が変わると写像も変わるため、後述のとおりリストの並び替えやノードの増減には敏感です。
# Sketch — consistent hashing; replace proxy names
proxy-groups:
- name: LB-STICKY-HASH
type: load-balance
strategy: consistent-hashing
proxies:
- NODE-A
- NODE-B
- NODE-C
HTTPS で接続ログ上が IP 表示のままだと、ルールや Sniffer まわりの設計次第で想定と違うキーに見えることがあります。ドメインで読みたいなら、必要に応じて Sniffer 稿 や DNS 側の整合を DNS リーク防止稿 で揃えます。
ヘルスチェックについて（短く）
一部の環境・バージョンでは load-balance にも url や interval を併記し、不通ノードを選考から外すような運用が可能です。具体的な既定値や追加キーは版差が出やすいため、本稿では深掘みしません。測定と自動切替そのものを主題にしたい場合は、url-test／fallback 稿 のパラメータ解説・確認手順を先に読むと接続がスムーズです。
ルール側とつなぐ
load-balance グループを書いただけでは、ルールの PROXY 相当がそのグループ名を指していなければ使われません。MATCH より上の行で別ポリシーに落ちている場合も多いので、ルール順 を疑ってください。また GEOIP,CN,DIRECT などが先に当たると、国内向けフローは自動グループに届きません。国情報まわりは GEOIP 稿 を参照してください。
二段の出口を積みたい場合は relay の話になります。負荷分散とチェーンの順路固定は目的が違うので、relay チェーンの稿 と設計を分けて考えると混乱が減ります。
効いているかの確認
- 設定読込：YAML 文法エラー、存在しないプロキシ名の参照がないか。
- ルール命中：対象アプリのフローが、想定のグループ名へ流れているか（ログで確認）。
- 戦略の体感：
round-robinなら複数サイト・複数接続で出口がローテーションしやすいか、consistent-hashingなら同一ホストへの接続が同じノードに寄りやすいか。 - 購読更新後：ノード名の変化でグループが空振りしていないか。
外部ダッシュボード（yacd 系など）で観察する場合は、External Controller と yacd の稿 に沿って権限とバインド先を絞ってください。
よくあるつまずき
- リスト順やメンバ増減：
consistent-hashingは環の変化で写像が変わり、以前と同じ出口にならないことがあります。 round-robinと Web サービスの相性：同一サービスでも接続が別ノードに乗ると、地域表示やレート制限体感が揺れます。- UDP／長時間接続：アプリやプロトコルによっては、UDP やキープアライブの挙動が想定とズレることがあります。音声通話などは Discord／UDP／TUN の稿 も参照してください。
- 手動
selectの上書き：GUI で別の階層を選んでいないか。ルールが別グループを指していないか。
注意：複数ノードへ分散するとトラフィック量も分散します。利用規約・職場方針・プロバイダのポリシーに反しない範囲で設計してください。
ドキュメントと入手先
細かなキー群は利用中の Mihomo 版公式ドキュメントを最終判断にしてください。日々のクライアント入手は 公式ダウンロードページ を第一にし、用語の整理には ドキュメント・チュートリアル も使えます。ソースや Issue は GitHub で追えますが、インストーラの主たる入口はサイト側と取り違えないようにすると安全です。
まとめ
Clash Meta／Mihomo で複数ノードに振り分けたいときは proxy-groups に type: load-balance を置き、strategy で round-robin（順番に回す）と consistent-hashing（同じ接続先に同じ出口を寄せやすい）を選び分けます。url-test／fallback が得意な「測って切り替える／主備で逃がす」用途と棲み分けし、ルール命中と DNS を同じセッションで揃えると、設定が正しくても不調に見える落とし穴を避けられます。
GUI のラベルはクライアントごとに違っても、最終的に大事なのはYAML 上の名前と戦略が意図どおりかという一点です。ルールとポリシーの見通しが立つクライアント群では、まず小さな load-balance グループを一つ試し、ログで振る舞いを確かめてから本番ルールへ載せるのが、2026年現在もっとも事故の少ない伸ばし方です。
周辺ツールに比べ、プロファイルをテキストで共有しやすいのも Clash 系の強みです。その強みを活かして、分散と安定性のバランスを自分の回線に合わせて調整してください。
→ Clash を無料ダウンロードし、load-balance や consistent-hashing を含む Mihomo プロファイルを試す