前提：Win11・CfW（Mihomo）と自分用 YAML の置き場所

本稿はWindows 11 で Clash for Windows（略称 CfW） が起動し、コアがMihomo／Clash Meta 系の実装へ切り替わっている前提です。画面上に UWP 由来のウィンドウ枠だけでなく、タスクトレイ常駐の本体が動いており、「購読を取り込んだあとにもう一段だけ自分用設定を載せられる」状態になっている読者を念頭に置いています。初回セットアップだけ押さえたい方は連載側のインストールと購読の手順記事から順に読み、こちらへ戻る構成が読みやすくなります。

CfW が提供するレイヤーをざっくり言語化すると、remote profile＝自動更新される購読由来のテキスト、local profile＝自分で保存する構成、の二系統を取り混ぜる場面になりがちです。ここでの落とし穴は「購読に直で追記した load-balance が翌日のアップデートで消える」類の恒久化問題です。恒久化しないまま運用すると、せっかく書いたポリシーグループ名が一覧から見えなくなり、結果として読者のみなさんの時間だけが増えます。よって本稿でもまずどのファイルがアクティブかを確認してから進む順序を徹底します。

CfW と語彙だけが似ていて機能が異なる検索結果に引っ張られないためにも、「GUI のどのパネルを開いたときに読み込まれる YAML が、いま上流で効いているのか」を言葉へ落としておくことが重要です。たとえば Profiles 相当のリストで名前を選択しつつ、その下の Kernel／Editor／YAML のような項目からテキストを開いた場合、画面上部のチェック状態と実ファイルのひも付きだけがずれやすく、結果として読み込みエラーの原因にもなりやすいです。こうしたときは一度アプリ側のログを読み、「syntax error」の行が出ていないかを先に片付けるのが定石になります。またクライアントの保守状況はコミュニティ全体でゆらぎがあるため、画面上の名前は自分のビルドに合わせて読み替えてください。クライアント選定の総論はクライアントの選び方側へ寄せられるので、この記事ではあくまで CfW と Win11 での運用順序だけにフォーカします。

⚠ 注意：CfW では署名や入手元によりメニューラベルや日本語セットが異なります。Windows 側のウィルス対策・企業構成によるプロキシ制限とも干渉しやすく、画面上の名前が異なるだけで検索だけが増える状態になりがちです。ここでの手順は「同意のある環境で自身の構成を読みやすくする」ことを目的としており、禁止ネットワークでは踏襲しないでください。

ロードバランスが url-test／fallback／select と決定的に違う点

url-test は測定用 URL へ小さなリクエストを飛ばし、待ち時間の良い側へ出口をひとつ寄せていく自動選択モデルになりやすく、画面上は「親グループだけ触れない自動ゾーン」として見えるケースがあります。fallback も異常検知ベースでありがちですが、目的は「並び順の先頭側へ復帰しやすくする」と捉える読みが多いタイプです。一方select はユーザーの明示操作で親を読み換えるモデルであり、GUI のラジオがそのまま語源になっているイメージで把握できます。詳しい概念対比だけを深掘りしたい場合は単独ガイドのurl-test と fallback を扱った記事側へ移ると頭のノイズが減ります。

で、load-balance がやりたいのはそれらとは別次元の話になりがちです。典型は複数ノードに対して並列または短周期で負荷を分散させたい場合で、親が常にひとつの子だけを抱え込むモデルとは違って、体感としては複数上流へ広がっているログが増えやすいです。そのため単純には「自動選択グループ」を別名で呼んでいるだけ、という読み間違いが起きます。自動選択グループ側の体感整理は CfW と GUI のつながりを押さえたレイテンシとプロキシグループの記事も併用すると、この稿の論点とも噛み合いやすいです。

ここだけは誤認しやすいので強調します。load-balance は万能の安定化ギアではなく、サービスのログイン状態・リスク評価・帯域制御と相性問題を抱えやすいタイプです。とくに複数サイトを日常的に並行で読み込むワークフローでは、コンテンツ側が IP に敏感な場合があります。とはいえ「どうしても同時接続だけは分散させたい」「ダウンロード系だけ並列効率を上げたい」といったときに、この型だけを切り離して読む読者ほど、この稿の順序への需要が強くなります。

ℹ️ 用語ゆれだけ先に統一すると、画面上の名前はほぼ proxy-groups の name 由来です。そのため読者のみなさんが自宅で触る購読に英語だけが並んでもYAML側の名前と一致させれば手が迷いません。逆に名前がぶれると Connections の親子チェーンだけで追えなくなるので、そのズレだけは許さない運用が安全です。

