rule-providersの役割：本体設定とルールデータを分ける

rule-providersは、ルールをメインの設定ファイルから分離し、外部ファイルとして取得・管理するための仕組みです。ドメインやIPアドレスの一覧を別ファイルにまとめると、ルール本体を何度も編集せずに対象を更新できます。たとえば、業務用ドメインを直結する一覧、広告ドメインを拒否する一覧、特定サービスをプロキシへ送る一覧を、それぞれ独立して保守できます。

プロバイダーを設定しても、それだけで通信先が切り替わるわけではありません。プロバイダー定義は「ルールデータをどこから、どの形式で取得するか」を示し、rules内のRULE-SETが「そのデータをいつ、どのポリシーに適用するか」を指定します。読み込み定義と利用ルールの両方が正しく設定され、さらに現在のコアが該当形式に対応している必要があります。

  • 通常のルール：メイン設定のrulesに条件とポリシーを直接記述します。少数の例外や変更頻度が低い設定に向いています。
  • ルールプロバイダー：条件の一覧を別ファイルとして読み込みます。数が多い場合や、メイン設定と独立して更新したい場合に管理しやすくなります。
  • プロキシグループ：ノードやポリシーの選択先です。ルールプロバイダーは接続先ノードを作成せず、マッチ条件だけを提供します。

用途に合わせてbehaviorとファイル形式を選ぶ

最初に決めるのは、ファイルにどの種類の条件を入れるかです。ドメイン名を並べるだけならdomain、CIDR形式のIPネットワークならipcidr、複数のルールタイプを混在させるならclassicalを使います。behaviorとファイル本文の構造が一致しないと、HTTPでファイルを取得できていてもプロバイダーの解析に失敗する場合があります。

behavior 主な内容 YAML形式の例
domain ドメインのサフィックス、完全一致、キーワードなどのドメイン条件 payload配下の文字列リスト
ipcidr IPv4またはIPv6のCIDRネットワーク payload配下のCIDRリスト
classical ドメイン、IPなどを含むルール行 ルールタイプ、値、オプションを含む文字列リスト

YAML形式を利用する場合、通常はルールをpayloadというキーの下に置きます。テキスト形式を使う場合は、コアが対応する形式と区切り方を確認してください。MRSなどのバイナリー形式は、テキストのYAMLと同じ方法で手作業編集するものではありません。対応状況はコアのバージョンによって異なるため、見本の設定をそのままコピーするのではなく、利用中のリリース仕様と照合するのが安全です。

domain型のファイルを作る

以下はドメインを直結対象として管理する例です。ここではexample.comを説明用のドメインとして使っています。実際には、管理するサービスのドメインに置き換えます。ファイルの先頭に不要な説明文を入れず、YAMLとして読み取れる構造だけを保存してください。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,portal.example.net
  - DOMAIN-KEYWORD,internal-tool

DOMAIN-SUFFIXは指定した親ドメインとそのサブドメインを対象にします。DOMAINはホスト名の完全一致、DOMAIN-KEYWORDはドメイン名に含まれる文字列を対象にするため、意図しない範囲まで一致しないか注意が必要です。特にキーワード条件は、短い文字列や一般的な単語を指定すると、無関係なサイトにも適用されることがあります。条件は必要最小限にし、実際の接続記録で一致範囲を確かめてください。

classical型のファイルを作る

ドメインとIPの条件を同じプロバイダーにまとめたい場合は、classical型を検討できます。ルール行にはルールタイプと値を記述します。ポリシー名はプロバイダー側ではなく、メイン設定のRULE-SETに指定します。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,portal.example.net
  - IP-CIDR,192.0.2.0/24,no-resolve

この例のIP範囲はドキュメント用のアドレスです。実運用では対象ネットワークに置き換えてください。no-resolveのようなオプションが受け入れられるか、またどのルールタイプで使えるかはコアの仕様を確認します。IP条件に名前解決を伴う判定が必要かどうかも含め、データの意味を理解してから登録してください。

メイン設定でプロバイダーを読み込む

プロバイダー定義はメイン設定のrule-providersに追加します。下記は構造を示す例で、URLは実際に公開したファイルのURLへ変更してください。pathは取得したデータをローカルに保存する場所、intervalは再取得の間隔を秒数で指定する項目です。保存先のディレクトリがクライアントの実行環境から書き込み可能かも確認します。

