GitHubでMihomoのrule-providersを自作するYAML設定・運用ガイド

rule-providersを使うメリット

Mihomoの設定を使い続けていると、AIサービス、開発ツール、広告配信など、目的ごとのルールが増えていきます。すべてをメインの rules: に直接書く方法は手軽ですが、項目が多くなるほど設定ファイルが読みづらくなり、更新のたびに本体のYAMLを編集して配布し直す手間もかかります。複数の端末で同じルールを使う場合は、端末ごとの設定差分が生まれやすい点も課題です。

rule-providersは、ルールを別ファイルとして管理し、MihomoからHTTP経由で読み込む仕組みです。たとえばGitHubリポジトリに ai-services.yaml を置けば、ルールを変更する作業とメイン設定の変更を分けられます。利用する側はプロバイダー名を指定するだけでよく、ルールの追加や整理もリポジトリ上で行えます。更新をGitのコミット履歴で追えるため、「いつ、何を、なぜ変えたか」を確認しやすいのも利点です。

ここで押さえておきたいのは、rule-providerが通信先を直接決める機能ではないという点です。プロバイダーは条件に合う通信先のルールを提供し、実際にその通信をどこへ送るかは rules: のルールからプロキシグループなどのポリシーへ渡します。ルールの配布元と、通信の出口を選ぶ設定を分けて考えると、構成を保守しやすくなります。

なお、rule-providerの設定項目や対応形式はMihomoのバージョンによって異なる場合があります。以下の例を導入する前に、利用中のカーネルが指定した形式をサポートしているか確認してください。クライアントの画面上の名称が異なっていても、読み込まれるMihomo設定の構造を基準に確認するのが確実です。

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

最初は、用途を一つに絞った小さなルールファイルから始めましょう。ここではAIサービス用のルールを例にします。公開リポジトリなら、GitHubのRaw URLからファイルを配信できます。ルールにAPIキー、購読URL、個人情報などを含めないようにし、公開して問題のないドメインやルールだけを保存してください。

GitHub上でリポジトリを作成し、用途が分かるファイル名でYAMLを追加します。MihomoでYAML形式のルールセットとして扱う場合、ファイルには payload を置き、その下にルールを並べます。以下は構造を示す例です。実際に登録するドメインは、自分が利用するサービスの公式ドメインを確認したうえで選んでください。

payload:
  - DOMAIN-SUFFIX,example-ai.com
  - DOMAIN,api.example-ai.com
  - DOMAIN-SUFFIX,example-devtools.com

ルールの種類には、主にドメインを扱うもの、IPアドレスやCIDRを扱うもの、複数種類の条件を含められるクラシック形式があります。用途とファイルの中身に合った behavior を指定してください。ドメイン名を並べたファイルにIP用の形式を指定するなど、内容と宣言が食い違うと、取得に成功しても期待どおりに一致しないことがあります。

domain：ドメインベースのルールセットに使用します。ワイルドカードやドメインの包含関係を扱う場合は、形式の対応状況を確認してください。
ipcidr：IPv4・IPv6のアドレス範囲を扱うルールセットに使用します。CIDRの書式やアドレス種別が正しいか確認します。
classical：ドメインやIPなど、Mihomoの通常のルール形式を含むセットに使用します。ルールごとの記述形式も、利用中のMihomoに合わせてください。

公開URLには、リポジトリ画面のHTMLページではなく、ファイル本体を返すRaw URLを指定します。URLをブラウザーで開き、ログイン画面やGitHubのファイル表示ページではなく、作成したYAMLの内容が返ることを確認してください。ブランチの main を参照するURLは更新しやすい一方、ブランチ上の変更がそのまま利用者へ反映されます。変更を慎重に管理したい場合は、リリース用ブランチやタグを使う方法も検討できます。

運用のヒント：AI関連、社内サービス、開発ツールのように更新理由が異なるルールは、ファイルを分けるとレビューしやすくなります。ただし、細分化しすぎるとプロバイダーの数や確認箇所が増えるため、変更頻度と目的のまとまりを見ながら分割してください。

YAMLでproviderとプロキシグループをつなぐ

ルールファイルを用意したら、メイン設定のトップレベルに rule-providers: を追加します。次の例では、GitHubからファイルを取得し、ローカルの指定パスに保存して、24時間ごとに更新を確認する構成にしています。URLとパスは環境に合わせて変更してください。

rule-providers:
  ai-services:
    type: http
    behavior: classical
    format: yaml
    url: "https://raw.githubusercontent.com/your-account/your-rules/main/ai-services.yaml"
    path: ./ruleset/ai-services.yaml
    interval: 86400

proxy-groups:
  - name: AI-Proxy
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - RULE-SET,ai-services,AI-Proxy
  - MATCH,DIRECT