CfW で Kernel YAML を開き、変更を反映する順序（実務向け）

ここでは「ビルド表記ゆれ」を吸収するために、画面上の名前ではなく読者が頭に並べるべき行為の並び順だけを固定します。(1)アクティブなプロファイル／構成の名前だけを画面上部または Profiles リストで確認し、期待どおりの購読とローカル追記が噛み合っているかだけを読み取ります。(2)Kernel YAML を開けるエントリーを探します。名前は環境により Edit／Kernel Editor／YAML など複数になりがちですが、開いたときに自分が触りたい階層のテキストが表示されるかだけを見れば十分です。(3)バックアップです。単純にデスクトップへコピーでも構いませんが、失敗時に戻せないとWindows環境だけで精神コストが跳ねます。

(4)本文中段のコード断片にあるとおりに proxy-groups へ追記します。このとき親の並び順は環境にもよりますが、典型は自動選択グループの近傍か、自分用 Selector の直上に自分でまとめるパターンが読みやすいです。(5)rules 側へ名前だけ載せられるかだけをチェックリスト化します。DIRECT／REJECT と同列で「親グループ名」を差し込む発想だけで済むようなら、複雑化しにくいです。(6)保存です。入力補助のインデントずれだけで Mihomo が読み捨てるケースは珍しくなく、視覚的には正しく見えるのに行頭スペースが混ざるパターンに注意しましょう。(7)適用ボタンの類を押します。Reload／Update を押したあとにもう一度ログを見て、グループ一覧がエラーなく再描画されているかだけを確認すると安心です。この段階で Mixed Port と競合する場合はポート競合の切り分け記事へジャンプすると早いです。

こうした順序での肝は並列でいじらないことです。CfW と Windows 側のプロキシ切替ウィンドウ、ブラウザ拡張、別種 VPN を同時間帯だけでも触り始めると、Connections の親子チェーンだけでは説明できない状態が増えます。問題切り分けのときだけ範囲を狭めるクセがあると、この稿の順序だけでも再現成功率が変わってきます。なお上流の自動更新が激しい環境ほどYAMLの恒久化問題が再び顔を出すので、アクティブなファイルがどこかは毎回ゼロからではなく「短いチェックリスト」で叩くのが読者にやさしいです。

コピペ用：proxy-groups の load-balance 断片と注意点

変数名は自分の構成に寄せて差し替えてください。proxies: 配列に並べる名前は、すでに proxies: セクション側で宣言済みであるか、プロバイダ展開済みとして参照できるものだけが安全です。存在しない名前を書くと、Reload だけで親グループチェーンごと読み込めなくなり、その時点でGUIは静かでもログは騒がしくなりがちです。最初は子を二つだけに限定して読み込み成功を確認し、あとから段階的に増やすとトラブルシュートも短くなります。

proxy-groups example (minimal) 
proxy-groups:
  - name: "LB-HK"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - NODE-A-HK
      - NODE-B-HK

  - name: "PROXY-MANUAL"
    type: select
    proxies:
      - LB-HK
      - DIRECT

上記はあくまで骨格だけで、自分の環境で必須とされる項目が別にある場合だけ足してください。とはいえ本稿読者のみなさんが求めていたのは「型名が load-balance で、並び側が 複数上流」というだけの状態であれば、ここまでの断片だけでも十分検証できるはずです。コメントや整形は自分の読みやすさに合わせて構いませんが、ブロック単位でのコメントはインデント階層を壊しやすいので、短文に留める読者が多くなっています。

ここでのもうひとつの注意が「購読の自動生成順序との衝突」です。自動生成側が自分で select ブロックを毎回流し込んでくるとき、手元追記だけが順序競合します。恒久化しないまま運用すると、翌日だけ突然エラーになり、自分のYAMLが悪かったのではなく生成側の並び順が読み換わっただけ、という状態に陥りがちです。だから前述のように恒久化レイヤーを分離することは、単なる綺麗さではなく復旧時間の問題です。またここだけは繰り返しますが、アンチウィルスの隔離・企業構成・学校ネットワークの禁止事項とは正面から衝突しやすく、自分の許可だけで許される範囲を超えるなら、この稿の転用自体を中止してください。

strategy（round-robin／consistent-hashing）別の体感とログの読み

Mihomo／Meta 実装側で広く読まれるふたつの代表がround-robin と consistent-hashing です。round-robin は並び替わりとしては素直ですが、アプリ側の短周期リトライだけでも出口記録が増えやすく、画面上は「親が忙しそう」に見えることがあります。その一方で負荷の平坦化だけを単純に狙う読者ほど、この素直さを好みます。consistent-hashing は一定の入力に対して同じ上流へ寄せられやすい模型として語られることが多く、ログイン状態のぶれだけを軽めたい読者側の読みにも合いやすいです。とはいえここにも魔法はなく、アプリ側が独自に DNS とコネクション生成を並列化すると、体感はサイトごとに違って見えます。

