Clash プロキシグループ（proxy-groups）：基礎から応用までの完全ガイド

Clashのプロキシグループ（proxy-groups）とは何か

Clashの設定YAMLでは、proxy-groups に並ぶ各エントリは仮想プロキシです。単体でサーバーになるのではなく、ひとつ以上の実ノードや別グループに対する振り分けポリシーを表します。ルールが接続をあるグループ名に送ると、Clashはそのtypeに従って最終的な出口を決めます。

一文で言えば、ルールは「プロキシを使うべきか」を決め、プロキシグループは「どのプロキシが実際に通信を運ぶか」を決める、という分担です。ゲームの遅延、動画視聴、日常の安定性に効いてくるのはこの部分です。用語の全体像は先に Clashのチュートリアル で押さえてからここに戻ると、理解の順番がつかみやすくなります。

コミュニティ配布のプロファイルは、だいたい「画面上で触る入口用のselectが少数」「裏で地域ごとにurl-testするプール」という層構造になっています。配布元のアップデートを取り込んでも、自分用の追記を壊しにくい読み方が身につきます。Clash Meta系クライアント（Mihomoベース）では同じ語彙がそのまま使えるので、Verge系やGUIフォーク、ヘッドレス運用でもスキルが横に効きます。

サブスクリプションが届くのは通常proxies（ノード一覧）だけです。ノードをどう束ね、どう名前を付け、アプリにどう見せるかは自分のYAML設計次第で、同じ購読でもルーティング体験は人によってまったく変わります。

実務で使う4つの基本タイプ

多くのプロファイルは、次の4タイプを軸に組まれています。用途はそれぞれ「手動」「遅延優先」「順番のフェイルオーバー」「負荷分散」です。

ネット上のスニペットを貼る前に、自分のクライアントがそのtypeを解釈できるか確認してください。Mihomo（Clash Meta）は拡張挙動が増えますが、日常設定の背骨はこの4つです。未対応の型を書くとパースエラーや無視につながります。

① select — 手動で選ぶ

selectは最もシンプルです。クライアントのUIでメンバーを選び、自動測速やローテーションは行いません。銀行アプリ用に地域を固定したい、DNSまわりを切り分けてデバッグしたい、といった意図的に手で切り替えたい場面向きです。

自動が入らないぶん、学習初期にも安全です。候補は短めにしてメニューを読みやすくし、あとからurl-testのプールを下に隠す、という段階的な設計も一般的です。多くのテンプレートは、カジュアル利用者向けにトップに「Proxy」「Global」など単一のselectだけを出します。

proxy-groups:
  - name: "Manual"
    type: select
    proxies:
      - HK-01
      - JP-01
      - US-01
      - DIRECT

② url-test — 遅延の小さいノードを選ぶ

url-testは、プローブURL（多くは軽量な204応答）へ定期的に試し打ちし、もっとも速そうなメンバーを維持します。ゲーム、ビデオ会話、対話的なSSHなど応答性が重要なときに向きます。toleranceは、わずかな差で行き来するのを抑えるための「許容幅」です。

プローブ先への遅延は、利用するすべてのサービスと一致するとは限りませんが、自動化には現実的な近似になります。配信サービスが出口にうるさい場合は、その用途だけselectを別途用意し、ルールで上書きできるようにすると運用が楽です。

proxy-groups:
  - name: "Auto fastest"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300        # 300秒ごとに再テスト
    tolerance: 50        # 50ms以内なら切り替えない
    proxies:
      - HK-01
      - HK-02
      - JP-01

③ fallback — 優先順にフェイルオーバー

fallbackはリストを上から順に見て、ヘルスチェックを通った最初のプロキシに張り付きます。失敗したら次へ。これは「一番速い勝ち」ではなく「まず主系、だめなら予備」の物語です。遅延より順序の意味を重視するワークフローに合います。

運用では、安定したDC系を先に、コストのよい住宅系IPを後ろに置く、といった並べ方もよく見ます。YAMLの外のメモに意図を残しておかないと、並べ替えだけでフェイルオーバーの意味が変わるのに見た目は変わらない、という事故が起きがちです。

proxy-groups:
  - name: "Failover"
    type: fallback
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    proxies:
      - Primary-HK
      - Backup-JP
      - Emergency-SG

④ load-balance — 接続を分散する

load-balanceは複数ノードに負荷を分散します。戦略にはround-robinやconsistent-hashingなどがあります。HTTPSでは、同一ホスト名が同じ出口に寄りやすいconsistent-hashingが選ばれることが多く、セッションとIPの紐づけが厳しいサイトでのログイン切れを減らせます。

同一リージョンに複数の健全ルートがあるときの分散に向きます。一方、銀行や一部SaaSのように単一固定IPが必須の用途では、selectやメンバー1つのグループへ寄せる方が安全です。

proxy-groups:
  - name: "Load balance"
    type: load-balance
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing
    proxies:
      - HK-01
      - HK-02
      - HK-03

ネスト（入れ子）でポリシーを組み立てる

proxies配列には、実ノード名だけでなく別グループ名も並べられます。下層に地域ごとのurl-testプール、上に用途別のselect、さらにrulesからは安定した1つの名前だけを指す、という階層にすると、ルール表を短く保てます。

循環参照は無効です。AがBを含みBがAを含むようなグラフは決定的に解けません。葉が実ノード、中間がグループ、辺がproxiesの参照、と紙に書くと整理しやすいです。有向閉路のないグラフなら挙動は予測しやすく、ループはコアの版によってエラーまたは未定義になります。

