rule-providersの仕組み
rule-providers は、ドメインや IP アドレスなどのルールを設定本体から分離し、外部ファイルとして読み込む Mihomo の機能です。ルールを追加・修正するたびに大きな設定ファイル全体を書き換える必要がなく、複数のプロファイルで同じルールセットを再利用したい場合にも便利です。たとえば、広告用、社内サービス用、特定アプリ用など、用途ごとにファイルを分けて管理できます。
ここで押さえておきたいのは、rule-provider が保持するのは「どの通信を対象にするか」を示すルールの一覧であり、プロキシサーバーやプロキシグループそのものではないという点です。プロバイダーを読み込んだ後、rules に RULE-SET を記述し、最後の引数で転送先のグループや DIRECT、REJECT を指定します。
設定の全体像
ルールファイルを用意し、rule-providers で登録してから、rules で適用先を指定します。登録しただけでは通信の振り分けは始まりません。
Mihomo はプロバイダーの種類や behavior に応じてルールを解釈します。一般的なドメイン一覧には domain、IP アドレスや CIDR の一覧には ipcidr、DOMAIN-SUFFIX などのルール形式をまとめて使う場合は classical を選びます。配布元のファイル形式と behavior が合っていないと、読み込み時のエラーや意図しない判定につながるため、最初に確認してください。
1YAMLでプロバイダーを設定する
次の例では、公開 URL からドメインルールを取得し、プロキシグループ Proxy に振り分けます。URL とグループ名は自分の環境に合わせて変更してください。URL はブラウザーで開いたときに HTML の説明ページではなく、ルールファイルの内容が直接返るリンクを指定します。
type: http は HTTP 経由で取得する設定です。path は取得したファイルの保存先で、通常は Mihomo の設定ファイルを基準にした相対パスを指定できます。フォルダーがまだない場合は作成し、実行ユーザーに書き込み権限があることも確認してください。interval は更新間隔を秒数で指定しており、上の例の 86400 は24時間です。
format: yaml のファイルは、たとえば次のように payload の下にルールを並べます。domain の場合、値は対象ドメインを表します。先頭に +. を付ける形式は、対象ドメインとそのサブドメインをまとめて扱いたい場合に使われます。
取得するファイルの形式を classical にする場合は、プロバイダー側の behavior も合わせ、ファイル内にルールタイプと値を記述します。
RULE-SET,custom-sites,Proxy の custom-sites は、rule-providers で定義した名前と完全に一致させます。Proxy も既存のプロキシグループ名と一致する必要があります。大文字・小文字やハイフンの違いにも注意してください。特定のルールを DIRECT にしたい場合は、同じ書式で転送先を変更できます。
ルールの順序に注意
rules は上から順に評価されます。対象ルールより前に MATCH を置くと、そこで判定が終了し、後続の RULE-SET は利用されません。通常は個別ルールやルールセットを先に書き、包括的な MATCH を最後に配置します。
2更新・Git管理と動作確認
独自ルールを継続して運用するなら、ルールファイルを Git リポジトリで管理すると変更の追跡が簡単になります。ドメインを追加した理由や変更日をコミットメッセージに残しておけば、誤判定が発生したときに変更箇所を特定しやすくなります。公開リポジトリに置く場合は、機密情報や個人を特定できる接続先を含めないようにしてください。
- ルールの用途ごとにファイルを分け、ファイル名と
rule-providersの登録名を整理します。 - YAML のインデントをスペースで統一し、タブ文字を使わないようにします。設定例をコピーした後も、キーと値の階層が崩れていないか確認してください。
- 変更を Git にコミットし、Mihomo から直接取得できる URL を設定します。リポジトリのトップページ URL ではなく、生のファイルを返す URL を使います。
- クライアントで設定を再読み込みし、プロバイダーの更新状態とコアのログを確認します。必要に応じてクライアントの更新操作を実行します。
- テスト対象のドメインにアクセスし、接続ログで一致したルールと選択されたグループを確認します。
設定を変更した直後に反映されない場合は、まずクライアントが実際に読み込んでいるプロファイルを確認します。編集した YAML が別のプロファイルだった、またはサブスクリプションの更新で手動変更が上書きされた、というケースは少なくありません。Clash Verge Rev などのクライアントでは、プロファイル編集画面と実行中のコア設定が同じ内容かを照合してください。
- プロバイダーの更新に失敗する： URL のタイプミス、ネットワーク制限、配布元の応答エラー、証明書の問題を確認します。URL をブラウザーで開き、ルールファイルが取得できるか試してください。
- YAMLの読み込みで失敗する： インデント、コロン、引用符、重複したキーを見直します。
behaviorと配布ファイルの内容が対応しているかも確認します。 - 更新できるのにルールが当たらない：
rulesのプロバイダー名、グループ名、ルール順を確認します。接続ログで対象の通信が想定したドメインとして認識されているかも調べます。 - 変更が古いままに見える： 更新間隔を待つか、クライアントからプロバイダーを手動更新してキャッシュを再取得します。更新後も変化しない場合は、保存先の
pathと利用中の設定ファイルを確認してください。
問題を切り分けるときは、一度に複数の箇所を変更せず、「ルールファイルの取得」「YAMLの読み込み」「ルールとの一致」「転送先グループ」の順に確認すると効率的です。ルールを追加した後は、対象ドメインだけでなく、通常の通信が誤ってプロキシ経由や拒否になっていないかもテストしてください。
よくある質問
rule-providersを登録したのに振り分けられないのはなぜですか？
rule-providers はルールセットを登録するだけで、通信への適用は行いません。rules に RULE-SET,登録名,転送先 を追加し、登録名と転送先グループが実際の設定と一致しているか確認してください。また、その記述より前に MATCH がないことも重要です。
intervalは何秒に設定すればよいですか？
ルールの更新頻度に合わせて設定します。頻繁に変わらない独自リストなら、1日ごとの 86400 秒などが一つの目安です。短くしすぎると配布元へのアクセスが増えるため、必要以上に小さな値にせず、配布元の利用条件も確認してください。
domainとclassicalはどう選べばよいですか？
単純なドメイン一覧を読み込むなら domain、DOMAIN-SUFFIX や DOMAIN-KEYWORD など複数のルールタイプを含むルールを読み込むなら classical が適しています。ルールファイルの中身と behavior を対応させ、取得元が求める形式に従ってください。
個人用のルールも公開Gitで管理できますか？
誰でも取得できる公開リポジトリに個人用ルールを置くこと自体は可能ですが、社内限定のドメイン、内部 IP、利用者を特定できる情報などを含めるのは避けてください。非公開リポジトリを使う場合は、Mihomo が取得時に認証できる方法や URL へのアクセス条件を別途確認し、認証情報を不用意に設定ファイルへ埋め込まないようにします。
rule-providers を使えば、独自ルールを用途別に整理し、Gitで変更履歴を残しながら自動更新できます。まずは小さなドメイン一覧から始め、接続ログで判定を確かめてから対象を広げると、安全に運用しやすくなります。