· 購読と設定 · 読了時間：約10分

Clashのrule-providers設定｜GitHubでルールセットを管理・自動更新する方法

ClashやMihomoの設定ファイルにルールを直接書き足すのではなく、rule-providersで分離して管理する方法を解説。YAMLルールセットの作成からGitHubへの配置、behavior・format・path・intervalの設定まで、実例で紹介します。ルールの優先順位や更新エラー、非公開リポジト…

rule-providersの役割と、管理対象を分ける考え方

rule-providersは、ドメインやIPアドレスなどのルールをメイン設定から分離し、外部ファイルとして読み込む仕組みです。たとえば、広告用ドメインの一覧や社内ネットワークの除外ルールを別ファイルに置けば、ルールを追加・削除しても大きな設定ファイル全体を編集せずに済みます。ファイルの変更履歴をGitHubで管理すると、いつ、どの行を、なぜ変更したかを追跡しやすくなります。

ルールプロバイダーはノードの購読先ではありません。ノード情報を提供するproxy-providersとは目的が異なり、プロバイダーに書かれたルールをメイン設定のrulesから参照して初めて通信の振り分けに使われます。また、設定を読み込むのはクライアントの画面ではなく実際に動作しているカーネルです。以下の例を使う前に、使用中のClash系クライアントのカーネルがrule-providersと指定するファイル形式に対応しているか確認してください。

リポジトリは公開範囲にも注意が必要です。公開リポジトリのファイルは誰でも閲覧できるため、アカウント情報、サブスクリプションURL、トークン、個人を特定できる接続先を含めないでください。社内用や個人用のルールを公開できない場合は、公開リポジトリではなく、使用するカーネルが認証方法を含めて対応している保管先を選びます。認証が必要なURLを設定ファイルに直接記述して公開する方法は避けてください。

プロバイダーの主要項目とファイル形式

HTTP経由で取得するプロバイダーでは、type、behavior、url、path、intervalを中心に設定します。behaviorはルールの種類を示し、公開ファイル内の内容と一致させる必要があります。次の例は設定の形を示すためのひな形です。<OWNER>などの部分を、実際に公開したリポジトリとファイルの情報に置き換えてください。

rule-providers:
  custom-domains:
    type: http
    behavior: domain
    url: "https://<RAW-FILE-URL>/custom-domains.yaml"
    path: ./rules/custom-domains.yaml
    interval: 86400
    format: yaml

  custom-ip:
    type: http
    behavior: ipcidr
    url: "https://<RAW-FILE-URL>/custom-ip.yaml"
    path: ./rules/custom-ip.yaml
    interval: 86400
    format: yaml

rules:
  - RULE-SET,custom-domains,Proxy
  - RULE-SET,custom-ip,Proxy,no-resolve
  - MATCH,DIRECT

YAML形式のドメインプロバイダーは、たとえば次のような構造にできます。payloadの下にはドメインの項目を並べます。

payload:
  - "+.example.net"
  - "service.example.org"

classicalを使うファイルは、ドメイン名だけでなくDOMAINやIP-CIDRなど、通常のルールに相当する条件を含めます。domain用のファイルに完全なルール文字列を入れるなど、宣言したbehaviorと内容を混在させると、解析に失敗したり期待した条件で照合されなかったりします。まず種類ごとにファイルを分け、最小限の項目で読み込みを確認すると原因を追いやすくなります。

GitHubで公開し、自動更新につなげる

ルールファイルをGitHubで管理する基本的な流れは、リポジトリの作成、ファイルの配置、配信URLの確認、Clash設定への登録です。リポジトリ内では、たとえばrules/ディレクトリを作り、domain.yamlやipcidr.yamlのように用途が分かるファイル名を付けます。READMEには用途、ルールの追加基準、更新担当、確認日を記録すると、後から見たときに意図を判断しやすくなります。

  1. ファイルを作成する：まずは数件だけの小さなルールセットを用意します。YAMLのインデントはスペースで統一し、タブ文字や不要な全角記号が混ざっていないか確認してください。
  2. リポジトリにコミットする：変更理由が分かるコミットメッセージを付けます。既存ルールを置き換えるときは、変更前後の差分を確認し、誤って大量の行を削除していないか調べます。
  3. 配信URLを確認する：リポジトリのファイル表示画面と、ファイル本文を返す配信先は異なります。クライアントで使うURLを開き、ログイン画面やHTMLではなく、期待するルールファイルの内容が返ることを確認してください。
  4. 設定へ登録する：プロバイダーをrule-providersに追加し、同じ名前をRULE-SETで参照します。名前の大文字・小文字やハイフンの違いも照合してください。
  5. 読み込み後に検証する：設定を再読み込みし、構文エラーがないこと、プロバイダーの取得が成功すること、対象の接続が意図したポリシーに一致することを順に確認します。

