分流ルールで決まっていること
Clash やそのフォーク（Mihomo コアを内蔵するクライアントなど）では、接続ごとに「どの出口へ送るか」を rules セクションのルール列が決めます。ここでいう分流とは、ドメイン名・IP アドレス・地理情報などの接続の特徴を手掛かりに、DIRECT（直結）、REJECT（遮断）、あるいは proxy-groups で定義した名前（例：PROXY や AI）へ振り分ける仕組みです。
GUI では「ルールモード」と呼ばれることが多いですが、YAML 上では mode: Rule のときにこのリストが有効になります。ルールを一行も書かない構成では最終的にフォールバック行の方針に寄ります。逆に言えば、意図した分流を再現したいなら、rules の並びと各行の意味を押さえるのが最短ルートです。
評価順序がすべての起点
分流で最初に覚えるべき鉄則は、上から順に一行ずつ評価され、最初にマッチした行で打ち切られるという点です。したがって「広く当たるルール」を先頭に置くと、その下に書いた細かい例外が永遠に評価されません。典型例は、先頭付近に強いワイルドカードや巨大な RULE-SET を置いてしまい、特定サービスだけ別出口にしたい行が届かないパターンです。
現実的な並べ方の型は次のとおりです。(1) テレメトリ遮断や LAN 直結など、誤魔化せないローカル系を先に固める。(2) 自分だけの例外（社内ドメイン、決済サイトなど）を短く載せる。(3) 購読ルールセットや GEOIP など、カバー範囲の広い行を置く。(4) 最後に MATCH で全体の逃げ道を決める。購読テンプレが末尾に MATCH を置いているなら、あなたのカスタム行は原則としてそのより上に差し込む、と覚えると安全です。
代表的なルール種別を押さえる
コアの世代やビルドによって細かな別名がありますが、入門で押さえるべき主役は次のとおりです。DOMAIN は完全一致、DOMAIN-SUFFIX はサフィックス一致（子ドメインを含む）、DOMAIN-KEYWORD はホスト名にキーワードが含まれるか、といった文字列マッチ系です。速さと可読性のバランスがよく、特定サービスを切り出すときの主力になります。
IP-CIDR は IPv4／IPv6 のプレフィックス一致、GEOIP は GeoIP データベースによる国・地域コードでの判定です。動画 CDN のようにドメインより IP の方が安定して識別できるケースもありますが、VPN やプロキシチェーンによっては見え方が変わる点には注意が必要です。SRC-IP-CIDR のように送信元側を見るタイプは、ルーター用途や高度な分割で登場します。
最終行によく登場する MATCH は「ここまでどれにも当たらなかったらこのポリシーへ」という網羅的な落とし穴です。テスト中に意図せぬ通信がここへ流れていないか、ログで定期的に確認する習慣があると安心です。
ポリシー名は proxy-groups と一致させる
ルール行の末尾に書く文字列は、多くの場合 proxy-groups に宣言したグループ名か、組み込みの DIRECT／REJECT などです。ここが一文字でもずれると「存在しないポリシー」として扱われ、読み込みエラーや期待と異なる挙動の原因になります。大文字小文字も区別されることが一般的なので、GUI で作った名前と YAML を突き合わせてください。
サブスクリプションが吐き出す PROXY や Auto などの名前をそのまま使うか、自分用にリネームして全体を一括置換するかは運用次第です。後から読みやすくするなら、意味のある短い英数字に統一し、ルール側とグループ側を同じ辞書で管理するのがおすすめです。
最小サンプルから書き始める
いきなり本番ファイルを編集するのではなく、次のような極小スニペットをメモ帳に置き、用語の対応を確かめると学習コストが下がります。以下は説明用の例であり、実際のグループ名やパスは手元の設定に合わせて置き換えてください。
# Example only — align names with your profile
rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
- DOMAIN-SUFFIX,cdn.example,PROXY
- GEOIP,JP,DIRECT
- MATCH,PROXYこの並びは「社内ドメインは直結」「特定 CDN はプロキシ」「日本向け GeoIP は直結」「残り全部プロキシ」という意図のダイアグラムを表しています。本番では購読が挿す数十〜数百行の前後関係があるため、差分を小さくし、変更のたびに一行ずつ意図を言語化するとミスが減ります。
DNS とルールの境界を混同しない
「ルールにドメインを書いたのに効かない」という相談の多くは、実際の接続がすでに IP 化されたあとにルール評価が走っており、想定していた DOMAIN 系に届いていないケースです。Fake-IP モードやローカル DNS のキャッシュ、ブラウザの DNS-over-HTTPS など、解決経路はクライアント設定と OS の両方にまたがります。
切り分けの基本は、問題の接続についてログに出るホスト名と IPをメモし、どのルールタイプに乗るべきかを紙に書くことです。必要なら TUN モードの解説とあわせて読み、システムプロキシだけでは取りこぼすアプリがないかも確認してください。
検証の型：変更→再接続→ログ
ルールを足したら、ブラウザのタブを閉じたりアプリを再起動したりして接続を作り直すことを忘れがちです。長寿命の WebSocket や HTTP/2 は、古い経路を保持したままに見えることがあります。クライアントの接続一覧やログで、対象ホストが期待したポリシー名に紐づいているかを確認します。
うまくいかないときは、(1) ルール順で上書きされていないか、(2) ポリシー名の綴り、(3) DNS 由来のホスト名不一致、(4) UDP や QUIC が別経路になっていないか、の順に見ると早いです。AI 系サイトのようにドメインが増えやすいサービスでは、分流チェックリストの考え方も参考になります。
肥大化したら Rule Providers へ
ドメインや IP の列挙が数百行を超え始めたら、メインの設定から切り離して外部ルールセットとして管理する段階です。Mihomo 系では rule-providers や RULE-SET 参照が定番で、更新間隔やキャッシュとセットで運用します。詳細は当ブログのRule Providers 上級ガイドに譲りますが、「手書きの可読さ」と「購読の省力化」のトレードオフを意識して移行タイミングを決めるとよいでしょう。
初心者が踏みがちな落とし穴
順序の誤り
広い DOMAIN-KEYWORD を先頭に置くと、意図しないホストまでまとめてヒットします。キーワード系は最後の手段として狭く使うか、より具体的な DOMAIN-SUFFIX で囲い込むのが無難です。
GEOIP と実測のズレ
データベースの版や到達経路によって、思った国コードにならないことがあります。GeoIP 行を盲信せず、問題の接続についてログの実値を確認してください。
購読更新とのマージ
テンプレ側の MATCH 位置やデフォルトグループが変わると、あなたのカスタム行の「効き」が静かに変わることがあります。大きな更新のあとは、差分を読む時間を確保するのがプロです。
出所の曖昧なリストに注意
コミュニティ配布の巨大ルールセットは便利ですが、どのドメインをどちらに送るかという信頼を丸ごと外部に委ねることになります。可能なら公開リポジトリと更新履歴を確認し、本番と検証でプロファイルを分けてください。オープンソースの信頼性については Mihomo の GitHub リポジトリで仕様変更を追うのが確実です。インストールパッケージの主な入手経路は GUI の更新や当サイトの導線とし、GitHub は仕様・Issue 確認に使い分けると混乱が少ないです。
クライアントとドキュメントを併読する
実際の編集画面は製品ごとに名称が異なりますが、根底は同じ YAML です。まずは公式のクライアント入手ページから自分の OS に合うビルドを選び、エクスポートした設定に対して本稿の順序立てを当てはめてみてください。用語のつながりを俯瞰したい場合はドキュメントとチュートリアル一覧も併読すると、システムプロキシや TUN、DNS の章との対応が掴みやすくなります。
まとめ
カスタム分流ルールの本質は、接続の特徴をどの順で見るかと、マッチしたあとにどの出口名へ渡すかの二点に集約されます。DOMAIN 系でサービス単位を切り出し、IP 系や GEOIP で広い塊を処理し、最後に MATCH で逃げ道を決める——この型を身体に染み込ませれば、購読テンプレの上に自分用の数行を足すだけでも事故率が大きく下がります。
同種ツールのなかでも、Clash エコシステムはルール表現の蓄積とクライアントの選択肢の豊富さが強みです。いきなり完璧なリストを目指さず、まずは一つのドメインを別グループに逃がすなど小さな成功体験を積み重ねるのが、長く快適な分流設定への近道です。