先頭だけが勝つ：ルールリストの評価順

Clash（Mihomo を含む）の rules:／相当ブロックは、記述した順に上から評価し、最初に一致した行で探索を打ち切るのが基本です。したがって「下の方に丁寧に DOMAIN 行を追記したのに反映されない」典型原因は、その上に「もっと早く当たる広い規則」があることです。接続ログには、どのルール名やポリシーに載ったかの手がかりが出ます。上流で既にヒットしているとき、あなたが後段に書いた行は読まれません。設計の全体像や Rule Provider は 分流のベストプラクティスに譲り、本章では並び順の事故に絞ります。

「誰かが強い／弱い」というより位置の早さが効きます。RULE-SET を束で読込むときも、その集合を展開した各行は設定の並び順に従って評価され、ユーザーが自分で並べていないリストを複数インポートすると意図せず広い規則が先頭側に来ることがあります。GUI が Rule Provider を「上」「下」に移動できる場合は、まずそこを疑ってください。

MATCH を最後に置く理由と、「抜ける」とき

MATCH は「残りすべて」を受け止める行としてよく文末に置かれます。形式的にはMATCH, で指定したストラテジ（またはプロキシ群に送る処理）だけでなく、環境によっては RULE SET の再帰的な仕様やクライアントの合成ルールの影響で、MATCH が期待どおり兜底にならない構成も稀に見られます。まずはMATCH より上に自分の細かい行が並んでいないかを一覧で確認しましょう。あわせて、プロファイルの合成（mixin／include）で末尾に別の rules が続いていると、見えている YAML の「最後の行」が本当の最後ではないケースがあります。mixin や併合を使っている場合は、実際にコアが読み込んだ設定のルール塊を追いかけてください。

ℹ MATCH を「保険」として置くのは正しいのですが、保険より前に当たる規則がすべてを決めます。「MATCH を書いたのに効かない」と感じたら、多くはその上の行が原因です。

より上位の広い行がすべてを決めてしまう

典型例は次のようなパターンです。DOMAIN-SUFFIX,google.com や GEOSITE,google のような束の広い行が先頭付近にあり、その下に特定サブドメインだけ DIRECT にしたい行を置いても、先に当たった行のストラテジが勝つため、下の行は評価されません。逆に FINAL 相当の表現がないコアでは、MATCH 以外の一般名が使われますが、思想は同じです。

回避策の方向性はシンプルで、例外を先に、デフォルトを後に並べ替えるか、Rule Provider を分割して依存関係の薄い順に読み込むか、あるいはもっと具体的な DOMAIN／DOMAIN-SUFFIX を上に寄せることです。どのクライアントでもこの原則は同じなので、GUI でルール順をドラッグできるかも含め、運用しやすい道具を選ぶと事故が減ります。

ドメイン規則の前／後：GEOIP・IP-CIDR との並べ方

ターゲットがドメインで解決されるフローなら、多くの場合 DOMAIN 系の行で望む出口に寄せられます。一方で、既に接続が 実 IP に対して張られており、かつルール評価がその段階に入ると、GEOIP や IP-CIDR の行が先に意味を持ちます。たとえば「国内 IP は DIRECT」を GEOIP,CN で書いた列が、細かく書いたドメイン行よりリスト上で上にあると、すべての CN 宛トラフィックがまとめてそこへ流れる、といった挙動になります。また mmdb が古く国コード判定がずれると GEOIP が誤経路になるので、順序とは別次元の問題としてデータ更新があります（手順は GEOIP と mmdb／geosite 更新記事を参照）。「ルール順は合っている気がするのに GEO だけ変」と感じたら、その切り分けです。

IP-CIDR を企業 CDN や社内ネットへ使うときも、より具体的な細いプレフィックスを上に、広い0.0.0.0/0 に近い行をリスト後方にまとめる、という順序運用が安全です。自動選択のストラテジー側で出口が変わる場合も、ログ上は「ノードが変わった」ように見えるだけで、ルール評価の結果は別です。両方見てください。

DNS・Fake‐IP と接続ログに出る名前のズレ

Fake‐IP モードでは、名前解決の段階で返るアドレスと、ユーザーが頭に描いている実サーバ側の組み合わせが一致しないことがあります。ブラウザの開発者ツールで見えているホストと、Clash がルール評価に使ったホスト情報が異なると、「ドメイン行を増やしたのに効かない」ように見えます。DNS の nameserver／fallback／fake-ip-filter は 別稿でまとめています。また LAN やルーター管理画面向けに例外を張るときは、 sniffing とルール両方が絡むため、並べ順だけでは足りない事例もあります。

IPv4／IPv6 の二重スタックでは、「こちらでは国内と判定した IPv4 と、別経路で出て行った IPv6」が原因で出口がずれることがあります。IPv6 と DIRECT の記事とセットで読むと、GEOIP と併記したときの切り分けがしやすくなります。

実測：ログでの当たり行と並べ替え順

運用での推奨手順を短くまとめると次のとおりです。①問題のサイトやアプリを再現させ、②接続ビューやログで適用ポリシーとルール名（またはヒットした行の説明）を確認、③その行が rules リストのどこかをYAMLで突き合わせ、④「その行より前に当たっている可能性のある広い規則」を探して上下を入れ替える、です。TUN モードではシステム全体のトラフィックがクランプに載るので、ブラウザ拡張のみの例外と混ざらないよう確認してください。ログの読み方自体に不安があるときは、その記事から入ると流れやすいです。

まとめ

「上から並べているのに想定しないノード」「ドメイン行を増やしたのに効かない」は、ほとんどが前列の広い規則、GEOIP／IP‐CIDR とドメイン系の並び、DNS・Fake‐IP による見かけと実体のズレのどれか（または複合）です。MATCH は末尾のまとめ役として妥当ですが、MATCHより上のすべてが先に判定されることを前提に並べ替えと漏れチェックを行ってください。対症療法的にノードだけ入れ替えても、同じ並び順なら同じ迷子に戻りがちです。GUI でルールが整理しやすいクライアントを選び、ログでヒット行を見ながら固めると運用が楽になります。実装の入手は配布ページ経由が分かりやすいです。→ Clash を無料でダウンロードし、この記事の並び替え手順で自分のリストを再検証してください。