ルール分流とは何のためか
ルール分流とは、Clash のコア（多くの場合 Mihomo）が、接続ごとにドメイン名・IP・地理情報などを手がかりにして、DIRECT（その場の回線でそのまま）か、あるいは指定したプロキシグループへ送るかを決める仕組みです。購読 URL は「サーバ一覧とグループの素」を渡すだけで、最終的にどのトラフィックがどの出口へ行くかは、ほぼいつも rules セクションと rule-providers の内容次第です。
中国本土のユーザーにとって典型的な目的は、国内のウェブやアプリは遅延と帯域の観点から DIRECT に寄せ、検索や SNS、開発者向けサービスなど海外向けの通信だけをプロキシへ載せることです。すべてを常時プロキシにすると、国内 CDN まで遠回りになりがちですし、ノードのクォータも無駄に消費します。逆にルールが粗いと、国内サイトまで海外ノードへ流れて遅い・不安定という症状が出ます。まずは「ルールは上から順に最初の一致だけが効く」という前提を押さえるのが出発点です。関連トピックは ブログ一覧 から辿れます。
mode: rule（またはクライアントが同等の挙動を選んでいる状態）で、GLOBAL や DIRECT に全面固定しない限り、rules の評価が有効になります。
ルールの優先順位：必ず「上から先勝ち」
Clash 系のルールはリストの先頭から順にマッチ探索し、一度決まったらそれ以降は見ません。そのため、例外や細かい条件ほど上に、包括的なフォールバックほど下に置くのが基本です。例として、社内 LAN やローカルホスト、キャプティブポータル検出用ドメインなどは、誤ってプロキシへ送らないよういちばん上か、少なくとも GEOIP より前に置くのが安全です。
代表的な並びの型は次のイメージです。（1）プライベート IP や LAN。（2）広く共有されている「国内ドメイン／国内 IP レンジ」のルールセット。（3）広告ブロックや追跡回避など任意の追加ルール。（4）GEOIP,CN のような地域判定。（5）最後に MATCH で残りを既定のプロキシグループへ、という流れです。実際のキーワードや国コードは利用するコアのバージョンとデータベースに合わせてください。サンプルは説明用の断片であり、そのままコピーすると環境によっては動きません。
DOMAIN・IP-CIDR・GEOIP をどう使い分けるか
DOMAIN／DOMAIN-SUFFIX／DOMAIN-KEYWORD は、名前解決の結果に関係なく接続しようとしているホスト名を見ます。HTTPS のような暗号化通信でも、多くの場合 SNI などからホスト名が分かるため、ドメインルールは体感では分かりやすい一方、リストの網羅性とメンテナンスコストが課題になります。IP-CIDR は、すでに IP が確定している経路向けで、CDN のように IP が変わる相手だけをこれで押さえるのは難しいことがあります。
GEOIP は IP の所在地データベースに基づき、例えば中国大陸向けのトラフィックを一括で DIRECT にするのに使われます。データの鮮度や境界付近の誤判定はゼロにはできないため、「国内サイトが遅い」というときは、まずそのドメインがどの IP に解決されているか、ルールのどこで拾われているかをログで確認すると早いです。コアやルールセットの更新頻度も、長期運用では重要な要素になります。
rule-providers でルールを外部化する
手書きの rules だけではリストが肥大化しやすいので、rule-providers を使ってコミュニティやメンテナされているルールセットを HTTP(S) で取り込み、rules 側では RULE-SET,provider_name のように参照する方法が一般的です。名前の通り、ACL4SSR 系や Loyalsoldier など、目的別に公開されているセットを選び、自分のポリシーグループ名と整合するようテンプレートを選ぶ必要があります。
プロバイダは更新間隔とフォールバックの設計が重要です。取得に失敗したときに古いキャッシュで動くか、まったくルールが空になるかは実装と設定次第です。また、信頼できない第三者 URL をそのまま取り込むのはリスクがあるため、よく使われているミラーや公式に近い配布元を選び、可能なら内容をざっと確認してから運用するのが無難です。購読の取り込み手順そのものは別記事で扱っていますが、ルールセットも「外部から入る設定」だと心得すれば、更新ポリシーやバックアップの考え方が共有できます。
DIRECT 落ちの原因になります。GUI で名前を変えたら、ルール側の参照もセットで見直してください。
proxy-groups：PROXY の中身をどう組むか
ルールの行末にあるのは DIRECT か、proxy-groups で定義した名前です。海外向けに送る先としては、手動選択（select）、遅延計測で自動（url-test）、フォールバックなど、用途に合わせたグループを用意します。ベストプラクティスとしては、まず「とりあえず一つの安定ノード」へ繋げるより、計測付きの自動グループ＋手動で上書きできる select を併設しておくと、障害時の切り替えが楽になります。
国内 DIRECT と海外 PROXY の二層だけでは足りないケースもあります。例えば「ストリーミングだけ特定の地域ノード」「社内 VPN と併用」などは、別ポリシーグループを増やし、DOMAIN ルールで先に振り分ける形にすると読みやすいです。ルールが複雑になるほど、名前付けとコメント（YAML のコメントはクライアントによっては保持されます）で意図を残しておくと、三ヶ月後の自分を救えます。
DNS・fake-ip とルールの関係
ルール分流の成否は、名前解決がどこで・どのモードで行われるかに強く依存します。enhanced-mode: fake-ip を使う構成では、ドメインルールが効くタイミングと、実 IP が見えるタイミングが変わるため、「ドメインでは DIRECT のはずが IP 判定では PROXY」のようなズレが起きることがあります。期待どおりに動かないときは、DNS の設定（nameserver／fallback）、fake-ip のフィルタ、クライアントの「リモート DNS」相当のオプションをセットで確認してください。
また、IPv6 が有効な環境では、IPv4 だけのルールでは取りこぼす場合があります。自宅回線やキャリアの設定に合わせて、IPv6 の経路とルールの両方を意識するか、当面 IPv6 を切って切り分けるか、運用方針を決めておくとトラブルが減ります。TUN モードと併用する場合は、DNS ハイジャックやスタックの順序も絡むため、TUN モード解説 と合わせて読むと全体像が掴みやすいです。
よくあるつまずきと直し方
国内サイトなのに遅い・タイムアウトする
多くは国内向けトラフィックがプロキシ側へ流れているか、DNS が遠回りしているパターンです。ログでマッチしたルール行と実際のプロキシ名を確認し、GEOIP や DOMAIN リストの位置を見直します。購読テンプレが「全部 PROXY へ MATCH」に近い場合は、ルール全体の置き換えが必要になることもあります。
海外だけ見たいのに繋がらない
逆に、海外サイトが DIRECT のままだと、フィルタ下では到達できません。ルールのより上に DOMAIN 例外を足すか、該当ドメインが国内リストに誤って含まれていないかを疑います。企業ネットワークでは、プロキシ以前に出口でブロックされていることもあるため、別回線での比較が有効です。
MATCH の行き先を誤っている
最終行の MATCH が意図しないグループを指していると、全体の挙動が一気に変わります。テンプレを複数人で共有しているときは、自分用にリネームしたグループと、ルール末尾の名前が食い違っていないかを再確認してください。
まとめ：分流は「リストの設計」と「DNS」の両輪
国内直結と海外プロキシの分流は、華やかなノード選びより地味ですが、体感速度とコストのバランスを決める本丸です。ルールの順序、GEOIP／ルールプロバイダ、ポリシーグループ、DNS の四つをセットで理解しておけば、「購読は取れたが使い物にならない」状態から脱しやすくなります。Clash 系はルールベースで出口を細かく切り替えやすいのが強みなので、その強みを活かすなら、まずは mode: rule と rules の見直しから着手するのがおすすめです。
クライアントの導入や更新は、配布元が分かりやすい ダウンロードページ から行うと、OS ごとの推奨ビルドを選びやすく、後からルールをいじるときも同じ土台に立てます。他ツールと比べても、YAML と GUI の両方から運用できる柔軟さは Clash の魅力のひとつです。