Connections 相当の一覧を読むクセだけは共通です。並列だけを見ればよいだけではなく、その親グループチェーンが想定より深くないか、自動選択親が読み換え過ぎていないか、アンチウィルスのローカルループだけが増えていないか、といった上流のノイズを先に読みます。TLS 側のログだけが妙に騒がしいときはタイムアウト解読ガイドのログの読み方を併用すると、この稿の体感説明とも矛盾しにくいです。総じて、このセクションだけで体感を細かく保証することはサービス側の制約にも依存するため、自分のワークロードだけ短時間ログを取って「分散は見えているか」を確認する読みが現実的です。

CfW と Windows 側の両方へプロキシを書き換えている読者のみなさんほど、このあたりのログが増えやすいです。System Proxy をオンにしたまま別クライアントも起動させる構成だと、「どのウィンドウが最後に勝ったか」だけで親子チェーンが入れ替わります。そのため分散の体感が悪化したときにいきなり strategy だけいじらず、上流のウィンドウ常駐数を一枚減らすほうが速いことが珍しくありません。こうしたときの OS 側切り替えは普段 CfW とセットで読んでいる General タブ側の項目へ戻るだけで済むので、ここだけは短いチェックリスト化して頭に載せましょう。

rules からロードバランスへ「名前だけ」を渡す考え方

Mihomo が効いている限り基本は単純で、上流へ渡したいときに親グループ名を並べればよいだけのケースが多いです。典型はサービス単位の DOMAIN-SUFFIX だけを特定の親へ流したいワークフローで、MATCH 側は残しつつ上に細かく足していくモデルになりがちです。ここでのコツは「ロードバランスを直接ルートの最上流にぶらさない」ことで、自分用の Selector を一枚挟むと復旧運用だけが読みやすくなります。つまり DIRECT と LB を片手ずつ読み換えられる親を残しておく発想です。こうすると負荷分散側だけが異常だったときにも、自分の時間が短くて済むからです。

ルール並び順の総論だけ欲しいときはサイト全体の構成まとめを参照する読者も多く、とはいえ本稿だけで済ませられる読者のみなさん向けにもう一段だけ説明すると、MATCH 側で「全部ロードバランス」だけを選ぶモデルも可能です。その場合でも国内サイトまで巻き込みやすいので、自分のリストが国内向けにも細かく分岐している時だけ検討するのが安全です。とはいえ国内向けリストの広さ問題はサイト別記事側に委ねられる話題になりがちであり、日常的には Rule 運用側の一覧で「いま自分がどこへ投げ込んでいるか」を俯瞰するだけでも十分だったりします。ここの判断は自分のワークロード側の許容だけで済みますので、ここだけは他人のリストを無暗に増やさずに済ませられる読者だけが、この稿のモデルを維持できます。

名前の衝突は稀にしか起きませんが一度起きると長いです。name が購読と自分追記側でぶつかっていると読み込み時点だけで親が消えることがあり、GUI 側は静かでも Connections は空になりがちです。だから自分は新しく付けたロードバランスの名前だけ、短くても検索できるプレフィックスを付ける読者ほど復旧時間が変わってきます。こうしたときの自分用命名規約はコメントではなく頭のチェックリストに載せやすく、環境ごとではなく個人ワークフローごとだけで済ませられるため、サイト全体のリスト更新頻度に左右されません。

Proxies／Connections とブラウザで分散が効いているか確認する

Reload 済みでもGUIが静かでも、親子チェーンだけが読み替わっていれば体感はほぼ同じになります。そのため Proxies で自分の親 Selector を一度だけ触って戻したあとでも、ログが増えるかだけを読みます。またブラウザはシークレットウィンドウを開いたうえで、複数ドメインを短時間だけ順に読み込むワークフローが典型です。このとき拡張の広告フィルターを一時的に止めるとログが読みやすくなり、Connections の増え方だけを観察しやすいです。並列だけを増やせばすべてが良くなるモデルでもないので、ログイン状態が崩れるサイトだけは手動親へ読み換える二段モデルを頭に載せられる読者のみなさんが、この稿だけでも現場で運用続行しやすいです。