ブランチの先端を指すURLは、コミットするたびに配信される内容が変わります。ルールを頻繁に更新したい場合には便利ですが、変更後に問題が起きたとき、どの版を取得したか追跡しにくくなることがあります。安定性を優先するなら、タグやコミットを基準にした固定URLで検証済みの版を利用し、更新は差分を確認してから切り替える方法があります。使用する配信URLが固定参照に対応するかは、実際のURLとクライアントのログで確かめてください。

更新間隔による定期取得と、GitHub上でファイルを変更した直後の反映は別の動作です。intervalを設定していても、変更の反映時刻は取得タイミングやキャッシュ、ネットワーク状態に左右されます。すぐに試したいときは、クライアントの設定再読み込みやプロバイダー更新機能を使い、その後に取得日時と読み込まれた内容を確認します。クライアントによってボタン名や画面の場所は異なるため、特定のメニュー名をすべてのアプリに当てはめないでください。

ルールの順序を決め、意図した振り分けを検証する

ルールは通常、上から順番に評価され、最初に一致した条件のポリシーが使われます。そのため、RULE-SETをどこに置くかが重要です。より限定的なルールを先に置き、広い範囲を対象とするルールを後に配置します。最後のMATCHは一致しなかった通信を受け止めるため、一般に末尾に置きます。先に広いプロバイダーやMATCHを置くと、その下に追加したルールへ到達しないことがあります。

例のProxyは、実際の設定に存在するプロキシグループ名に置き換えてください。DIRECTに振り分ける場合は、目的に合う通信だけを対象にしているか確認します。また、no-resolveはIP-CIDR系ルールで照合する際にドメイン名の解決を行わない指定として使われますが、すべてのルールへ機械的に付けるものではありません。名前解決が照合に必要な構成で付けると、意図した判定に影響する場合があります。

  1. 設定の構文を確認する：YAMLのインデント、コロン、引用符、プロバイダー名、RULE-SETの引数数を見直します。設定を再読み込みしたときにエラーが出ていないことを確認してください。
  2. 取得の成否を確認する：接続ログやコアのログでHTTP応答、タイムアウト、TLSエラー、ファイル保存先のエラーを確認します。ルールがマッチしない問題と、ファイル自体を取得できない問題を分けて調べます。
  3. ファイル内容を確認する：配信URLが正しいブランチとファイルを指しているか、取得した本文がYAMLまたはテキストの想定形式かを確認します。公開リポジトリの閲覧ページのHTMLを誤ってURLに指定していないかも確認してください。
  4. テスト対象を限定する：追加したルールに一致するドメインを一つ選び、クライアントの接続一覧やルール表示で、実際に一致したルールと選択されたポリシーを確認します。ノード変更やDNS設定変更を同時に行わないでください。
  5. 問題時に戻せるようにする：直前の正常なコミットや設定を記録し、新しい版で問題が起きたら、まず直近の変更を戻して再読み込みします。複数のルールを一度に変更すると、原因箇所を特定しにくくなります。

プロバイダーの更新に失敗した場合は、最初にURLをクライアント外から確認し、次にクライアントのログ、pathの保存先、最後にファイル形式を調べると効率的です。HTTP 200が返っていても、返された内容がHTMLのエラーページや空ファイルならルールとしては使えません。逆に、取得成功のログがあっても対象の通信が変わらない場合は、rules内の順序、プロバイダー名の一致、対象ルールの書式、選択されたポリシーを確認します。

変更を追跡しやすくするには、ルールの追加理由をコミットやREADMEに残し、無関係な変更を一つの更新にまとめないことが有効です。最初は小さなルールセットで取得と照合を確認し、安定してから対象を増やしてください。GitHub側の更新、クライアント側の取得、ルール判定を別々に検証すれば、問題が起きてもどの段階で止まっているかを切り分けやすくなります。

Clash Mac版のインストーラー