ルール分流が Clash の体験を決める

Clash 系クライアントの快適さは、ノードの速さだけでは決まりません。設定ファイルの中心にある rules と proxy-groups が、どの接続をプロキシに流し、どれを DIRECT にするかを決めるからです。サブスクリプションをそのまま読み込んだだけでは、国内サイトまで遠回りしたり、逆に必要なトラフィックだけがプロキシを迂回したりといった不整合が起きがちです。ここでは ドキュメント の考え方に沿いつつ、実務で効く設計パターンに絞って説明します。

前提として、現行のコアは多くの場合 mihomo（旧 Clash Meta）です。rule-set や rule-providers を併用すると、巨大なドメインリストも起動時負荷を抑えて扱えます。ルールの「書き方」だけでなく「並べ方」と「ポリシーグループの型の選び方」まで含めて設計することが、長期運用では欠かせません。

ルールは上から順に「最初の一致」で確定する

Clash のルールリストは先頭から評価され、最初にマッチした行だけが採用されます。後ろに同じドメイン向けの別ルールがあっても無視されるため、細かい例外を置く場合は具体的なルールを上に、緩いルールを下に並べるのが原則です。典型的には、広告ブロック用の REJECT、社内ドメインや LAN 向けの DIRECT、ストリーミング向けの専用プロキシグループなどを先に置き、最後に GEOIP や MATCH で全体を受けます。 

# Conceptual order (simplified)
rules:
  - DOMAIN-SUFFIX,company.corp,DIRECT
  - DOMAIN-SUFFIX,ads.example,REJECT
  - GEOIP,JP,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

上記は概念例です。実際の国コードやグループ名は、利用している GeoIP データベースとサブスクのノード名に合わせて調整してください。MATCH は必ず最終行に置き、ここでフォールバック先のポリシーグループ（多くは Proxy や 🚀 节点选择 など）へ集約する構成が一般的です。

ドメイン系ルール：DOMAIN / SUFFIX / KEYWORD / REGEX

ドメイン指定は、パフォーマンスと可読性のバランスが取りやすい領域です。DOMAIN は完全一致、DOMAIN-SUFFIX はサフィックス一致（サブドメインをまとめて扱うのに向く）、DOMAIN-KEYWORD はホスト名にキーワードが含まれる場合にマッチします。誤爆しやすいのが DOMAIN-KEYWORD で、短いキーワードは意図しないサイトにまでマッチするため、可能なら DOMAIN-SUFFIX か RULE-SET に寄せる方が安全です。

  • DOMAIN：特定サービスのトップドメインだけを厳密に指定したいとき
  • DOMAIN-SUFFIX：CDN 配下の多数サブドメインを一括で同じポリシーへ流したいとき
  • DOMAIN-KEYWORD：ルール数を抑えつつ広く拾うが、テストで挙動確認が必須
  • DOMAIN-REGEX：複雑なパターン向け。コストが高めなので多用は避けるのが無難

コミュニティ公開の rule-providers（例：広告・追跡・地域別リスト）を使う場合、behavior: domain や classical の定義に合わせて RULE-SET 行を追加します。インラインで数千行のドメインを書くより、外部セット化した方が更新も差分も管理しやすく、mihomo ではパフォーマンス面でも有利です。

GeoIP：国コードで「残りの IP」を束ねる

GEOIP,JP,DIRECT のように記述すると、解決済み IP が MaxMind 系データベース上でその国に属すると判定されたトラフィックがマッチします。日本在住ユーザーであれば、国内向けトラフィックをプロキシに回さず直結させるために JP を DIRECT にすることが多いです。中国圏のリストと併用する構成では CN や専用ルールセットを先に置く例もよく見られます。

GeoIP の精度はデータファイルの鮮度に依存します。geodata-mode や geoip.dat / country.mmdb の更新設定を確認し、長期間放置しないでください。意図しない国判定は「なぜかこのサイトだけ遅い」「国内動画がプロキシ経由になる」などの原因になります。

