Clashのrule-providers設定術：GitHubで自作ルールを管理する方法

NT-06.1rule-providersとは何か、rulesに直書きしない理由

ClashおよびClash Meta(mihomo)のrule-providersは、ドメインやIPアドレスの集合を外部ルールセットとして登録し、必要なときにrulesから呼び出すための仕組みです。設定ファイルのrulesへ大量のDOMAIN-SUFFIXやIP-CIDRを直接書く方法もありますが、サービスごとの項目が増えるほど編集しにくくなり、更新のたびにメイン設定全体を変更しなければなりません。rule-providersを使えば、ルールの本体と通信の振り分けロジックを分離できます。

例えば、動画サービス用、広告用、社内システム用、ゲーム用というように用途別のファイルを作り、メインProfileではそれぞれを異なるポリシーグループへ割り当てます。ルールの一覧を更新しても、ノード定義やDNS、TUN設定まで触る必要はありません。複数の端末や複数のProfileで同じルールを使う場合も、ルールセットを一か所で管理できるため、表記ゆれや更新漏れを減らせます。

GitHubのリポジトリを保管場所として利用する場合、YAMLファイルを編集する場所と、Clashが取得する公開ファイルの場所を分けて考える必要があります。リポジトリは履歴、レビュー、変更差分、ロールバックを管理する台帳であり、Clashはそこから公開されたルールファイルを定期取得するクライアントです。リポジトリを作っただけではルールは適用されず、Profile側にrule-providersとRULE-SETの両方を記述して初めて動作します。

項目役割確認するポイント
rule-providers外部ルールセットの取得元と形式を登録する名前、type、behavior、url、pathが正しいか
behaviorルールの種類を宣言するdomain、ipcidr、classicalを内容に合わせる
RULE-SET登録済みルールセットを実際の振り分けに使うプロバイダ名とポリシーグループ名が一致するか
path取得したルールのローカル保存先を指定する書き込み可能な相対パスまたは絶対パスか
最初に分けるべきもの

rule-providersはノードやプロキシグループを提供する機能ではありません。ノードはproxies、グループはproxy-groups、外部ルールの取得と参照はrule-providersで管理します。この3つを混同すると、ルールファイルを登録したのに選択画面へノードが追加されるといった誤解につながります。

NT-06.2GitHubでルールを作るときのYAML設計と公開方法

最初にリポジトリ内のディレクトリ構成を決めます。ルールファイルを一つの場所へ集めるだけでも動作しますが、用途別にファイル名を分けた方が更新対象を把握しやすくなります。例えばrules/streaming.yaml、rules/messaging.yaml、rules/ads.yamlのように分類し、ファイルの先頭には用途が分かるコメントを残します。コメントはルール判定には影響しませんが、後から内容を確認する際の手がかりになります。

behavior: domainはドメイン形式のルールを扱う場合に使います。ドメインのリストを単純に並べる形式ではなく、mihomoが対応するルールプロバイダの書式に合わせる必要があります。behavior: ipcidrはCIDR形式のネットワーク範囲を対象にし、behavior: classicalはDOMAIN-SUFFIXやDOMAIN-KEYWORDなど、Clashの従来型ルール記法を含むファイルに使います。内容とbehaviorが一致しない場合、取得自体は成功してもルールが期待どおりに解釈されません。

以下は、外部のHTTPルールセットを取得する基本例です。URLは実際に公開したファイルの配信先へ置き換えてください。保存先のpathはクライアントが書き込める場所を指定し、同じ名前のプロバイダを複数定義しないようにします。

rule-providers:
  streaming:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.invalid/rules/streaming.yaml"
    path: ./ruleset/streaming.yaml
    interval: 86400

  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://example.invalid/rules/private-network.yaml"
    path: ./ruleset/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,streaming,Proxy
  - RULE-SET,private-network,DIRECT
  - MATCH,Proxy

GitHub側では、編集用のブランチと公開用の既定ブランチを分ける運用が安全です。ルールを変更したら差分を確認し、ドメインの誤記、重複、意図しない広すぎるキーワードがないかを確認してから公開ブランチへ反映します。特にDOMAIN-KEYWORDは一致範囲が広く、短い文字列を指定すると無関係なドメインまで拾う可能性があります。サービス名の一部だけを登録するより、管理可能なドメインサフィックスを優先してください。

公開URLには、常に変化する既定ブランチを直接指定する方法と、タグや特定コミットを基準に固定する方法があります。前者は更新が簡単ですが、公開側で変更された内容が次回更新時に自動適用されます。後者は再現性を保ちやすく、意図しないルール変更を避けられます。自動更新を重視する個人用リストと、業務端末で利用する固定リストを同じ運用にせず、用途に応じて更新頻度と公開単位を決めることが重要です。

外部ファイルは設定の一部として扱う

