Clash YAML ルール分流完全ガイド 2026：ポリシーグループとRule Providers

ルール分流とは何を解く仕組みか

プロキシクライアントは、単に「すべてを海外ノードへ」ではなく、接続先ごとに経路を変えることができます。国内の動画や銀行サイトは直接、検索やSNSだけ別ノード、広告やトラッキングは拒否、といった分流です。Clashではこの判断をYAMLの rules に列挙し、上から順に最初に一致した行だけが採用されます。ここが理解の出発点です。

分流を支えるもう一つの柱が proxy-groups です。実際のサーバー名（proxies に書かれた各ノード）を、ユーザー向けの「自動選択」「香港」「手動」といったポリシー単位にまとめ、ルール側はそのポリシー名だけを指すようにします。ルールとポリシーが分離されることで、ノードが増減してもルール本体を書き換えずに済む場面が増えます。

コアが Clash Meta（mihomo） であれば、従来のルールに加えて Rule Providers で外部のルールセットを取り込み、RULE-SET として扱えます。ドメインリストやGEOIP相当の集合をURLやローカルファイルから供給でき、本稿の後半で詳しく扱います。コアの入れ替えや前提については、Clash Meta（mihomo）コアアップグレードガイドも併せて参照してください。

設定ファイルの骨格：proxies／proxy-groups／rules

典型的な構成は次の流れです。まず proxies でノードを定義し、続けて proxy-groups でそれらを束ね、最後に rules でトラフィックをポリシーへ振り分けます。ポートやDNSなど別セクションは省略していますが、分流の議論ではこの三つが中心です。

