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

rule-providersを使う理由：ルールを一つのYAMLに詰め込まない

Clashの設定ファイルが大きくなると、接続先を追加するたびにルール全体を編集する必要があり、記述ミスや優先順位の事故が起きやすくなります。特に広告、SNS、動画配信、社内サービス、地域別ドメインなどを一つの rules 配列に集約すると、どのルールが何のために存在するのか分かりにくくなります。

rule-providers は、ルールのまとまりを別ファイルとして管理し、メイン設定から必要なセットだけを読み込む仕組みです。ルールを用途別に分割できるため、GitHubで変更履歴を確認しやすく、複数の端末やプロファイルで同じルールを再利用できます。MihomoやClash系クライアントでは、プロバイダーの定義と RULE-SET の呼び出しを組み合わせて利用します。

例えば、広告ブロック用、国内サービス用、海外サービス用、個人用の例外ルールを別々にしておけば、広告リストだけを更新したり、仕事用のルールだけを検証したりできます。これは単にファイルを分けるだけの整理術ではありません。更新担当、適用対象、失敗時の切り戻し方法を明確にすることで、日常運用の安全性も高められます。

GitHubで管理する前のリポジトリ設計

最初に決めるべきなのは、ルールファイルをどの場所に置き、誰がアクセスできるようにするかです。Clashから取得するファイルは通常、インターネットから直接参照できるURLが必要になります。そのため、公開しても問題のないルールだけを公開リポジトリに置き、個人情報や社内ドメインを含むファイルはプライベートリポジトリやローカル配信に分けてください。

おすすめのディレクトリ例

clash-rules/
├── README.md
├── rules/
│   ├── ads.yaml
│   ├── streaming.yaml
│   ├── social.yaml
│   └── private.yaml
└── sources/
    └── notes.md

公開ルールには、ファイルの目的、対象ドメインの基準、更新日、想定するポリシー名をコメントやREADMEで記録しておくと便利です。ルールの中身だけを見ていると、なぜ特定のドメインを追加したのか後から分からなくなるためです。また、コミットメッセージは「動画サービスを追加」「誤判定ドメインを除外」のように変更理由が分かる文面にすると、障害発生時の確認が速くなります。

GitHubのRaw URLを使う場合は、リポジトリのブランチ名とパスを正確に指定します。ブラウザで表示される通常のページURLではなく、ファイルのRaw表示URLを使用してください。URLにスペースや日本語を含めず、リポジトリを移転する可能性がある場合は、参照先の変更が全端末に影響することも覚えておきましょう。

注意

アクセストークン、購読URL、利用者を識別できる情報はルールファイルに書かないでください。Gitの履歴には削除前の内容が残る場合があるため、誤って公開した秘密情報はファイルを消すだけでなく、直ちに無効化・再発行します。

rule-providersの定義とRULE-SETの呼び出し

rule-providersでは、プロバイダー名、取得元URL、形式、更新間隔、保存先を定義します。以下はGitHub上のYAMLルールを参照する基本例です。実際のキー名や対応形式は、使用しているClashコアまたはMihomoのバージョンに合わせて確認してください。

rule-providers:
  ads:
    type: http
    behavior: domain
    url: https://raw.githubusercontent.com/example/clash-rules/main/rules/ads.yaml
    path: ./ruleset/ads.yaml
    interval: 86400

  streaming:
    type: http
    behavior: classical
    url: https://raw.githubusercontent.com/example/clash-rules/main/rules/streaming.yaml
    path: ./ruleset/streaming.yaml
    interval: 86400

rules:
  - RULE-SET,ads,REJECT
  - RULE-SET,streaming,Proxy
  - MATCH,DIRECT

type: http はHTTP経由でルールセットを取得する指定です。behavior は、ファイルの内容がドメイン形式なのか、クラシック形式なのかを示します。単純なドメイン一覧を使う場合は domain、Clashのルール形式をそのまま書く場合は classical が一般的です。ルールファイルの形式と behavior が一致しないと、取得自体は成功しても読み込み時にエラーになることがあります。

path はダウンロードしたルールをローカルに保存する場所です。クライアントによって相対パスの基準ディレクトリが異なるため、既存設定の保存場所を確認してください。interval は更新間隔を秒で指定します。毎回起動時に取得するのではなく、広告リストのように頻繁な変更があるものでも一日一回程度から始め、サーバー負荷と鮮度のバランスを取るのが安全です。

