Clashのrule-providersをGitHubで管理する実践設定ガイド

rule-providersとは何か

Clashの設定ファイルが大きくなると、rules の配列にすべてのドメインやIPルールを書き続ける構成は、次第に管理しにくくなります。動画サービス、広告、仕事用サービス、プライベートネットワークなどのルールが一つのYAMLに混在すると、設定を確認するたびに長いファイルを探す必要があり、複数のプロファイルへ同じルールを反映する作業も面倒です。

rule-providers は、ルールセットを別ファイルとして定義し、Clashの設定から必要なときに読み込む仕組みです。ルール本体をGitHubなどのURLへ分離できるため、メイン設定を簡潔に保ちながら、複数のプロファイルで同じルールを再利用できます。Clash Verge Rev、Mihomo系クライアント、Clash for Androidなど、対応するコアを搭載したクライアントで利用できます。

ただし、rule-providersはノードやプロキシグループを提供する機能ではありません。あくまで「どのドメインやIPをどのポリシーへ送るか」をまとめたルールファイルです。設定を分割する前に、使用中のクライアントがMihomoまたは対応するClashコアであること、そしてプロファイルの構文がそのコアの形式に合っていることを確認してください。

GitHubにルールファイルを用意する

最初にGitHubで専用リポジトリを作成します。リポジトリ名は、例えば clash-rules や proxy-rule-providers のように、用途が分かる短い名前にすると後から見つけやすくなります。公開設定にする場合は、ルールファイルの中に購読URL、アクセストークン、社内ホスト名、個人のIPアドレスなどを含めないでください。GitHubの公開ファイルは、URLを知っている人だけでなく検索エンジンやクローラーからも取得できる可能性があります。

GitHubで新しいリポジトリを作成し、READMEとライセンスの有無を決める。
rules や providers などのディレクトリを作り、用途別にYAMLファイルを保存する。
ファイルの内容をClashのルールプロバイダー形式で記述する。
コミット後、ブラウザでファイルを開き、Raw のURLをコピーする。
Clash側のrule-providersへURLを登録し、更新と読み込みを確認する。

ルールファイルは、通常のClashルールプロバイダーで使われる次のような形式にします。ファイル名の拡張子は必ずしも重要ではありませんが、内容の形式とプロバイダーのformat指定を一致させることが大切です。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN-SUFFIX,example.net
  - DOMAIN-KEYWORD,stream
  - IP-CIDR,203.0.113.0/24,no-resolve

GitHubの通常表示ページではなく、Raw URLを使う点に注意してください。通常ページはHTMLとして返されるため、ClashがYAMLとして解釈できません。Raw URLはリポジトリのブランチ名やファイルパスを含み、一般的には次のような形になります。

https://raw.githubusercontent.com/USER/REPOSITORY/main/rules/media.yaml

Clash設定へrule-providersを追加する

次に、メインの設定ファイルへプロバイダー定義を追加します。ここで使うキー名は、後でRULE-SETから参照する名前と完全に一致していなければなりません。behavior は、ルールファイルの内容がドメイン中心なのか、IP中心なのか、クラシック形式なのかを示します。ファイルの形式と合わない値を指定すると、更新は成功してもルールが期待どおりに評価されないことがあります。

rule-providers:
  media:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/USER/REPOSITORY/main/rules/media.yaml
    path: ./rule-providers/media.yaml
    interval: 86400

  private:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/USER/REPOSITORY/main/rules/private.yaml
    path: ./rule-providers/private.yaml
    interval: 86400

type: http はHTTPまたはHTTPSのURLから取得する設定です。path はダウンロード後にクライアントが保存するローカルパス、interval は自動更新の間隔を秒数で指定します。1日ごとに更新するなら86400、6時間ごとなら21600です。頻繁に変更しない個人ルールでは、短すぎる間隔を設定する必要はありません。GitHubへ大量のリクエストを送らないためにも、更新頻度は実際の変更ペースに合わせてください。

プロバイダーを定義しただけでは通信経路は変わりません。rules の中でRULE-SETとして呼び出し、適用するポリシーを指定します。

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,media,Proxy
  - MATCH,Final

