Clash ポリシーグループの負荷分散：load-balance と consistent-hashing（一貫ハッシュ）の書き方

1. なぜ url-test だけでは足りないのか

url-test と fallback の違いを押さえたうえで、ざっくり言うと url-test は 「いま遅延が小さい 1 ノードを 1 つ選び、同じ出口を多くの接続に使い回す」方向の挙動が基本です。一方、BitTorrent 風のクライアントや、複数スレッドで並列取得する大容量ダウンロード、ブラウザの同時接続数が多いケースでは、その「単一の選ばれたノード」に帯域が集約され、サーバや回線の片側にだけ負荷が乗ることがあります。

さらに、同じ接続元（クライアント側）から出る流れを、毎回同じプロキシに固定したい（セッションやログイン都合、あるいは接続先サーバのレート制限と相性を取る）一方で、別の元アドレスや別接続同士はバラしてよい、といった要望は、round-robin だけの単純振り分けでは意図とずれることがあります。ここで登場するのが load-balance およびその strategy です。

2. load-balance が向く「偏り」問題

load-balance 型のポリシーグループは、候補に列挙した複数の proxies に対し、新しい接続（あるいはコア実装が定義する単位）を複数の出口へ配分する、という考え方を表します。目的は 「遅延テストで常に 1 位のノードを 1 つ取る」ことではなく、帯域や同時接続の分散、同一クライアント内での一貫性の両立など、用途に応じた振り方を選べる点にあります。

大容量のゲーム配信クライアントの CDN 周りの話題は Steam 向けの記事でドメイン分流を扱いますが、「どの出口ノードに流すか」というレイヤは本稿の proxy-groups 側の設計で決まります。まずルールでトラフィックを専用グループへ集め、そのグループの型を load-balance にする、という二段構えで考えると手がかりが掴みやすいです。

3. strategy：round-robin と consistent-hashing

mihomo / Clash Meta 系のドキュメントでは、load-balance に strategy キーが付き、代表例として次のような値が挙がります（利用中のコアのバージョン表を必ず確認してください。名称や追加の戦略子が更新される場合があります）。

• round-robin：新しい接続を、候補ノード上で順番に回していくイメージです。単純に分散したいときの基礎的な動き方として理解しやすく、同じ元からの複数接続を別ノードに割り当てる意図に合います。
• consistent-hashing（一貫ハッシュ）：接続元やフローに応じたキーに対し ハッシュを取り、常に同じ候補ノードにマッピングする考え方です。結果として、「同じ元からの一連の挙動は同じ出口へ、別の元は別の出口へ混ざりやすい」、という ソースに対する一貫した振り分けが期待できます。API や会話系で IP が散らばるのを防ぎたいニーズに対し、url-test とは逆方向の文脈で語られることがありますが、ここでは「多ノード配下での安定した同一性」がポイントです。

古い文脈や実装では pcc（per-connection 相当の挙動）のような表記で説明されることもあります。プロファイル断片のコメントや周辺のリリースノートと突き合わせ、自分の mihomo の版がサポートするキーに合わせてください。

4. url-test / fallback / load-balance の違い（表）

検索でよく出る「負荷分散」と「自動遅延テスト」を混同しないよう、本サイトの url-test／fallback 解説と併せて、ここでは負荷分散列を足した対比を示します。数値の意味や間隔の既定値はクライアント差があるため、表は 目的の整理向けです。

5. 分手順：proxy-groups の YAML 例

次は説明用の抜粋です。proxies セクションに列挙したノード名と完全に同じ表記を proxy-groups に書いてください。購読の取り込み手順は サブスクリプション導入ガイドにまとまっています。

手順のイメージ（1）候補ノード名を proxies で確定する →（2）load-balance グループを 1 つ追加し、type・strategy・proxies を書く →（3）下記 §6 のとおり rules でこのグループ名を参照する、の順で進めます。

proxy-groups:
  # load-balance with consistent hashing: sticky per flow/client key in core
  - name: 🎯 DL-Balance-Hash
    type: load-balance
    strategy: consistent-hashing
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 香港 A
      - 日本 B
      - シンガポール C

  # round-robin: spread new connections across members
  - name: 📶 Multi-RR
    type: load-balance
    strategy: round-robin
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - 韓国 D
      - 米国 E

url / interval は実装・バージョンによって任意だったり、ヘルスチェックと併用される定義の場合があります。自環境のサンプルプロファイルと照合し、空のまま起動に失敗する場合は、url-test グループで使っているのと同じテスト先を仮置きする方法もあります。

6. ルールで専用グループを指す

作った load-balance グループは、rules の右端に グループ名そのものを書けば使えます。ルール列の上から評価される原則は ルールルーティングの解説と同じで、大容量ダウンロード専用にだけ使いたいなら、該当ドメイン・プロセス行を MATCH より上に置きます。

rules:
  - DOMAIN-SUFFIX,large-cdn.example,🎯 DL-Balance-Hash
  - GEOIP,CN,DIRECT
  - MATCH,🔰 手動選択

全トラフィックを一括で load-balance に向けると、意図せず会話系や銀行アプリの流れも分散されるため、ルールで対象を絞るのが無難です。ChatGPT など会話系で IP 変化が煩わしい話題は、専用のルール記事で触れているとおり、デフォルトの url-test や load-balance と方針が衝突しやすい点にも留意してください。

7. 注意点とバージョン差

第一に、「consistent-hashing だから出口 IP が一生固定」と断言できない場合があります。ノード候補のリストが更新されたり、同一ノード内で実 IP が回転するアップストリームの場合、ハッシュ表が変わると別出口へ切り替わることがあります。購読の差し替え直後に挙動が変わるのは典型です。

第二に、load-balance は 魔法の帯域合成ではありません。各ノードの帯域上限を超えて速くなるわけではなく、複数同時接続の配置を制御する仕組みです。単一の巨大ファイルが 1 TCP で落ちてくるようなケースでは、期待と体感が違うこともあります。

第三に、GUI クライアントのバージョンとコア（mihomo）の版が食い違うと、パネル上の表記と実際の YAML のキーが一致しないことがあります。不具合時は 生成された設定ファイルの生テキストを確認してください。

最後に、本稿は一般的なプロキシ設定の解説であり、特定事業者の推奨や違法行為の助長を意図するものではありません。契約·法令·利用規約の範囲で、自己責任で利用してください。

8. まとめ

load-balance は、url-test の「最速 1 点に集約」や fallback の「主と予備」とは異なり、複数ノードを束ね接続配分の設計を行うためのポリシーグループ型です。strategy として round-robin を選べば 輪番的な分散、consistent-hashing を選べば フローごとの一貫したマッピング、というざっくりした図式で手を動かすと設定が迷子になりにくいです。あわせて、ルールで対象を絞る・購読名と代理名の綴りを揃える、という基本を踏まえてください。

コアのビルドやクライアントは日々更新されるため、安定した導入から試すのが手堅いです。パッケージの入手は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。