1 なぜ今 load-balance と consistent-hashing か
リモート購読を取り込むと、同じ地域ラベルでも複数の実サーバが proxies に並びます。運用の定番である type: url-test は、定期的な HTTP ベースの遅延測定でいま最も速いと判断したノード一つを選び直すため、長所は「体感レイテンシを追いかけやすい」ことです。一方で、すべてのトラフィックを同じ出口に集めたくない、あるいは「接続のたびに出口が変わると困る」という用途では、単一ノードへの収束がかえって不都合になることがあります。たとえば、複数の長期接続を同時に張り、それぞれ別のノードへ分散したいときや、ログインCookieやIPベースのレート制限と相性を取りたいときです。
type: load-balance は、その名のとおり候補ノードの間でトラフィックを分散するための戦略グループです。ここで strategy に consistent-hashing（一貫ハッシュ）を指定すると、コアは「ある接続の特徴」をハッシュ関数に通し、結果に応じてどのノードに載せるかを決めます。これにより、同じ特徴を持つフローが同じノードに寄る、という挙動が期待できます。厳密な「アプリケーションレベルのセッション固定」ではありませんが、多くの利用者が求める「同じサイトへの接続が同じ出口に寄る」イメージに近づきます。
前提として、本稿は Mihomo（Clash Meta）系の Clash 互換コアを想定します。GUI クライアントのプリセット名は製品ごとに異なりますが、YAML の proxy-groups に書く概念は共通です。基礎の url-test はURL-Test／Fallback の記事で扱っているので、ここでは重複する説明は避け、対比を中心に進めます。プロキシグループの全体像はドキュメントの proxy-groups 解説も併せて参照してください。
2 url-test と load-balance は問題設定が違う
url-test が解くのは「候補の中で誰が速いか」という最適化です。測定した RTT が小さく、tolerance を超えて明確に差が出たときに張り替える、という発想です。一方 load-balance が解くのは「候補の中で負荷をどう分けるか、または同一フローをどう揃えるか」という設計です。前者は「最速一点」に収束しやすく、後者は「複数出口を同時に使う」か「ハッシュで出口を固定する」のどちらか、あるいは両方の意図になります。
したがって、「とにかく遅延が最小のノードへ常に寄せたい」だけなら、まずは url-test の調整（tolerance を含む）が素直です。逆に、「最速一点」に集めると逆に不安定になる（特定サイトだけ別ノードが良い、あるいは同時接続数を分散したい）といった声は、load-balance の検討材料になります。両方を YAML に用意し、外側を select で切り替える構成もよく見られます。
遅延測定との関係
load-balance グループでも、実装によっては url と interval を付けてヘルスチェックに近い振る舞いをさせられます。これは「どのノードが生きているか」を見るための補助であり、url-test のような「最速ランキング」そのものではありません。測定値が良いからといって、そのノードに全トラフィックが集まるわけではなく、戦略（strategy）の定義が優先されます。混同すると、ダッシュボードのログを読むときに「遅延は良いのにノードがばらける」という体感ギャップが生じます。
3 consistent-hashing が「セッションに近い安定」を与える理由
consistent-hashing は、各フロー（実装ではコミュニケーションのキーとして、送信元・宛先の情報などを含むことが多い）に対してハッシュ値を計算し、その値に応じてノードのインデックスを決めます。ハッシュが同じなら同じノード、という単純な対応ですが、ハッシュ関数の性質により、候補ノードの集合が変わると再配置が起きる点にも注意が必要です。これは後述の「落とし穴」に直結します。
対比として、round-robin（ラウンドロビン）は接続ごとに順番に回していくため、厳密な「同一フロー同一ノード」ではなく、分散の公平性を重視する傾向があります。ログイン状態やクッキーがIPアドレスに紐づくサイトと相性が悪いケースでは、consistent-hashing の方が「同じ宛先・同じクライアントからの流れが同じ出口に寄る」イメージに近づきやすいです。
ただし、これはOSI 7 層すべてのセッション意味を保証するものではありません。TLS の中身、HTTP の Cookie、WebSocket の再接続など、アプリ側の状態管理は別問題です。本稿で言う「セッションに近い」は、プロキシの出口選択の一貫性という文脈に限ります。銀行や二要素認証のような高セキュリティ要求の場面では、ベンダー推奨の単一出口やルール固定の方が無難な場合もあります。
fallback や fallback-filter は名前解決の話であり、proxy-groups の type: fallback とは別物です。混線すると設定を誤って書き換えるリスクがあるため、DNS 実務の記事と頭の中で分離しておいてください。
4 YAML 設定例（Mihomo／Clash Meta）
以下は、proxies に実ノード名が存在することを前提とした最小例です。名前は購読マージ後の実名に合わせて置き換えてください。url と interval は、実装・バージョンにより省略可能な場合もありますが、ヘルスチェックの意図を明示するために書いておくと運用しやすいです。
proxy-groups:
- name: "LB-HASH"
type: load-balance
strategy: consistent-hashing
url: http://www.gstatic.com/generate_204
interval: 300
lazy: false
proxies:
- hk-01
- hk-02
- jp-01
- us-west-01
lazy: true にすると、グループが実際に使われるまで積極的に測らない、という意味合いで待機負荷を抑えられます。初回接続直後だけ遅いと感じる場合は false に戻して比較してください。
ラウンドロビンとの対比
分散の公平性を重視し、出口の固定性はそれほど気にしないなら strategy: round-robin を検討します。同一サービスへの複数接続が別々のノードに載ることがあり、ログインやレート制限の観点では一貫ハッシュと体感が異なる可能性があります。
proxy-groups:
- name: "LB-RR"
type: load-balance
strategy: round-robin
url: http://www.gstatic.com/generate_204
interval: 300
proxies:
- node-a
- node-b
- node-c
ルール側では、どちらのグループも、宣言した name を rules から参照します。例として MATCH,LB-HASH のように書けば、最終ルールでこの出口に流れます。セレクタ型のグループを外側に置き、手動で AUTO-BEST（url-test）と LB-HASH を切り替えられるようにしておくと、トラブル時の切り分けが容易です。
5 向き／不向きのシナリオ
向きやすい例： 複数ノードの帯域を同時に使いたいが、同一サービスへの接続が頻繁に出口を変えるとログインや人間確認が出やすい、というとき。一貫ハッシュは「同一フローに近い出口の一貫性」を狙います。また、単一ノードに集中すると逆に遅延が悪化する（混雑のせいで）という状況では、分散の意味が出ます。
不向きな例： 常に最速の一点だけを追いかけたい、というだけなら url-test の方が素直です。また、ノードの入れ替えが頻繁な購読では、ハッシュの再配置が起きるため、「一貫した出口」という期待に揺れが出ます。さらに、遅延テストの URL への RTT と、実際のサービス（ゲームや CDN）への経路は一致しない点は、url-test のときと同じく load-balance でも注意が必要です。
二系統の空港を併用している場合は、proxies に両方のノードを並べた単一の load-balance グループにするか、まずはルールで別の戦略グループに分けるか、運用の好みが分かれます。契約やログの観点で「このドメインは A 側だけ」といった制約があるなら、rules 側で先に振り分け、残りを load-balance に載せる方が安全です。
6 よくある落とし穴
- ノードリストの変更でハッシュが崩れる： 購読の更新でノードの名前や順序が変わると、同一フローでも別ノードに振り分けられることがあります。安定性を重視するなら、
proxy-providersまわりのマージや手動フィルタの運用を見直します。 - 「遅延が良いのに体感が悪い」： 測定 URL への RTT は単なる指標です。本稿では url-test との違いを強調しましたが、load-balance でも実測の経路と一致しない点は同様です。
- ヘルスチェックと戦略の誤解：
urlへの到達が全滅に近いと、ノードが不健康扱いになります。企業ネットワークや国フィルタで定番のテスト URL が見えない場合は、到達できる軽量 HTTP に差し替えてください。 - IPv4／IPv6 の混在： スタックの違いで、同じ論理フローでもハッシュ入力が変わることがあります。クライアント側の IPv6 設定とノード側の対応を揃えて切り分けます。
- クライアントの古いコア：
strategyの対応値や、キー名の別名は実装依存です。可能なら Mihomo の現行リリースに揃え、リリースノートを確認してください。
7 まとめ
url-test が「最速の一点」を追うのに対し、load-balance は「複数ノードの使い方」そのものを設計するための戦略グループです。その中で consistent-hashing は、ハッシュに基づいて出口を一貫させつつ分散を実現する、という意味で「セッションに近い安定」を狙います。一方で、ノード集合の変化や測定 URL と実際の経路の違いは、常に頭に置いておく必要があります。
実務では、まず URL-Test／Fallback で基本を固め、必要なら load-balance を追加し、セレクタで切り替えられるようにしておくと安全です。ダッシュボードや 外部コントローラと Yacd で実際の選択ノードを確認しながら調整すると、YAML の意図とログのズレを減らせます。
総じて、Clash 互換スタックはルールと DNS、そして戦略グループの三層で体験が決まります。本稿の load-balance と一貫ハッシュは、多ノードの購読を「単一の最速」以外の設計に広げるためのピースです。GUI で購読管理と遅延表示をまとめたい場合は、ダウンロードページで自 OS に合うビルドを選ぶと、同じ proxy-groups 概念を画面越しに扱いやすくなります。