GEOIP はドメインルールで拾いきれなかった接続向けの「安全網」として機能します。そのためドメインルールと重複する記述を増やしすぎるより、明確に分岐したいサービスだけドメイン側に寄せ、残りは GeoIP と MATCH に任せる方がメンテナンスしやすいです。

IP-CIDR・SRC-IP-CIDR とルールの段階設計

VPN や社内ネットワークのレンジは IP-CIDR で DIRECT に固定することが多いです。送信元ベースの SRC-IP-CIDR はマルチデバイスやスプリット環境で使う上級テクニックですが、家庭用単一 PC では必須ではありません。IP-CIDR を大量に並べると評価コストが増えるため、可能ならまとまった CIDR に整理するか、プロバイダー別ルールセットに委ねる方法も検討してください。

プロキシポリシーグループ：4 つの型と使い所

proxy-groups の type によって挙動がまったく異なります。ここが分かると、「ルールでどのグループ名を指せばよいか」が設計しやすくなります。

select：手動選択のハブ

select はユーザーが UI 上でノードや別グループを選ぶための手動ポリシーです。「とりあえず全部ここに集約」用のマスターグループとして使われることが多く、ルールの最終行 MATCH がこのグループを指す構成は定番です。名前はサブスク提供者のローカライズ（日本語や絵文字入り）でも問題ありませんが、ルール側の参照名と完全一致させる必要があります。

url-test：遅延計測による自動選択

url-test は指定した URL への疎通とレイテンシを定期的に測り、最も速いプロキシを自動で選ぶタイプです。interval や tolerance を調整し、頻繁な切り替えでセッションが不安定にならないようバランスを取ります。動画視聴やゲームなど、特定アプリだけ別レーンにしたい場合は、専用の url-test グループを切り、ルール側でそのグループ名を指定するパターンが実用的です。

fallback：可用性優先のフェイルオーバー

fallback はリスト順に健全性を確認し、生きている最初のプロキシを使います。「速さ」よりも「繋がること」が優先される出口や、不安定なノード列の保険として向いています。url-test と目的が近いですが、選択ロジックが異なるため、混同しないようにドキュメント化しておくとチーム運用で助かります。

load-balance：分散とその注意点

load-balance は複数ノードに負荷分散しますが、同一サービスが同一セッションを複数 IP で見なすとログインや決済で問題になることがあります。用途を限定し、必要ならスティッキーや同一ノードへの固定ルールを検討してください。

ベストプラクティス：運用で効くまとめ

  1. ルール順を「例外 → 地域 → 全体」に揃える。広告・LAN・社内・特定ストリーミングなど、最優先で決めたいものから並べる。
  2. 巨大リストは rule-providers に逃がす。リポジトリや CDN 上の更新可能なセットを参照し、ローカルは rules を読みやすく保つ。
  3. GeoIP データを定期更新する。古い DB は誤分類のもとになる。
  4. ポリシーグループ名をルールと一貫させる。タイポは「沈黙の全直通／全プロキシ」につながりやすい。
  5. DIRECT とプロキシの境界をログで確認する。クライアントの接続ログや外部コントローラの可視化で、意図した経路かを検証する。

これらを押さえておけば、サブスクリプションのノード構成が変わっても、ルール側の骨格は大きく崩さずに済みます。GUI クライアントでは編集がしやすい一方、YAML の全体像を一度把握しておくとトラブル時の切り分けが速くなります。

GUI とコアをセットで考える

ルール分流はテキストで完結しますが、日々の切り替えはクライアントの UI に依存します。mihomo 対応の最新クライアントでは、ポリシーグループの切り替え、TUN / システムプロキシのトグル、ログ確認までが一画面にまとまっているものが多く、本記事で整理した select や url-test の実体をそのまま操作できます。似た機能のツールと比較しても、ルール表現の柔軟さとコミュニティのルールセット資産の両方を取りにいきやすいのが Clash 系の強みです。

Clash を無料ダウンロードして、ルール分流をまとめて体感する → インストールからプロファイル読み込みまでを短時間で済ませ、上記の設計をそのまま試せます。