ルールは上から順番に評価されます。特定のドメインを直接接続したい場合は、広いルールより前に置きます。最後のMATCHは、どのルールにも一致しなかった通信を受けるための保険です。これを省略すると、コアや設定によっては想定外の処理になるため、明示的に記述しておくと切り分けが容易になります。

形式、優先順位、複数プロファイルの考え方

rule-providersを安定して使うには、ルールの形式と適用順序を分けて考える必要があります。ドメインだけを並べた簡易リスト、DOMAIN-SUFFIXなどのタイプ付きルール、IP-CIDRを含むクラシック形式では、必要なbehaviorが異なります。Mihomoで利用できる機能が、すべての古いClashコアで利用できるとは限らないため、複数端末で同じ設定を使う場合は最も古いクライアントを基準に検証してください。

項目	確認する内容	よくある問題
URL	Raw URLであり、ブラウザから取得できるか	GitHubのHTMLページを登録している
behavior	ルールファイルの形式と一致しているか	domain形式とclassical形式を取り違える
名前	定義名とRULE-SETの参照名が同じか	タイポや大文字小文字の不一致
順序	例外ルールが広いルールより前にあるか	先にMATCHして後続ルールへ到達しない

複数のプロファイルで同じプロバイダーを使う場合は、URLと参照名を共通化し、プロキシグループだけをプロファイルごとに変更する方法が便利です。例えば仕事用プロファイルではWorkProxy、個人用ではProxyを指定しても、GitHub上のルールファイルは一つで済みます。これにより、ルールの修正と出口ノードの選択を別々に管理できます。

ヒント

個人用、仕事用、テスト用のルールを最初から一つにまとめるのではなく、用途ごとに小さく分けてください。問題が起きたときに、どのプロバイダーが通信を拾ったのかをログで確認しやすくなります。

更新後の検証と安全な運用

GitHubのファイルを更新したら、まずブラウザのRaw URLで新しい内容が表示されるか確認します。GitHub側の反映には少し時間がかかる場合があり、CDNやクライアントのキャッシュが残ることもあります。Clashの画面でプロバイダーを手動更新し、更新日時、取得状態、ルール件数を確認してください。

ルールが取得できても、正しくマッチするとは限りません。Clashの接続ログで対象ドメインへの通信を開き、実際にどのRULE-SETへ一致し、どのポリシーグループへ送られたかを確認します。期待と違う場合は、次の順序で調べると効率的です。

Raw URLへアクセスして、ファイルが空ではないことを確認する。
YAMLのインデント、キー名、カンマ、CIDR表記を確認する。
behaviorとルールの記述形式が一致しているか調べる。
同じドメインに一致する別のルールが、先に書かれていないか確認する。
クライアントを再起動する前に、プロバイダー単体の更新を試す。

注意

GitHub上のファイルを編集した直後に、いきなり全端末へ反映するのは避けてください。ルールの誤記で重要なサービスがREJECTになったり、社内システムがプロキシへ送られたりする可能性があります。変更前にコミットを作成し、問題があれば直前のコミットへ戻せるようにしておくと安全です。

運用では、コミットメッセージに変更理由を残し、ルールの追加と削除を小さな単位で行うのがおすすめです。外部から取得した巨大なルールセットを無条件に混ぜると、メモリ使用量や更新時間が増え、ルールの優先順位も把握しにくくなります。必要なドメインだけを自分のプロバイダーへ整理し、定期的に不要な項目を削除すると、設定の読みやすさと動作の安定性を両立できます。

GUIによってはプロバイダーの状態表示が簡略化され、更新失敗の理由が分かりにくいことがあります。接続できない場合は、クライアントのログだけでなく、Raw URLをブラウザやコマンドラインから取得できるかも確認してください。URLの期限切れ、GitHubへの接続制限、TLSエラー、ローカルパスの権限問題を分けて調べることで、設定そのものの問題か通信環境の問題かを判断できます。

従来のGUIだけでルールを直接編集する方法は、手軽な反面、長い設定の検索や複数プロファイルへの同期が難しく、バックアップも不十分になりがちです。GitHubで管理するrule-providersなら、変更履歴、差分確認、ロールバック、複数プロファイルでの再利用をまとめて扱えます。設定ファイルを整理しながら、更新状況を自分で追跡できるClashの運用を始めたい方は、Clashを無料でダウンロードして試してみてください。