proxies:
  - {name: "hk-1", type: ss, # ...}
  - {name: "jp-1", type: vmess, # ...}

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "hk-1"
      - "jp-1"
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

DIRECT は特殊な名前で、プロキシを使わず直接接続します。REJECT は拒否（多くのGUIでは広告ブロック用プリセットとして使われます）。ルールの右側に書くのは「プロキシ名」ではなく、ポリシーグループ名か、これらのキーワードです。

ルールは必ず「上から」評価される

同じ接続が複数行に当てはまり得るとき、先に書いた行が勝ちます。そのため、細かい例外（特定ドメインだけ直結など）を書く場合は、広い条件（例：最後の MATCH）より上に置く必要があります。逆に、意図せず国内サイトがすべてプロキシに流れる、というトラブルの多くは、GEOIP,CN や DOMAIN-SUFFIX の位置が不適切なことが原因です。

ポリシーグループの種類と選び方

proxy-groups の type によって動作が変わります。よく使うものを押さえておくと、GUIの「自動選択」「故障時フォールバック」がYAMLでも再現できます。

select：ユーザーが手動で1つ選ぶ。最もシンプルで、ルールの行き先として使われることが多いです。
url-test：定期的にURLへ到達テストし、遅延の良いプロキシを自動選択。url と interval を指定します。
fallback：上から順に到達可能か試し、最初に使えたものを採用。不安定な回線での「生きているノードへ」に向きます。
load-balance：複数プロキシへ負荷分散。同一ホストへの接続の振り分け方は実装依存のため、用途を絞るのが無難です。
relay：チェーン接続（A経由でBへ）。高度な構成で、レイテンシは増えがちです。

実務では、メインの出口を url-test または select にし、国内向けは DIRECT をルールで明示、広告や追跡は REJECT へ、という階層にすると迷いが減ります。

url-test の例

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies:
      - "hk-1"
      - "jp-1"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance は、わずかな遅延差で切り替えが頻発するのを抑えるための余裕値です。体感で切替が多すぎるときは上げると安定します。

rules の主要キーワードと使い分け

代表的なルールタイプは次のとおりです。いずれも「条件,引数,ポリシー名」の形式が基本です（バージョンや実装により細部は異なります）。

タイプ	用途の目安
DOMAIN	完全一致のホスト名。特定サービス1件だけ変えたいとき。
DOMAIN-SUFFIX	サフィックス一致。CDNやサブドメインをまとめて扱いやすいです。
DOMAIN-KEYWORD	ホスト名にキーワードが含まれる場合。広すぎると誤爆しやすいので注意。
IP-CIDR / IP-CIDR6	宛先IPのレンジ。P2Pや固定IP向けの例外に。
GEOIP	国コードに基づく振り分け。国内直結に `GEOIP,CN,DIRECT` がよく使われます。
SRC-IP-CIDR	送信元IP（LAN内の特定端末だけ別ポリシーなど）。
MATCH	最後の総取り。必ずどこかに1行入れるのが一般的です。

Clash Meta では RULE-SET を使い、Rule Provider が供給する集合を1行で参照できます。大量のドメインを rules に直書きせず済むため、設定が読みやすくなります。

GEOIP の前提 GEOIPはデータベースとルーティング情報に依存します。クライアント側のGEOIP更新や、DNSが返すIPの見え方によって結果が変わることがあるため、「国内は必ず直結」と絶対視せず、重要なドメインは DOMAIN-SUFFIX で補強すると安全です。

Rule Providers：外部ルールを購読する

rule-providers は、名前付きでルールセットを定義するブロックです。type には http（URL取得）や file（ローカルパス）などがあり、behavior で中身の解釈（ドメイン一覧か、クラシックなルール行かなど）を指定します。取得したデータはキャッシュパスに保存され、interval ごとに更新できます。

定義の例（HTTP）

rule-providers:
  reject-ads:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

behavior には domain、ipcidr、classical などがあります。classical は従来型のルール行をそのまま束ねるイメージで、他と混在させるときの読み方に注意が必要です。プロバイダーが配布するドキュメントの指定に合わせるのが確実です。

rules 側で RULE-SET を参照する

rules:
  - RULE-SET,reject-ads,REJECT
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

ここで第3引数は、先ほどの proxy-groups にある名前（例：自動選択）や DIRECT です。RULE-SET の行も評価順は他と同じく上からなので、広告やプライバシー系のセットを先に置き、あとから地域分流、最後に MATCH、という並べ方がよく使われます。

信頼できるソースだけを購読する Rule ProviderのURLは設定の一部です。更新のたびに同じ内容が届くとは限りません。出所が不明なリストは慎重に扱い、可能なら自分のミラーに固定するなどの対策を検討してください。

DNS と分流の関係（ざっくり）

ルールがドメインベースのとき、名前解決の結果が分流に影響します。特に「国内ドメインなのに海外IPが返る」ような状況では、GEOIP の行き先が意図とずれることがあります。Clash Meta では DNS 関連の設定（fake-ip、nameserver-policy など）を細かく制御できますが、本稿の主題はルール構造なので、まずは ルールの順序とポリシー名が意図どおりか をログで確認することが先です。

DNSまわりを深くやる場合は、クライアントのログでどのルールに当たったかを追い、必要なら DOMAIN-SUFFIX で例外を足すのが現実的です。詳しいクライアント別の画面操作は、ダウンロードページで入手したアプリのドキュメントと併用するとよいでしょう。

実務で効く設計のコツ

長く運用する設定にするための要点をまとめます。

ポリシー名は短く一貫させる：PROXY、自動選択、国内 のように、ルール行の右端が読みやすい名前にします。
例外は上に：社内ドメインや決済サイトなど、直結したいホストは GEOIP より前に DOMAIN-SUFFIX で書きます。
Rule Provider は用途別に分割：広告、追跡、海外SNSなど、セットを分けておくとON/OFFや差し替えがしやすいです。
購読と手書きの境界：サブスク全体は購読に任せ、自分だけの追記は小さな rule-providers の file や末尾の rules に置くとコンフリクトが減ります。

GUIだけで完結する場合も、エクスポートしたYAMLを一度眺めると、クライアントが裏でどういうポリシー名を使っているかが把握でき、トラブル時に役立ちます。

よくあるつまずき

症状	確認すること
国内サイトが遅い／不要なプロキシを経由している	`GEOIP,CN` や国内向け `DOMAIN-SUFFIX` が、広い `MATCH` より上にあるか。ルールの順序を見直す。
RULE-SET を入れたら起動エラー	プロバイダー名の綴り、`behavior` と実ファイル形式の不一致、パスの書き間違いを確認。
自動選択が頻繁に切り替わる	`url-test` の `interval` や `tolerance` を調整。テスト用URLがそのプロキシで安定して応答するかも確認。
意図しないブロック	`REJECT` 用の RULE-SET が広すぎないか。ログでヒットしたルール行を特定する。

ログに出る「matched rule」や「policy」は、設定が期待どおりかを判断する手がかりになります。最初から完璧を目指さず、ルールを少しずつ足して挙動を確認するのが安全です。

まとめ

ルール分流は、単なるコマンドの羅列ではなく、トラフィックの優先順位とポリシー名の設計です。proxy-groups で出口の振る舞い（手動・自動・フォールバック）を整理し、rules で接続先をポリシーへ割り当て、必要なら Rule Providers で大規模なリストを保守可能な形で取り込む。この三層がそろうと、購読だけでは届かない細かな調整も自分の手の中に収まります。

GUI中心のクライアントでは、これらの概念が画面のどこに対応しているかは製品ごとに違いますが、YAMLの理解があると設定のエクスポートやログの読み方が一気に楽になります。安定したコアとわかりやすいクライアントを組み合わせることも、長期運用では重要です。

→ Clashを無料ダウンロード — Metaコア対応クライアントをまとめて比較でき、自分に合う環境から試せます。

ほかのチュートリアルや最新記事は技術コラムからどうぞ。