各フィールドの役割を理解しておくと、取得エラーや読み込み漏れを切り分けやすくなります。type: http はHTTP経由でルールセットを取得すること、behavior はルールの分類、format はファイル形式を表します。url は配信元、path はローカルでの保存先、interval は更新確認の間隔を秒数で指定します。更新間隔を短くすれば即時性は高まりますが、配信元へのアクセス回数も増えます。頻繁に編集しないリストなら、数時間から1日程度を起点に運用するのが現実的です。

RULE-SET,ai-services,AI-Proxy は、provider名 ai-services のルールに一致した通信を AI-Proxy グループへ渡す指定です。ここに書く名前は proxy-groups: にあるグループ名と一致させます。グループ名が存在しない、または表記が違う場合は、設定の読み込みに失敗したり、意図した出口を選べなかったりする原因になります。グループ内の PROXY は説明用の名前なので、実際には自分の設定に存在するプロキシ名や別のグループ名へ置き換えてください。

ルールの順番も重要です。Mihomoは設定されたルールを上から確認し、最初に一致したルールのポリシーを使います。広い条件のルールや最終的な MATCH を先に置くと、その下にあるrule-providerへ到達しません。既存の設定に特定ドメインの例外がある場合は、その例外とproviderのどちらを優先するか決めてから並べます。たとえば「特定サービスだけDIRECTにする」例外を優先したいなら、その例外を該当するRULE-SETより前に置きます。

注意：path を別のproviderと同じ場所にすると、取得したファイルが競合する可能性があります。providerごとに異なるファイル名を付け、設定ファイルからの相対パスが意図した場所を指しているか確認してください。クライアントによっては設定ファイルの保存先や相対パスの基準が異なるため、起動ログも合わせて確認する必要があります。

更新・検証・変更を安全に運用する

設定を一度読み込めたら終わりではありません。providerは起動時や指定した更新間隔でファイルを取得するため、GitHub側のURL変更、ファイル名の変更、YAMLの構文ミス、ネットワーク障害があると、更新が止まったり以前のルールが残ったりする場合があります。まず、変更前の設定ファイルをバックアップし、少量のルールで取得から通信確認まで一通り試すと、問題が起きた範囲を絞りやすくなります。

ファイル単体を確認する：Raw URLをブラウザーやHTTPクライアントで開き、想定したファイル内容が返ることを確認します。404やHTMLのエラーページが返る場合、Mihomo側ではなくURLや公開設定に原因がある可能性があります。
YAMLを検証する：インデント、コロン、リストのハイフン、引用符を確認します。YAMLでは空白のずれが構造の違いになるため、タブを混在させず、既存のルール形式に合わせて記述してください。
Mihomoの設定をテストする：利用中のカーネルが提供する設定検証機能やクライアントのテスト機能を使い、provider名、形式、ポリシー名、ルール順のエラーを確認します。テスト用コマンドを使う場合は、手元のMihomoバージョンに対応したオプションを確認してください。
ログと接続を照合する：プロバイダーの取得エラーがないかをログで見たうえで、テスト対象の通信がどのルールに一致し、どのグループへ送られたかを確認します。接続できない場合も、ルールの誤判定とプロキシノードの障害を分けて調べます。
小さく変更して戻せるようにする：ルール追加とグループ変更を同時に行わず、コミット単位を分けます。問題が出たときは、Gitの差分で直前の変更を特定し、最後に正常だった版へ戻せる状態を保ちます。

GitHub上でのレビューでは、ルールを追加した理由、対象サービス、確認日をコミットメッセージや変更説明に残すと、後から不要なルールを整理しやすくなります。ドメインの仕様変更やサービスの統合で古い記述が残ることもあるため、ルールを増やすだけでなく、定期的に利用状況を見直してください。ひとつのサービスが複数のドメインやAPIホストを使うケースでは、トップページだけで動作確認しても不足することがあります。ログイン、API呼び出し、更新処理など、実際に使う機能ごとに確認すると、必要なルールを見つけやすくなります。

ルールを公開リポジトリで共有する場合は、誤った更新がすべての利用端末へ届く可能性も考慮します。大きな変更は別ブランチでテストし、動作確認後に配布用ブランチへ反映する方法が安全です。また、GitHubの公開状態を変更したり、Raw URLの構成を変えたりすると取得できなくなることがあるため、URLの安定性も運用項目に含めてください。自動更新は便利ですが、レビューや検証の代わりにはなりません。更新頻度と変更リスクのバランスを取り、問題が起きた場合に戻せる手順を用意しておくことが大切です。

ルールをすべてメイン設定へ直接書く方法は、少量なら分かりやすい一方、分流リストが増えると変更の追跡や複数端末への反映が煩雑になりがちです。GitHubで管理するrule-providersなら、変更履歴を確認しながらルールを分離でき、Mihomoではプロキシグループとの連携やルール順を一つの設定で制御できます。こうした柔軟な運用を試したい方は、利用環境に合うClashクライアントを選び、設定を小さく検証しながら始めてみてください。Clashを無料でダウンロード