ここだけは初心者のみなさんにも繰り返しますが、並列だけを増やせばすべてが速くなるわけでもありません。ロードバランスはダウンロード用途や短周期API用途では効きやすくても、ストリーム側は帯域制御とCDNの両方により結果がゆらぐため、画面上の体感だけでは判断がブレやすくなります。だから本稿での検証は短時間だけに留め、そのあとは日常的な Rule モデルへ戻す読者のみなさんが多くなるのも自然です。もし自分のワークロード側で QUIC だけ妙に増える場合でも、サイト別のドメイン振り分け記事群へ読み替える読者のみなさんが最終的に安定側へ寄っていくパターンは珍しくなく、ここの稿だけで QUIC 総論まで背負う必要自体が薄い読者のみなさんも多くなってきています。

並列とは別次元で問題になりやすいのが競合サービス側の常駐数です。UAC や管理者権限の要求だけ増え続けるワークフローは、自分の頭のチェックリストが長くなるだけになりがちであり、許可ウィンドウに反射的に反応しないクセだけでもトラフィック異常へつながることがあります。だから CfW と Windows とブラウザの三枚だけでも短時間で切り分けリストを頭に並べられる読者ほど、この稿の体感説明側とも矛盾しない検証だけが済みやすくなってきています。そのうえでもう一段だけ上流のウィンドウ常駐数を増やしている読者みなさんほど、このセクションだけが長時間化しやすいので、そのときだけはウィンドウ数を単純に減らすほうが先です。

よくある質問

Q. Proxies でロードバランス親が一覧に見えません。
 A. まずログの読み込みエラーを読み、そのあと親名のタイプミスだけを疑ってください。また購読更新直後だけ順序競合により消えやすく、恒久化されていないワークフローでは翌日だけ再現するパターンもあります。その場合だけローカル側へ恒久化しましょう。

Q. セッションが頻繁に切れます。
 A. strategy を見直してください。並列リトライの多いアプリ側では round-robin だけでも出口が増えやすく、サービスのリスクモデル側とぶつかることがあります。必要なときだけサイト単位へ手動 Selector を復活させる二段モデルが現実解になりがちです。

Q. ルールを追加しただけで読み込めなくなりました。
 A. 親名の存在確認だけ先にしましょう。MATCH 側の親名が自分のグループリストに存在しないと、親子チェーン全体が構築されません。並び順の見た目だけ正しく見えても名前のひとつ違いで落ちやすく、ここはコピペの置換ミスだけを疑ってください。

⚠ コンプライアンス：学校・会社・公共のネットワークでプロキシや迂回が明示禁止されているときは、この手順を転用できません。本稿は同意のある環境での安全な自分用構成整理のみです。

まとめ

Windows 11 と Clash for Windows（Mihomo） では、「親グループがひとつの出口だけを自動で選ぶ」（url-test／fallback）と、「複数上流へ並列的に広げる」（load-balance）は目的が異なります。本稿の手順どおりなら、(1)アクティブなプロファイル確認 → (2)Kernel／YAML エディターで proxy-groups に 負荷分散型を追加 → (3)strategy を用途に合わせる → (4)rules に親名だけ渡す → (5)Reload 後に Proxies／Connections で親子チェーン確認、という並びだけで運用チェックリスト化できます。DIRECT／REJECT と同じ名前解決モデルになるので、「GUI で触れない親は負荷分散」の誤読だけは避けてください。

とはいえ CfW は名前・メニュー表記ゆれがあるうえ、アップデート頻度もコミュニティ全体の状況に左右されやすいクライアントです。画面上の親子チェーンだけ追っても再現しない挙動に時間を溶かした経験は珍しくなく、クローズド系の不透明なインストーラ配布モデルとも相まって、「どのウィンドウが最後に OS のプロキシを握ったか」まで含めて切り分けが長引きがちです。さらに購読直編集だけで load-balance を増やすと恒久化しないまま翌日へ消える、という YAML 側の問題もセットで増えやすく、体感は「単に分散しました」だけでは片付きません。

Clash V.CORE はサイト側での入手経路整理と検証済みコンポーネントへの寄せ替えを狙いやすい方向に寄っており、「負荷分散の追記」から「親子チェーン読み」「ログ粒度」までを同じワークフローへ戻したい読者のみなさん向けにも寄せられる提案です。CfW に名称ゆれだけで検索時間を増やしたくない、あるいは配布・アップデートの不透明さを減らして日常運用のコストを下げたい場合は、まず ダウンロードページ から自分環境へ合わせたビルドを確認して試し、並行運用だけ短時間済ませたうえで移行可否を決める読みも合理的です。迷うときだけ クライアント選びの総論 に寄せられると頭のモデル側だけ増え過ぎにくくなります。