Clashは外部ルールを取得できても、その内容が安全か、意図したサービスだけを対象にしているかまでは保証しません。公開URLの所有者、変更履歴、更新日時を確認し、見覚えのない大量追加やMATCH相当の広い条件が混入していないか確認してください。取得元が停止した場合に備え、最後に正常だったファイルをローカルに保管しておくと復旧しやすくなります。

NT-06.3RULE-SETの呼び出し方とルール優先順位

rule-providersに登録しただけでは通信は振り分けられません。rulesセクションにRULE-SET,プロバイダ名,ポリシーの形式で記述し、対象通信をどのグループへ送るかを指定します。ここで参照するプロバイダ名は、URLのファイル名ではなく、YAML内で定義したキーです。例えばstreamingというキーを登録した場合、ルール側もRULE-SET,streaming,Proxyと書く必要があります。

Clashのルールは通常、上から下へ評価され、最初に一致したルールが採用されます。そのため、広い条件を上に置くと、後ろに書いた細かい例外ルールへ到達できません。例えば広告用のドメインセットを最上段に置いた後で、特定サービスを直接接続へ戻すルールを書いても、広告セットの条件に先に一致すれば例外は実行されません。例外を先に置き、一般的な集合を後ろへ置くのが基本です。

rules:
  - DOMAIN,login.example.invalid,DIRECT
  - RULE-SET,private-network,DIRECT
  - RULE-SET,streaming,Streaming
  - RULE-SET,ads,REJECT
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

この例では、特定のログインドメイン、プライベートネットワーク、動画サービス、広告ルール、LAN向けの順で判定され、最後にどの条件にも一致しない通信がProxyへ送られます。MATCHは最終的な受け皿なので、通常は最下部に置きます。先頭付近に置くと、それ以降のrule-providersが実質的に使われなくなります。

複数のrule-providersが同じドメインを含む場合も、ファイルの読み込み順で自動的に優先度が決まるわけではありません。実際の優先度はrulesに書いたRULE-SETの位置で決まります。動画サービスの集合と広告集合が重なる場合、どちらを優先するかを明示し、必要なら例外用の単独ルールを最上段へ追加してください。

NT-06.4更新、検証、反映されない場合の切り分け

設定を保存したら、まずProfile全体の構文エラーがないかを確認します。YAMLはインデントが意味を持つため、タブ文字とスペースの混在、キーの重複、コロン後の記述ミスで読み込みに失敗することがあります。クライアントの設定検証機能やログ画面にエラーが表示される場合は、いきなりルールの内容を疑うのではなく、最初に行番号とインデントを確認してください。

  1. ルールファイルをブラウザまたは取得ツールで開き、URLがエラーページや空の応答になっていないことを確認する。
  2. ファイル形式とbehaviorが一致しているか確認する。ドメイン形式のファイルをipcidrとして登録しない。
  3. Clashクライアントのルールプロバイダ一覧で、対象プロバイダの取得時刻とルール件数を確認する。件数が表示されない場合は取得または解析に失敗している可能性がある。
  4. RULE-SETの名前がプロバイダのキーと一致しているか、送り先のポリシーグループが現在のProfileに存在するか確認する。
  5. テスト用のドメインへアクセスし、ログで実際に一致したルール名と選択された策略グループを確認する。
  6. 変更直後だけ古い動作が残る場合は、プロバイダを手動更新し、必要に応じてクライアントを再起動してローカルキャッシュの反映状態を確認する。

ルールが取得できているのに動作しない場合、最も多い原因は優先順位です。対象ドメインが別のrule-providerに先に一致していないか、上位にあるDOMAIN-SUFFIXやGEOIPが通信を取っていないかを確認します。また、アプリケーションがIPアドレスへ直接接続している場合、ドメイン用のproviderは一致しません。TUNモード、DNSの解決方式、IP-CIDRルールの必要性を合わせて確認してください。

GitHub上で更新しただけでは即時反映されない

Clash側のintervalは定期更新の間隔であり、リポジトリへ変更を保存した瞬間に全クライアントへ配信する機能ではありません。検証中はクライアントからプロバイダの手動更新を実行し、公開ファイルの内容とローカル保存内容が一致しているかを確認してください。更新間隔を極端に短くすると取得元への負荷や一時的な制限につながるため、通常は数時間から1日程度の運用が扱いやすい範囲です。

運用が安定したら、ルールの変更理由、対象サービス、想定するポリシーグループ、公開日をコミットメッセージや変更履歴に残します。不要になったドメインを定期的に削除し、同じ用途のファイルを増やしすぎないことも重要です。rule-providersはルールを無制限に外部化する仕組みではなく、更新頻度と責任範囲が明確なルールセットを管理するための仕組みです。小さなファイルから始め、取得、解析、優先順位、実通信での判定を一つずつ確認してから対象範囲を広げると、意図しない全域プロキシや直接接続を防げます。

Clash をダウンロード