はじめに
Clash の設定にルールを追加し続けていると、rules の一覧が長くなり、どの通信をどこへ振り分けているのか把握しにくくなります。複数の端末で同じルールを使いたい場合や、変更前後の差を確認したい場合も、設定ファイルにすべてを直接書く方法では管理に手間がかかります。
そこで役立つのが rule-providers です。ルールの本体を別の YAML ファイルとして分離し、GitHub に置いて Mihomo から読み込めば、プロファイル本体をすっきり保ちながら、変更履歴や更新内容を管理できます。本記事では、GitHub にルールセットを用意する手順、Mihomo の設定例、ルールの評価順、読み込みに失敗したときの確認方法を順番に解説します。
この記事でできること
GitHub 上のルールファイルを rule-providers として読み込み、更新・差分確認・トラブル対応まで行えるようになります。
1rule-providers の仕組みを理解する
通常の rules は、設定ファイルにルールを一行ずつ記述します。一方、rule-providers では、ルールの取得元や保存先、更新間隔をプロファイルに定義し、実際のルール一覧は別のファイルに置きます。プロファイル側には「どのルールセットを使うか」を記し、個々のドメインや IP のリストは GitHub 上のファイルで管理する構成です。
- 管理場所を分けられる： プロファイルの変更と、ルール一覧の変更を別々に扱えます。
- 複数の環境で共有しやすい： 同じ URL を使えば、複数の Mihomo プロファイルでルールを再利用できます。
- 更新履歴を確認できる： GitHub のコミット履歴や差分から、いつ何を追加・削除したか追跡できます。
- 用途ごとに分割できる： 仕事用、国内サービス用、広告ブロック用など、役割ごとにファイルを分けられます。
利用するコアを確認
以下の例は Mihomo を対象にしています。クライアントの表示名が Clash でも、実際に設定を処理するコアが Mihomo かどうかを先に確認してください。コアやバージョンによって利用できる項目が異なる場合があります。
2GitHub にルールファイルを作成する
まず GitHub に専用リポジトリを作成し、ルールを用途別のファイルに整理します。公開リポジトリを使う場合、Mihomo が取得する URL はブラウザーでファイルを表示するページではなく、ファイル本体を返す raw.githubusercontent.com の URL です。リポジトリ名やブランチ名、ファイルのパスは実際の構成に合わせてください。
ドメイン単位で管理する場合は、次のようなファイルを用意します。
この形式を使う場合、後で指定する behavior は domain にします。先頭の +. は対象ドメインのサブドメインを含める表記です。ホスト名を一件だけ指定したいときは、用途に応じて www.example.com のように記述します。誤った形式を混ぜると、取得には成功してもルールとして読み込めないことがあるため、ファイルの形式と behavior を一致させましょう。
GitHub へのコミット前には、YAML のインデント、ファイル名、拡張子を確認してください。ファイルを更新したら、GitHub 上でファイルを開き、内容が意図したコミットに反映されているか確認します。運用の再現性を重視する場合は、後述のとおりブランチの最新状態ではなく、特定のコミットに固定した URL を利用できます。
公開範囲に注意
公開リポジトリのファイルは誰でも閲覧できます。個人情報、非公開の接続先、認証情報、サブスクリプション URL などをルールファイルやコミットに含めないでください。
3Mihomo の YAML に登録する
ルールファイルを用意したら、プロファイルのトップレベルに rule-providers を追加します。以下は公開 GitHub リポジトリのドメイン用ルールを取得し、1日ごとに確認する基本例です。OWNER、REPO、ブランチ、ファイル名は自身のリポジトリに置き換えてください。
type: http は HTTP 経由でファイルを取得する指定、behavior はルールの形式、url は取得元、path は端末内に保存する場所です。interval は更新確認の間隔を秒数で表し、86400 は24時間に相当します。短くしすぎると取得回数が増えるため、頻繁に変わらないリストなら数時間から数日程度の間隔を検討してください。
RULE-SET,my-domains,PROXY は、ルールセットに一致した通信を PROXY という名前のポリシーへ送ります。実際の設定にその名前のプロキシグループがなければ、既存のグループ名に置き換えます。ルールセットの指定だけでは通信先は決まらないため、ポリシー名の一致も必ず確認してください。
IP アドレスや従来形式のルールを使う場合
IP CIDR の一覧を読み込む場合は behavior: ipcidr とし、ファイルには用途に合った CIDR を記述します。複数種類のルールを一つのファイルにまとめたいときは behavior: classical が選択肢になります。その場合はルール行の形式も classical 用にそろえます。domain 用のリストをそのまま classical として扱うなど、形式を混在させないことが重要です。
設定を保存したら、クライアントのプロファイルを再読み込みするか、対応する更新操作を実行します。Mihomo のログでプロバイダー取得の成否を確認し、さらに接続テストで対象のドメインが想定したポリシーに振り分けられるか確かめてください。YAML の記述を直しただけでは、実行中のコアに変更が反映されていない場合があります。
4優先順位と Git による更新を管理する
Clash の通常の rules は上から順に評価され、最初に一致したルールが適用されます。そのため、rule-provider を登録しただけで通信が振り分けられるわけではありません。RULE-SET の行を適切な位置に追加し、広い条件のルールや MATCH より前に評価させます。たとえば対象ドメインを DIRECT にする個別ルールが先にあると、後ろに置いたプロキシ用ルールセットには到達しません。
- 例外を先に置く： 特定のホストだけ別のポリシーにしたい場合は、該当する個別ルールをルールセットより前に記述します。
- 用途別に分ける： 仕事用と個人用など、変更担当や更新頻度が異なるリストは別ファイルにします。
- 最後に MATCH を置く： すべての条件に一致しなかった通信の処理は、通常、ルール一覧の末尾で定義します。
- 変更を小さく保つ： 一度に大量の項目を変更せず、コミット単位で目的が分かるように記録します。
Git で管理する場合は、ルールを編集するたびに差分を確認し、意図しない削除や重複がないことを見てからコミットします。複数人で編集するなら、変更の理由をコミットメッセージに残し、レビュー後に既定ブランチへ反映する流れが扱いやすいでしょう。端末側ではブランチの URL を使うことで更新を追従できますが、ブランチが更新されれば取得内容も変わります。
予期しない変更を避けたい場合は、URL のブランチ名の代わりにコミット ID を指定し、その時点のファイルに固定します。内容を確認してから新しいコミットへ切り替えられる一方、自動で最新ルールに追従しなくなる点には注意が必要です。安定性を優先する環境では固定し、定期的に差分を確認して更新する方法が有効です。
運用のポイント
GitHub 上のファイルを更新しても、端末での反映には provider の更新確認やプロファイルの再読み込みが必要な場合があります。変更後は URL、更新状態、実際のルール判定をセットで確認しましょう。
5読み込みや振り分けの問題を解決する
ルールが反映されないときは、まず設定を一度に大きく変更せず、取得・解析・評価の順に切り分けます。GitHub にファイルが存在していても、Mihomo からその URL にアクセスできるとは限りません。次の項目を一つずつ確認してください。
- URL が 404 になる： リポジトリ名、ブランチ、ディレクトリ、ファイル名の大文字・小文字を確認します。GitHub の通常のファイルページではなく、raw URL を指定しているかも確認してください。
- 取得時にエラーが出る： 端末のネットワークから GitHub に接続できるか、URL が公開アクセス可能かを確認します。プライベートリポジトリは認証情報なしで取得できないことがあるため、公開 URL に秘密情報を追加して解決しようとしないでください。
- YAML エラーになる： インデントがスペースで統一されているか、
payloadの位置が正しいか、リスト項目の書式がbehaviorと一致するかを見直します。 - ファイルは取得できるが一致しない： ドメインの表記、サブドメインの範囲、対象通信のドメイン、ルールセットを置いた位置を確認します。
- 変更が古いままに見える： provider の更新間隔、最後の更新時刻、ローカル保存先の内容を確認し、必要に応じてクライアントから手動更新します。
- 別のポリシーへ流れる： 先行するルールに一致していないか、指定したポリシー名が設定内に存在するか、末尾の
MATCHより前にルールセットがあるかを確認します。
変更後の確認には、Mihomo のログだけでなく、クライアントの接続一覧やルール判定表示も利用します。対象ドメインが表示されているのに期待したポリシーにならない場合は、provider の取得問題ではなく、ルールの順序やポリシー名の誤りである可能性が高くなります。逆に provider 自体が読み込まれていない場合は、まず URL、ファイル形式、更新ログに絞って調べると原因を見つけやすくなります。
よくある質問
GitHub のリポジトリは公開にする必要がありますか？
Mihomo から認証なしで取得する構成なら、URL からアクセスできる公開ファイルが必要です。非公開リポジトリを利用する場合は、クライアントやコアが対応する安全な認証方法を確認してください。アクセストークンを URL や共有設定に直接書く方法は、漏えいにつながるため避けましょう。
interval を短くすると、すぐに設定が反映されますか？
短い間隔は更新確認の頻度を上げますが、設定を書き換えた瞬間に必ず反映されることを意味しません。コアの実装やクライアントの更新操作、ネットワーク状況によって反映タイミングは変わります。急いで確認する場合は、クライアントから provider を手動更新し、ログとルール判定を確認してください。
プロファイル更新と provider 更新は同じですか？
同じではありません。プロファイル更新は設定ファイル全体の更新を指すことがあり、rule-provider の更新は外部ルールファイルの再取得を指します。使用しているクライアントの画面で、それぞれの更新操作や状態表示を確認してください。
複数の rule-providers を同時に使えますか？
用途ごとに名前を変えて複数登録できます。それぞれについて URL、保存先、形式、更新間隔を定義し、rules に対応する RULE-SET を追加します。同じ条件を複数のセットに重複して記載すると、先に一致したルールが適用されるため、役割と優先順位を整理してから分割してください。
GitHub と rule-providers を組み合わせると、ルールの保守を設定本体から切り離し、変更理由や差分を追いやすくできます。まずは小さな公開ルールセットを一つ作り、URL の取得、形式の読み込み、ルールの判定まで確認してから、用途別のリストへ広げていきましょう。