本稿で押さえること
読み終わったあとにできるようになるのは次の四点です。(1) ルールは常に上から走査され、最初のヒットで評価が終わる、という前提で設定を読める。(2) MATCH は「どの行にも当てはまらなかった接続」を受け止める最終行として配置する。(3) 各行の末尾にあるポリシー名は proxy-groups の name: と一字一句そろえる必要がある。(4) リモート購読や GUI のマージが、あなたが書いたローカル行を上または下に押し出すと、見かけ上まったく同じ YAML でも挙動が変わる、という点を疑える。DNS や FakeIP のレイヤは Meta コア DNS ガイド、自動換線は url-test／fallback 稿 に譲ります。
基本：上から「最初の一行」が勝つ
Mihomo／Clash Meta のルールエンジンは、接続ごとに rules: を先頭から順に試し、条件が真になった時点でそこで打ち切ります。したがって、同じドメインに対して「下の方にもっと丁寧な行を書いた」つもりでも、その上に広い条件がすでに置いてあると、下の行には到達しません。典型例は、先頭付近にある GEOIP,CN,DIRECT や巨大な GEOSITE カテゴリ、あるいは購読側の RULE-SET が、あなたが追記した DOMAIN-SUFFIX,example.com,PROXY より前に展開されているケースです。逆に、細かい例外を上に、ざっくりした国別や MATCH を下に積むと、人間の意図と機械の挙動が一致しやすくなります。
覚え方：ルール配列は「上から読む優先度リスト」であり、「下ほど強い」わけではありません。先に書いた行ほど強いと考えてください。
MATCH 行は「残り全部」の受け皿
MATCH,<ポリシー名> は、それより上のどの条件にも当てはまらなかったトラフィックを一括で指定ポリシーへ送るための行です。多くの設定で最下行に置かれ、いわゆる最終フォールバックとして機能します。MATCH を忘れると、想定外の接続がデフォルト経路に落ちたり、クライアントによっては警告や挙動の差が出たりします。逆に MATCH だけを過信して「とりあえず全部プロキシ」と書くと、社内ドメインやローカル検査まで巻き込むので、細かい DIRECT 例外は必ず MATCH より上に置くのが安全です。ポリシー名はやはり proxy-groups の定義と一致させます。複数の MATCH を並べても、最初の MATCH で必ず吸い切られるため、実質的な意味はほぼありません。
# Sketch — MATCH is the catch-all at the end
rules:
- DOMAIN-SUFFIX,internal.corp,DIRECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,PROXY_GROUP
「書いたのに分流しない」六つのチェック
次のどれかに当てはまると、設定ファイルを開いても原因が見えにくいままです。① より上の行にすでに吸われている（最頻出）。② HTTPS などでホスト名がルール評価に乗っておらず、別条件に流れている（Sniffer や DNS モードを要確認）。③ ポリシー名の typo で、内核が別グループやデフォルトへフォールバックしている。④ 購読更新でルールブロックの順序が変わった。⑤ GUI の「ルール追加」が、思っているより上または下に挿入されている。⑥ GEOIP や IP-CIDR ベースの広い行が先にあり、ドメイン行に届かない。まずはクライアントの接続ログ／ルールヒット表示で「実際に命中した行」を一つ特定すると、①か⑥かがほぼ即断できます。
プロキシグループ名はルールと完全一致
rules: の各行の最後のフィールドは、だいたいの場合「その名前の proxy-groups エントリ」か DIRECT／REJECT などのキーワードです。ここで Proxy と PROXY のように大文字小文字やスペルを誤ると、期待したノード選択には繋がりません。さらに、url-test や fallback などのグループ型を指しているつもりが、実際には select 型の別グループを指している、というケースでも「ルールは合っているのにノードが変」と感じられます。ルール側と proxy-groups 側を並べて名前を照合し、GUI ではグループの表示名と内部名が一致しているかも確認してください。
購読・Rule Provider・GUI マージの影響
サブスクリプションやリモートルールは、ローカルの rules: とマージされたあとの一本のリストとして内核に渡ります。クライアントやテンプレートによっては、(A) リモートを先に全部展開しローカルを末尾に足す、(B) その逆、(C) プロファイルごとにカスタム、のいずれかです。「同じ DOMAIN 行を手で書いたのに効かない」のに心当たりがないときは、ダッシュボードで実際にロードされたルールの並びを開き、あなたの行の直上に何があるかを見てください。広域の RULE-SET や GEOSITE,google,… が先に来ていると、細かい例外は下に追いやる必要があります。運用上は、ローカル例外用の Rule Provider を先頭に近い位置へ持ってくる、あるいは購読テンプレートを変えてマージ順を制御する、のどちらかが現実的です。
読みやすい積み方の型
実務で迷ったら、次の型に寄せるとトラブルが減ります。最上段：社内ホスト・決済・テスト用など、ドメインや IP を明示した狭い例外。中段：GEOSITE や RULE-SET によるサービス束ね。その下：GEOIP で国別に残りを処理（CDN 任意外国 IP とのズレには注意）。最下行：MATCH。この骨格は GEOIP／GEOSITE 稿 の「DOMAIN 例外 → GEOSITE → GEOIP」と同じ精神です。プロセス単位で上書きしたい場合は PROCESS-NAME 稿 を参照してください（レイヤが異なります）。
ログで実証する手順
- 対象アプリで問題の接続を再現し、ログに出るFQDN または IPをメモする。
- ルールヒット／コネクション詳細で、命中したルール行（種別と対象）を特定する。
- その行より上に、同じトラフィックを拾う広い条件がないかを設定エディタで確認する。
- ホスト名が空なら、先に Sniffer と DNS を整える。
- 必要なら行を切り貼りで上へ移動し、再読み込み後にもう一度ログで確認する。
コンプライアンス
職場・学校・契約回線ではプロキシやトラフィック改道が禁止されていることがあります。許可された環境でのみ設定し、第三者の回線やアカウントに無断で中継しないでください。
注意：本稿の YAML は理解を助けるスケッチです。キーや修飾子の正式な一覧は、利用中の Mihomo バージョンのドキュメントで必ず確認してください。
ドキュメントと入手経路
用語対照や画面操作は ドキュメント・チュートリアル も参照してください。インストーラの取り違えを減らすには 公式ダウンロードページ を第一の入手元にすると安全です。ソースや Issue は GitHub が向いていますが、配布パッケージの主たる導線はサイト側に寄せる運用を推奨します。
まとめ
Clash Meta（Mihomo）の分流は、ルール配列の順序そのものが優先度です。上から最初に真になる行が出口を決め、MATCH はその残りを受け止めます。GEOIP や DOMAIN を覚えても、この順序とマージ結果を見ないままでは「書いたのに効かない」体感が繰り返されます。ログで命中行を一つ決め、必要なら例外を上へ持っていく——このループを回せば、ほとんどのケースは収束します。
テキストでルールを管理できるのは Clash 系の強みなので、購読とローカルの境界に短い英語コメントを残すと、数か月後の自分の負担がぐっと減ります。GUI と YAML を行き来する場合も、最終的に内核が読んでいる並びを正としてください。
同じクライアントでも、ログとルールエディタが往復しやすいものを選ぶと、一行動かした効果をすぐ確認でき、試行錯誤のストレスが下がります。