proxy-groups:
  # Tier 1: regional pools (url-test per region)
  - name: "HK pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02, HK-03]

  - name: "JP pool"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  # Tier 2: manual pick among regions
  - name: "Pick region"
    type: select
    proxies:
      - HK pool
      - JP pool
      - DIRECT

  - name: "Streaming"
    type: select
    proxies:
      - US-01
      - JP pool

一通りの設定例（レイヤー構造）

日常利用でよくある形をひとつにまとめました。最上位のセレクタ、自動最速プール、動画向けの選択肢、地域url-test、最後に直結へ逃がせるキャッチオールです。ノード名は自分のproxiesに合わせて置き換えてください。

proxy-groups:
  - name: "Main"
    type: select
    proxies: [Auto, HK, JP, US, DIRECT]

  - name: "Auto"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies: [HK-01, HK-02, JP-01, SG-01]

  - name: "Streaming"
    type: select
    proxies: [US, JP, HK]

  - name: "HK"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [HK-01, HK-02]

  - name: "JP"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [JP-01, JP-02]

  - name: "US"
    type: url-test
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    proxies: [US-01, US-02]

  - name: "Catch-all"
    type: select
    proxies: [Main, DIRECT]

rules（ルール）とプロキシグループのつながり

rulesでは、ポリシー先としてグループ名を文字列で指します。国内ドメインをDIRECT、ストリーミング用リストをStreaming、最後にMATCHでMainやCatch-allへ、といった形です。rules側とproxy-groups側の綴りを一字一句そろえる必要があり、タイプミスは静かに誤経路を生みます。

GEOIPやDOMAIN-SUFFIX、PROCESS-NAMEなどのルールは、最終的にその文字列ターゲットへ転送します。ターゲットは実ノード名・グループ名・DIRECTやREJECTなどの組み込みキーワードのいずれかである必要があります。だから「HK」を「HongKong」に変えるときは、参照しているルール行もまとめて直す、というリファクタになります。

グループの中身を変えたあと、プロファイルをキャッシュしているクライアントでは再起動や「プロファイル更新」が必要なことがあります。Mihomoの新機能を安定して使うには、ビルドの追従がしやすい入手経路が便利です。インストールと更新の入口として ダウンロードページ を利用してください（GitHubのRelease直リンクを「唯一の入手先」と誤解されないよう、まずはこちらを基準にすると安全です）。

タイプの選び方（早見）

迷ったら用途から逆算します。監査や検証でノードを固定したい → select。クライアントに遅延の小さいものを自動で選ばせたい → url-test。主系・予備の順序が大事 → fallback。複数健全ルートに負荷を分散したい → load-balance（長寿命HTTPSにはconsistent-hashingが無難）。

実際のスタックでは型の混在が普通です。人間が触るselectを上に、下に地域url-test、レアな管理用ノードだけfallback、といった重ね方がよくあります。ユーザーに見せる名前を少なく保ちつつ、緊急時はDIRECTやREJECTに逃がせると運用が楽になります。

つまずきやすいポイント

• 幽霊名：購読更新で消えたノードをグループが参照したままだと、ダングリング参照になります。更新のたびにグループも整理しましょう。
• 過剰テスト：intervalを極端に短くすると、レート制限やノートPCのバッテリー消費の原因になります。
• toleranceの誤設定：0はノイズの多い回線で頻繁に切り替わります。大きすぎると平凡なノードに張り付きます。実測で調整してください。
• ルールの取り違え：別プロファイルからルールだけコピーし、グループ名を揃えないのは、誤出口への最短ルートです。

実運用での調整メモ

• 間隔：url-testとfallbackでは、180〜300秒あたりがバランスの取りやすい帯です。短すぎると電池と帯域を食い、長すぎると悪いノードに留まりすぎます。
• プローブURL：プロバイダの利用規約で許される先を使いましょう。公開の204が多いですが、自前ドメインにミラーする人もいます。
• 命名：UTF-8で日本語や絵文字も可能ですが、rulesやネスト参照と完全一致（大文字小文字含む）が必要です。手編集ならASCIIの短い名前がミスりにくいです。
• 深さ：深いネストは強力ですが、初心者には見えにくくなります。最上位の数個を「公開API」のつもりでドキュメント化するとよいです。
• ログ：挙動がおかしいときは接続ログでどのグループ名が流れたか確認し、ネストを逆に辿って実ノードまで行きます。

本番に載せる前の確認

構造をいじったらプロファイルを再読み込みし、代表例で確認します。国内ニュースはDIRECT、検索エンジン、自分が最重視するサービス（動画、クラウド、ゲームランチャーなど）です。一カテゴリだけおかしいなら、そのドメインに当たるルールとターゲットグループの存在を疑ってください。

大きめの変更はYAMLをGitなどでバージョン管理しておくと、壊れた購読バンドルを取り直すよりgit diffで戻す方が早いことがあります。パーサの挙動が変わる話題は Clashブログ でも追えるので、たまに目を通すと安心です。

よくある質問

単発のVPNトグルと違い、Clashは「意図をルールで」「実行をグループで」と役割を分けられます。日々のストレスを減らすには、それを快適に扱えるクライアント選びも大切です。まずは Clashを無料でダウンロードし、設定のしやすさを体験してください。