プロバイダーを定義しただけでは通信に適用されません。rules セクションに RULE-SET を追加して初めて、対象通信が指定ポリシーへ振り分けられます。ルール名の大文字・小文字、カンマ区切り、ポリシーグループ名のスペルを確認してください。

マッチング順序とポリシー設計

Clashのルールは上から順に評価され、最初に一致したルールが採用されます。このため、rule-providersを導入する際に最も重要なのは、ファイルの内容よりも呼び出す順番です。広い範囲を対象にするルールを上へ置くと、下にある例外ルールへ到達しません。

配置の考え方	例	目的
最優先の拒否	`RULE-SET,ads,REJECT`	不要な広告通信を早い段階で停止する
個別の例外	`DOMAIN-SUFFIX,example.com,DIRECT`	特定サービスだけ経路を上書きする
用途別プロバイダー	`RULE-SET,streaming,Proxy`	動画やSNSを専用グループへ送る
最後の受け皿	`MATCH,DIRECT`	どのルールにも一致しない通信を処理する

例えば、ある動画サービスを常にプロキシへ送るルールセットの前に、そのドメインを含む大きな「国内直結」セットを置くと、意図したプロキシグループへ到達しません。反対に、例外をすべて最上部へ並べすぎると、設定の意図が追いにくくなります。基本方針としては、必ず止めたい通信、明示的な例外、用途別プロバイダー、GEOIPやMATCHの順に整理すると、レビューしやすい構成になります。

運用のヒント

ルールを追加したら、いきなり複数のプロバイダーを変更せず、一つのファイルだけを更新して接続ログを確認します。期待するポリシーグループへ入ったかを見れば、ルールの内容と順番のどちらに問題があるかを切り分けやすくなります。

プロバイダー内のルールが重複していても、必ずしも動作エラーになるとは限りません。しかし、大きなファイルを複数回評価すると管理と診断が難しくなります。似た目的のリストを統合し、サービスの例外はメイン設定側に短く残すなど、更新頻度と責任範囲に応じて分割してください。

更新失敗時のログ確認と安全な運用

GitHub管理の便利さは自動更新にありますが、URL変更、ブランチ名の変更、Raw配信の一時障害、レート制限、TLS検証エラーなどで更新に失敗することがあります。更新できなかった場合でも、前回取得したローカルファイルが使われるクライアントはありますが、常にそうとは限りません。エラーを放置せず、現在ロードされているルールの日時と内容を確認してください。

Clashクライアントのログ画面を開き、プロバイダー名で検索する。
404、403、タイムアウト、証明書エラーなど、失敗の種類を記録する。
Raw URLをブラウザやコマンドラインから確認し、YAML本文が返るかを調べる。
GitHubのコミット履歴で、ファイル名、ブランチ、形式を変更していないか確認する。
修正後に手動更新し、プロバイダーの最終更新時刻とルール件数を確認する。

curl -L --fail \
  https://raw.githubusercontent.com/example/clash-rules/main/rules/ads.yaml

レスポンスがHTMLのエラーページになっている場合、URLは正しくありません。取得できても先頭に説明文やMarkdownのコードフェンスが混ざっていると、YAMLルールとして解釈できないことがあります。ルールファイルは必要な形式だけを返すようにし、READMEの内容を同じURLへ置かないでください。

変更を安全に戻せるよう、GitHubでは小さなコミット単位で管理します。大規模なリストを一度に置き換える前にブランチで検証し、問題がなければmainへ反映する運用が理想です。自動生成スクリプトを使う場合も、生成後のファイルサイズ、行数、空ファイル化、重複の増加をチェックすると事故を減らせます。

障害時の切り戻し

新しいルールセットで通信が止まった場合は、最後に正常だったGitコミットへ戻し、Clash側でプロバイダーを手動更新します。空のファイルを公開してしまうと、広告除外や直結判定が突然変わるため、公開前に最低限の行数と構文を確認してください。

設定をGitHubで整理する方法は、GUIだけでルールを編集する運用よりも再現性があります。一方で、他のプロキシアプリではプロバイダーの形式、更新間隔、ルールの優先順位が異なり、同じリストをそのまま流用できないことがあります。Clashはrule-providersとルールログを組み合わせて、用途別管理、履歴確認、手動更新、切り戻しまで一つの構成で扱える点が強みです。複雑なルールを安全に育てながら複数端末で共有したい方は、Clashを無料でダウンロードして、まず小さなルールセットから試してみてください。