rule-providers:
  custom-direct:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/custom-direct.yaml
    url: https://rules.example.net/custom-direct.yaml
    interval: 86400

rules:
  - RULE-SET,custom-direct,DIRECT
  - MATCH,Proxy
  • custom-directは任意のプロバイダー名です。定義名とRULE-SETで参照する名前を一字ずつ一致させます。
  • type: httpはHTTP経由でデータを取得する設定です。リモート配信では、URLがクライアントからアクセス可能であることが必要です。
  • behavior: domainとformat: yamlは、先ほどのpayload形式に対応させています。ファイルの中身と設定が異なる場合は修正してください。
  • pathはローカルの保存先です。相対パスの基準はクライアントやコアの起動方法に左右されることがあるため、読み込みログで実際の場所を確認します。
  • interval: 86400は24時間を秒数で表した例です。頻繁に変更されるリスト以外は、配信元や利用頻度に見合う間隔を設定してください。
  • Proxyは説明用のポリシー名です。実際の設定内に存在するプロキシグループ名へ置き換えます。

ルールは上から順に評価されるため、特定ドメインを直結する例外を、より広いプロバイダーのルールや最終フォールバックより前に置く必要があります。MATCHのような全接続を受ける条件を先に書くと、その後ろのルールは通常の評価で到達できません。複数のプロバイダーを使う場合も、どの条件が先に一致するかを一覧にしてから並べると、意図しない上書きを防ぎやすくなります。

GitHubで公開し、rawファイルを配信する

プロバイダーファイルを複数端末で使う場合は、公開リポジトリでバージョン管理すると変更履歴を追いやすくなります。リポジトリには、たとえばrules/custom-direct.yamlのように目的が分かるファイル名で保存します。編集履歴が残れば、誤ったドメインを追加した時点を見つけて差分を戻せます。更新担当者が複数いる場合は、変更前後の理由もコミットメッセージに記録してください。

  1. 新しいリポジトリを作成し、ルールファイルを専用ディレクトリに追加します。メイン設定、ノード情報、サブスクリプションURLなどの秘密情報を同じリポジトリに入れないでください。
  2. リポジトリ上でファイルを開き、公開対象のブランチとファイルのパスを確認します。Clashに渡すのは閲覧用HTMLページのURLではなく、ファイル本文を返すraw形式のURLです。
  3. raw URLをブラウザーで開き、YAMLの本文だけが返ることを確認します。ログイン画面、HTMLのエラーページ、リポジトリの説明ページが返るURLはプロバイダーには使えません。
  4. メイン設定のurlへraw URLを設定し、クライアントで設定を再読み込みします。初回は自動更新を待つのではなく、明示的にプロバイダーを更新して結果を確認します。

公開リポジトリに置いたルールファイルは、誰でも閲覧できる前提で管理してください。対象リストそのものから利用者の環境や社内のホスト名が推測できるなら、公開せずにアクセス制御された配信先を選びます。認証トークンをURLに含める方式は、設定の共有やログ出力で漏れるおそれがあります。公開URLに秘密情報を含めないことが基本です。

GitHub上でファイルを更新した直後に、すべての端末へ即時反映されるとは限りません。クライアント側に保存されたプロバイダーデータ、更新間隔、配信側のキャッシュが影響します。作業後は、raw URLの内容が新しい状態になったか、Clash側で更新が成功したかを別々に確認してください。急いで変更を検証するときは、手動更新後に新しい接続を作成し、接続記録に新しいルールが適用されたかを確かめます。

YAMLとプロバイダーの検証手順

YAMLの検証では、ファイル単体の構文、プロバイダー定義との整合性、コアによる実際の読み込みを分けて確認します。インデントが正しくても、behaviorとルールの種類が合わない、URLがHTMLを返す、参照名が食い違うといった問題は残ります。ひとつの段階で成功したことを、全体が正常に動いている証拠と考えないようにしましょう。

1. インデントとデータ構造を確認する

YAMLではインデントにスペースを使い、同じ階層のキーをそろえます。タブを混ぜないでください。ルールの各項目はリストを示すハイフンから始め、payloadの下に同じ深さで並べます。エディターで色分けされても、YAMLとして正しく解釈される保証にはなりません。保存後に簡単な構文検証を行い、エラーの行番号が表示されたら、その行の直前にあるインデントや引用符も合わせて確認します。

