はじめに
Clash のルールが増えると、設定ファイルにすべての項目を直接書き込む方法では、見通しが悪くなり、更新や修正にも手間がかかります。そこで役立つのが、ルールを別ファイルに分割して管理する rule-providers です。ルール一覧を GitHub のリポジトリに置けば、メインの YAML 設定を頻繁に編集せずに、分割ルールを個別に保守できます。
この記事では、Mihomo を含む Clash 系コアで使われる rule-providers の基本構造、GitHub 上のルールファイルの作り方、RULE-SET の指定方法を順に解説します。最後に、ルールの評価順や、取得できないときに確認すべき点も取り上げます。なお、クライアントの画面や対応項目はコアの種類・バージョンによって異なるため、実際の設定前に利用中のコアの仕様も確認してください。
この記事でできること
GitHub でルールファイルを管理し、rule-providers と RULE-SET をつないで、更新しやすい構成を作れるようになります。
1rule-providers の基本を理解する
rule-providers は、外部に置いたルールファイルを Clash が取得し、名前を付けて参照できるようにする設定です。ルール本体と振り分け先を分けて管理できるため、同じルールセットを複数の設定で再利用したり、ルールだけを差し替えたりしやすくなります。ただし、プロバイダーを定義しただけでは通信の振り分けは行われません。rules 側に、そのプロバイダーを使う RULE-SET を追加する必要があります。
主な設定項目は次のとおりです。
- type：取得方法を指定します。一般的なリモート配布では
httpを使います。 - behavior：ルールの種類を指定します。ドメイン中心なら
domain、IP アドレス範囲ならipcidr、複数種類のルールを含めるならclassicalが基本です。 - url：ルールファイルの取得先です。GitHub のリポジトリ画面の URL ではなく、ファイル本文を返す URL を指定します。
- path：取得したファイルの保存先です。通常は設定ファイルからの相対パスで、コアが書き込める場所を指定します。
- interval：更新を確認する間隔を秒数で指定します。たとえば
86400は24時間です。 - format：ルールファイルの形式です。YAML 形式では
yaml、対応コアが扱うプレーンテキスト形式ではtextを指定します。
設定前の確認
behavior とファイルの中身が一致しないと、取得に成功してもルールを正しく読み込めません。ドメイン一覧を使うのか、通常の Clash ルール式を使うのかを先に決めてください。
2GitHub に YAML ルールを用意する
GitHub では、ルール用のリポジトリを作り、用途ごとにファイルを分けると管理しやすくなります。たとえば rules/streaming.yaml や rules/work.yaml のように、対象サービスや目的が分かる名前を付けます。変更履歴が残るため、誤ったルールを追加した場合も差分を確認して戻しやすいのが利点です。
GitHub のファイル画面に表示される github.com の URL は、HTML の閲覧ページです。Clash に指定する URL には、通常 raw.githubusercontent.com から始まるファイル本文の URL を使います。公開リポジトリであれば、ブランチ名とファイルパスを含む形にします。
以下は behavior: domain と組み合わせる例です。payload の下にはドメイン項目を並べます。
+.example.com のようなドメイン表記は、使用するコアのルール形式に従って記述してください。ファイルを保存したら、GitHub 上で YAML のインデントや引用符が崩れていないか確認します。編集した内容が反映されているか、Raw 表示から本文を開いて確かめると、URL の指定ミスも見つけやすくなります。
公開範囲と機密情報に注意
公開リポジトリのファイルは第三者からも閲覧できます。個人情報、認証情報、非公開にすべき接続先を含めないでください。非公開リポジトリは認証や取得方法が追加で必要になる場合があるため、利用するコアが対応しているか事前に確認しましょう。
3rule-providers と RULE-SET を接続する
GitHub にファイルを置いたら、メインの YAML にプロバイダー定義を追加し、続けて rules から名前を参照します。次の例では、公開リポジトリの main ブランチに置いたドメイン型ファイルを、24時間ごとに更新する構成を示します。URL と保存先は自分のリポジトリに合わせて置き換えてください。
streaming は任意のプロバイダー名です。RULE-SET,streaming,Proxy の2番目の値を、定義した名前と同じにします。最後の Proxy は振り分け先のポリシーグループ名なので、自分の設定に存在するグループ名へ変更してください。名前の大文字・小文字や記号も含め、定義と参照を一致させることが大切です。
classical 型を使う場合
ドメインだけでなく、DOMAIN-SUFFIX や GEOIP など、複数のルールタイプをまとめたい場合は behavior: classical を検討します。その場合は、ファイルの形式と内容も classical ルールとして整えます。たとえば YAML 形式で配布する場合、利用するコアの仕様に合った payload 構造にし、項目を通常のルール式で記述します。
このファイルに対応させるプロバイダーでは behavior: classical を指定します。コアによって利用できる形式や細部に差があるため、エラーが出た場合はファイルの構文だけでなく、コアのバージョンと対応仕様も照合してください。
4ルール順序と更新を管理する
Clash のルールは上から順番に評価され、最初に一致した項目のポリシーが適用されます。そのため、具体的なルールセットを広い条件より前に置くのが基本です。たとえば特定サービスをプロキシに送りたい場合、そのルールセットを MATCH,DIRECT より前に記述します。末尾にある MATCH は、ほかのルールに一致しなかった通信を処理するため、通常は最後に配置します。
- 広いルールを先に置かない：先行する包括的な条件で通信が一致すると、後ろの
RULE-SETまで評価されません。 - ルールの重複を点検する：複数のセットに同じドメインがあると、上にあるセットのポリシーが優先されます。
- 更新間隔を目的に合わせる：頻繁に変わらないルールは長めに設定し、更新のたびに不要な通信が発生しないようにします。
- 変更履歴を確認する：GitHub の差分を確認し、意図しない一括削除や誤記がないかレビューしてから反映します。
ルールファイルを GitHub で更新しても、すべての端末へ即時反映されるとは限りません。コアの取得間隔、ネットワーク状況、ローカルに保存されたキャッシュなどによって反映時刻が変わります。急いで確認する場合はクライアント側でプロバイダー更新を実行し、ログやプロバイダー画面で最終更新時刻を確認してください。何度も短い間隔で再読み込みするより、まず URL の内容が新しくなっているかを確認する方が効率的です。
5取得エラーを切り分ける
プロバイダーが読み込めない場合は、YAML 全体を一度に書き換えるのではなく、取得、形式、参照、通信の順に分けて確認します。特に GitHub のページ URL と Raw URL の取り違え、ファイルパスの大文字・小文字、ブランチ名の間違いはよくある原因です。
- URL をブラウザーで確認：指定 URL を開き、ログイン画面や HTML ページではなく、ルールファイルの本文が返るかを確かめます。404 ならブランチ名、ディレクトリ、ファイル名を見直します。
- HTTP エラーを確認：タイムアウトや接続拒否は、ネットワークから GitHub に接続できない、または取得先へ到達できない可能性があります。現在のプロキシ設定や DNS も確認します。
- YAML の構文を確認：タブではなくスペースでインデントし、
payloadの階層とリスト記号の位置をそろえます。URL に特殊文字が含まれる場合は引用符で囲みます。 - behavior とルール形式を照合：ドメイン一覧なのに
classicalを指定するなど、型が一致していないと読み込みに失敗したり、期待する判定にならなかったりします。 - RULE-SET の名前を照合：定義したプロバイダー名と
RULE-SETの名前が一致しているか、さらにポリシーグループが存在するかを確認します。
安全に変更する手順
まず小さなルールセットを作って動作を確認し、問題がなければ対象を広げます。変更前の設定をバックアップし、ログでプロバイダーの読み込み結果と実際に選ばれたルールを照らし合わせると、原因を絞り込みやすくなります。
rule-providers を使うと、設定ファイルを「ルールの取得元」「適用するポリシー」「評価順」に分けて考えられます。GitHub 側ではルールの変更を小さく保ち、Clash 側では参照名と順序を明確にすることが、長期的に管理しやすい構成につながります。コアの仕様に合わせて形式を選び、更新後はログと実際の通信結果の両方を確認しましょう。