移行ガイド 読了目安 7分

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

GitHubやnpm、Docker Hub向けのClash自作ルールを、rule-providersで管理する方法を解説。YAMLの書き方、ルールの優先順位、更新設定、GitHubでの公開・検証手順をサンプル付きで紹介し、Mihomoで起きやすい互換性の問題も取り上げます。

rule-providersでルールを設定本体から分離する

Clashの設定にルールを直接追加し続けると、YAMLが長くなり、変更箇所の確認や別端末への反映が難しくなります。mihomoのrule-providersを使えば、ルールを独立したファイルとして管理し、メイン設定からRULE-SETで呼び出せます。GitHubのリポジトリを保存先にすれば、変更履歴を確認しながら編集でき、クライアント側では設定した間隔でルールファイルを取得できます。

ここで分けて考えたいのは、GitHubがルールを管理する場所であり、通信の照合と振り分けを実行するのはClashカーネルだという点です。プロバイダーのURLを設定しただけでは、ルールは通信に適用されません。rulesに対応するRULE-SETを追加し、その行より後ろにあるルールとの優先順位も確認する必要があります。

ルール形式を選ぶ

behaviorはプロバイダーのファイルに含めるルールの種類を指定します。ドメイン名を中心に管理するならdomain、CIDR形式のIP範囲ならipcidr、複数種類のClashルールをまとめるならclassicalを使います。ファイルの中身とこの値が合っていないと、取得には成功しても読み込みに失敗したり、意図した条件に一致しなかったりします。

GitHubでルールファイルを管理する

リポジトリには、メイン設定、ルールファイル、READMEを分けて置くと見通しがよくなります。たとえば、rules/domain.yamlにドメインルールを保存し、変更理由や適用範囲をREADMEに記録します。リポジトリは公開範囲を慎重に選び、サブスクリプションURL、認証トークン、個人を特定できる情報はコミットしないでください。ルールファイルが公開されてもよい内容か、更新前に確認しましょう。

公開リポジトリでは、Clashから取得するURLにブラウザーのリポジトリ画面ではなく、ファイルの生データを返すURLを指定します。URLの各部分は、所有者名、リポジトリ名、ブランチまたはコミット、ファイルパスに対応します。リポジトリを移動したり、ブランチ名やファイル名を変えたりすると、既存設定のURLも更新が必要です。

rules/
  domain.yaml
  ipcidr.yaml
README.md

domain.yamlをYAML形式で管理する場合は、次のようにpayloadの下にルールを記述します。インデントにはタブではなく半角スペースを使い、ドメインの先頭に付ける記号も含めて、ルール形式に沿って記述してください。

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

リポジトリの更新では、1回の変更を小さくし、コミットメッセージに理由を残すのがおすすめです。たとえば「社内テスト用ドメインを追加」「誤判定を修正」のように書けば、後から差分を見て変更意図をたどれます。ルールを削除するときも、いきなり複数の大きな範囲を消すのではなく、対象と影響を確認してから反映してください。

YAMLにrule-providersとRULE-SETを追加する

次の例では、GitHubに置いたドメインルールを1日ごとに取得し、該当ドメインを拒否するルールとして適用します。URLとパスは説明用の例なので、実際のリポジトリ所有者、ファイルパス、生データURLに置き換えてください。pathは取得したルールセットを保存するローカルパスです。クライアントによって設定ファイルの作業ディレクトリが異なるため、保存先が存在するか、書き込み可能かも確認します。

rule-providers:
  custom-domain:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/<owner>/<repo>/main/rules/domain.yaml"
    path: ./ruleset/custom-domain.yaml
    interval: 86400

rules:
  - RULE-SET,custom-domain,REJECT
  - MATCH,PROXY

interval: 86400は更新間隔を秒数で指定し、ここでは24時間ごとに更新します。短い間隔にすれば変更が早く反映されるとは限りません。ホスティング側の制限やネットワークの状態によって取得に失敗することもあるため、通常のルールなら1日程度から始めると管理しやすいでしょう。大量のルールや頻繁に変わらないリストで、数分単位の更新を常に行う必要はありません。

rulesは上から順に評価されるため、ルールセットより前に広い条件のルールを置くと、そこで照合が終わり、プロバイダーまで到達しない場合があります。たとえば先にMATCH,PROXYを置いてしまうと、その後に書いたルールセットは実質的に使われません。また、REJECTの代わりにプロキシグループ名を指定する場合は、その名前がproxy-groupsに存在することを確認してください。

取得・解析・照合を順番に検証する

設定を反映したら、まずYAML全体の解析エラーがないことを確認します。インデント、コロン、引用符、リストの書式に問題があると、プロバイダーの通信に到達する前に設定の読み込みが失敗します。次にクライアントのログを確認し、URLへの接続、HTTP応答、ルールセットの解析が成功しているかを見ます。エラーが出た場合は、メッセージの時刻と対象プロバイダー名を控え、URLのパス、HTTPステータス、レスポンス内容を順に調べます。

  1. URLを確認する：URLをブラウザーやコマンドラインで開き、認証画面やHTMLエラーページではなく、ルールファイルの内容が返ることを確かめます。
  2. 形式を確認する：behaviorとformatに対し、ファイル内のデータ構造と各ルールの書式が一致しているか確認します。
  3. 更新ログを確認する：カーネルのログで、接続タイムアウト、404、TLSエラー、YAML解析エラーなどを区別します。
  4. 照合結果を確認する：対象ドメインへの接続を発生させ、接続履歴やログで適用されたルールと選択されたポリシーを確認します。

ファイルを編集してもすぐに反映されない場合は、更新間隔の経過を待つだけでなく、クライアントにルールセットの手動更新操作があるか確認してください。更新後も古い結果が残るときは、プロバイダーのキャッシュ、取得先URL、ファイルパスを順番に調べます。取得したファイルのサイズが0に近い場合や、本文がエラー説明だけの場合は、ルール内容ではなく配信側の問題です。

GitHubのブランチURLは、ブランチ上の最新ファイルを参照します。すばやく編集できる一方、ブランチへの変更がそのままクライアントへ届くため、作業中の内容が公開される可能性があります。安定性を重視する場合は、変更を確認してから本番ブランチへ反映し、コミット履歴と差分をレビューする運用にします。特定のコミットを参照する構成は更新内容を固定しやすい反面、新しいルールを取り込むにはURLの更新が必要です。

最初は小さなルールファイルと1つのプロバイダーで動作を確認し、正常に取得・照合できてから対象を増やすと、原因を切り分けやすくなります。自作ルールは、誤ったドメイン指定や広すぎるIP範囲によって必要な通信まで遮断することがあります。追加時には対象と意図を記録し、問題が起きたらGitの差分から直前の変更を特定して戻せる状態にしておきましょう。

FlClash ダウンロード 各プラットフォームのクライアントを見る