2. URLと取得結果を確認する

配信URLを直接開いたときに返る内容を確認します。HTTPステータスが成功でも、本文がHTMLならルールファイルとしては使えません。公開リポジトリの閲覧ページを指定していないか、ファイル名やブランチを変更した後にURLを更新し忘れていないかも見直してください。公開設定を切り替えた直後は、別のブラウザーやネットワークから同じURLにアクセスして、ログインなしで本文を取得できるか確かめると切り分けに役立ちます。

3. コアのログと接続履歴を確認する

クライアントで設定を読み込んだ後、ログにプロバイダーの取得失敗、YAML解析エラー、ファイル書き込みエラーが出ていないか確認します。プロバイダーの一覧画面がある場合は、更新状態、最終更新時刻、読み込んだ件数も確認してください。件数がゼロなら、空ファイル、誤った形式、想定外の本文を取得していないかを調べます。件数が表示されても、ルール順やポリシー名が正しいとは限らないため、接続履歴でも対象通信を追跡します。

  • プロバイダー名が見つからない：定義側とRULE-SET側の名前、ハイフンや大文字小文字を照合します。
  • ファイル取得に失敗する：URL、ネットワーク接続、公開範囲、HTTP応答、リダイレクトの有無を確認します。
  • 解析に失敗する：behavior、format、payloadの構造、CIDR表記、YAMLのインデントを見直します。
  • 更新できるがルールが効かない：ルール順、ポリシー名、接続がコアに取り込まれているか、既存接続の再利用を確認します。
  • 再起動後にデータが消える：pathの保存先が一時領域ではないか、クライアントに書き込み権限があるか確認します。

ルール変更のテストでは、一度に複数の条件を変更しないことが重要です。まず新しいプロバイダーを単独で追加し、対象ドメインが期待するポリシーに一致するか確認します。意図しない通信まで一致した場合は、追加した行をひとつずつ外して範囲を調べます。テスト中は元の設定をバックアップし、失敗したときにすぐ戻せる状態にしておきましょう。

継続運用のための更新方針と安全策

ルールプロバイダーは、ファイルを置けば終わりではありません。対象サービスのドメイン変更、不要になった例外、誤記、重複ルールを定期的に見直す必要があります。追加するたびに、対象ドメイン、ルールタイプ、適用ポリシー、確認した日付を記録すると、後から判断の根拠を追えます。長いリストをひとつにまとめるより、変更担当や用途が異なるものを別々のプロバイダーに分けるほうが、原因調査とロールバックがしやすくなります。

  • 更新間隔を実態に合わせる：毎日変わるリストでなければ、短すぎる間隔にする必要はありません。配信先へのアクセス数やクライアントの更新負荷も考慮します。
  • 変更前後を記録する：何を追加・削除したか、どの通信を確認したかを履歴に残します。問題発生時に差分を特定しやすくなります。
  • 小さく反映する：大規模なリストを一度に更新する前に、検証用のプロバイダーや少数の条件で動作を確認します。
  • 古い条件を整理する：不要になったルールを残し続けると、例外が増えて評価結果を予測しにくくなります。定期的に実際の接続と照合してください。
  • 公開内容を再確認する：ルール一覧、ファイル履歴、コミットメッセージに個人情報、社内情報、認証情報を含めないようにします。

プロバイダーの更新と設定全体の更新も区別してください。クライアントによって、サブスクリプション更新時に設定を再生成するものや、ローカルの変更を保持するものがあります。メイン設定を直接編集すると、更新時にrule-providersの定義が消える可能性があります。オーバーライドやマージ機能を使う場合は、適用後の設定を確認し、プロバイダー定義、利用ルール、ポリシーの三つがそろっていることを確かめましょう。

まずは少数のドメインを含む小さなYAMLファイルを作り、公開URLで本文が取得できること、コアがプロバイダーを読み込めること、対象通信が意図したポリシーに一致することを順に試してください。正常な流れを確認してから一覧を増やせば、構文、配信、ルーティングのどこに問題があるかを判断しやすくなります。初回設定の手順はインストールと設定ガイド、クライアントごとの機能差はクライアント比較も参考にしてください。