rule-providersの役割を理解する
Clashのrule-providersは、通信ルールをメイン設定ファイルから分離して管理するための機能です。通常のrulesにすべてのドメインやIPアドレスを直接書く方法では、設定が長くなり、購読設定を更新するたびに手書き部分を失う危険があります。ルールプロバイダーを使えば、メイン設定には参照先と適用先だけを残し、開発ツール、AIサービス、広告、社内ドメインなどのルールを個別のYAMLファイルとして更新できます。
処理の流れは比較的単純です。mihomoは起動時または指定した更新間隔にルールファイルを取得し、ローカルのプロバイダーデータとして保存します。その後、メイン設定のrulesに記述されたRULE-SETを上から順に評価し、条件に一致した通信を指定したプロキシグループやDIRECTへ送ります。ルールプロバイダーそのものが通信経路を決めるのではなく、どのポリシーへ渡すかをメイン設定側で指定する点が重要です。
| 項目 | 役割 | 例 |
|---|---|---|
rule-providers |
ルールファイルの取得先と形式を定義する | GitHub上のYAML、ローカルファイル |
RULE-SET |
プロバイダーを通常のルールとして参照する | RULE-SET,ai-services,AI |
| プロキシグループ | 一致した通信の送信先を決める | AI、開発、DIRECT |
behavior |
取得したファイルをドメイン、IP、クラシック形式として解釈する | domain、ipcidr、classical |
GitHubでルールYAMLを設計する
GitHubで公開するルールファイルは、Clashの設定全体ではなく、ルール項目だけを持つ小さなファイルにします。開発ツール向けなら、コードホスティング、パッケージレジストリ、ドキュメント、コンテナレジストリなどを用途別に分けると、後から原因を調べやすくなります。AIサービスも、チャット、API、認証、モデル配信などを一つにまとめる方法と、用途別に分割する方法があります。最初はファイル数を増やしすぎず、通信ポリシーが異なる単位で分割するのが実用的です。
最も扱いやすい形式の一つが、ドメインルールをYAMLのpayloadに並べる方法です。YAMLのインデントにはタブを使わず、半角スペースを使用します。ドメイン名に不要なプロトコル、パス、クエリ文字列を付けないでください。https://example.com/apiはドメインルールとして適切ではなく、DOMAIN-SUFFIX,example.comのようなClashルール形式に変換する必要があります。
payload:
- DOMAIN-SUFFIX,developer.example
- DOMAIN-SUFFIX,registry.example
- DOMAIN,api.example
- DOMAIN-SUFFIX,docs.exampleこのファイルをbehavior: classicalで読み込む場合は、各行にDOMAINやDOMAIN-SUFFIXなどのルールタイプを付けます。一方、ドメインだけを列挙するファイルを使うなら、behavior: domainにして、対応する形式を明確にします。形式と内容が一致しないと、ファイルは取得できてもルールプロバイダーの解析に失敗します。
ルール形式を使い分ける
| 形式 | ファイルの内容 | 向いている用途 | 注意点 |
|---|---|---|---|
domain |
ドメインやサフィックスを中心に記述 | サービス名、広告、開発サイト | IP-CIDRや複雑なルールは別管理にする |
ipcidr |
IPv4またはIPv6のCIDR | 固定ネットワーク、社内アドレス | IPの変更に弱く、更新確認が必要 |
classical |
DOMAIN、PROCESS-NAMEなどのClashルール |
条件を細かく組み合わせる設定 | 各行の構文と順序を検証する |
mrs |
mihomo向けにコンパイルされたルールセット | 大規模なルールを高速に扱う場合 | 作成ツールとカーネルの互換性を確認する |
GitHub側では、変更履歴を追えるようにコミットを小さく保ちます。たとえば「AIサービスを追加」「開発用レジストリを削除」「誤判定するドメインを分離」のように、目的ごとにコミットを分けると、問題が起きたときに直前の状態へ戻しやすくなります。公開リポジトリでは、購読URL、アクセストークン、プライベートサーバーのIP、社内ホスト名などを絶対に含めないでください。
メイン設定からRULE-SETを参照する
ルールプロバイダーを使うには、まずrule-providersで名前、取得先、ローカル保存先、形式、更新間隔を定義します。次に、通常のrulesの中でRULE-SETを呼び出します。以下は、開発ツールとAIサービスを別々のプロキシグループへ送る基本例です。proxyの値は、実際の設定に存在するプロキシグループ名へ置き換えてください。
rule-providers:
dev-tools:
type: http
behavior: classical
format: yaml
path: ./rules/dev-tools.yaml
url: https://raw.example.invalid/your-account/rules/main/dev-tools.yaml
interval: 86400
proxy: DIRECT
ai-services:
type: http
behavior: classical
format: yaml
path: ./rules/ai-services.yaml
url: https://raw.example.invalid/your-account/rules/main/ai-services.yaml
interval: 86400
proxy: DIRECT
rules:
- RULE-SET,dev-tools,開発
- RULE-SET,ai-services,AI
- MATCH,PROXYpathはプロバイダーを保存するローカルパスです。既存の設定で使われているディレクトリ構成に合わせ、必要なら事前にrulesフォルダーを作成します。urlは、Clashから直接取得できる公開ファイルのURLを指定します。GitHubのリポジトリ画面を表示するURLではなく、ファイルの生データを返すURLを使う必要があります。URLをブラウザーで開いたとき、HTMLのリポジトリ画面ではなくYAML本文が表示されることを確認してください。
intervalの単位は秒です。86400なら24時間ごと、21600なら6時間ごとの更新です。頻繁に変更しない個人ルールに対して短い間隔を設定すると、GitHub側のレート制限や一時的な取得失敗を招くことがあります。日常用ルールなら24時間、業務上数回更新する必要がある場合でも6時間程度から始め、ログを確認しながら調整してください。
| フィールド | 設定例 | 確認ポイント |
|---|---|---|
type |
http |
リモートURLから取得する場合に使用する |
behavior |
classical |
ファイル内のルール記法と一致させる |
format |
yaml |
YAMLのpayloadを使う場合に指定する |
path |
./rules/ai-services.yaml |
書き込み可能な保存先にする |
proxy |
DIRECT |
ルール取得時の経路。必要なら更新用グループを指定する |
更新先自体への接続に問題がある環境では、proxy: DIRECTで取得できないことがあります。その場合は、既存のプロキシグループを指定して更新通信だけをプロキシ経由にします。ただし、更新用プロキシの選択が、同じルールプロバイダーの判定結果に依存すると循環が起きる可能性があります。更新用の通信経路は、メインの振り分けルールから独立した安定したグループにしてください。
開発ツールとAIサービスを安全に振り分ける
開発ツール用ルールでは、サービスのトップドメインだけでなく、認証、API、ダウンロード、コンテナイメージ取得に使われるドメインを確認します。ただし、公式ドキュメントに書かれていないサブドメインを推測で追加すると、無関係な通信まで同じプロキシへ送ることがあります。まずログやブラウザーの開発者ツール、アプリケーションの接続エラーから実際の接続先を確認し、必要なドメインだけを登録してください。
payload:
- DOMAIN-SUFFIX,code-host.example
- DOMAIN-SUFFIX,package-registry.example
- DOMAIN-SUFFIX,container-registry.example
- DOMAIN,api.developer.exampleAIサービスでは、Web画面とAPIのドメインが異なる場合があります。ログイン用ドメインだけを振り分けても、APIやモデル取得用の接続が別経路へ流れると、認証失敗や応答遅延が起きることがあります。一方で、広すぎるDOMAIN-SUFFIXを登録すると、同じ企業が提供する無関係なサービスまで対象になる場合があります。用途を明確にしたファイルを作り、追加したドメインごとに実際の動作を確認するのが安全です。
ルールの順序にも注意が必要です。rulesは上から評価され、最初に一致した行で処理が終了します。先にGEOIP,CN,DIRECTや広いDOMAIN-SUFFIXを置くと、後ろに書いたAI用ルールへ到達しないことがあります。個別の例外、専用プロバイダー、地域ルール、最終的なMATCHという順に整理すると、意図を説明しやすくなります。
rules:
- DOMAIN,private.example,DIRECT
- RULE-SET,dev-tools,開発
- RULE-SET,ai-services,AI
- GEOIP,LAN,DIRECT,no-resolve
- MATCH,PROXY更新失敗と誤判定を検証する
設定を保存しただけで正常動作と判断せず、まずYAMLの構文、次にプロバイダーの取得、最後に実際のルール照合という順番で確認します。インデントが崩れている場合は設定全体の読み込みに失敗します。設定は読み込めても、URLがHTMLを返していたり、GitHub側のファイルパスが違っていたりすると、プロバイダー更新だけが失敗します。FlClashなどのログ画面で、プロバイダー名、HTTPステータス、解析エラーを確認してください。
- 404：リポジトリ名、ブランチ名、ファイルパスのいずれかが間違っています。ファイルを移動した後はURLも更新します。
- 403または429：公開設定、アクセス制限、更新頻度を確認します。短い
intervalで何度も手動更新するのは避けてください。 - YAML解析エラー：タブ、コロン、引用符、インデントを確認します。YAML本文の先頭にHTMLやエラーメッセージが混ざっていないかも調べます。
- プロバイダーは更新済みだが通信が違う：
rulesの順序、プロバイダー名、プロキシグループ名、DNSで得られた接続先を確認します。 - 一部のアプリだけ対象外になる：そのアプリがシステムプロキシを使っているか、TUNが有効か、独自のDNSやQUIC接続を使用していないか確認します。
誤判定が見つかった場合は、いきなり大きなルールを削除せず、原因となるドメインを別の例外ルールへ移します。たとえば開発サービスの一部だけを直接接続したい場合、専用のDOMAINルールを該当するRULE-SETより前に置きます。変更後は、ブラウザーだけでなく対象アプリのログイン、API呼び出し、ファイル取得など複数の操作を確認してください。
rules:
- DOMAIN,local-api.developer.example,DIRECT
- RULE-SET,dev-tools,開発
- RULE-SET,ai-services,AI
- MATCH,PROXYGitHubで管理する利点は、変更履歴とレビューを残せることです。新しいドメインを追加するときは、サービス名、追加理由、確認したアプリ、想定するプロキシグループをコミットメッセージに記録します。定期的にルールを見直し、使われなくなったドメインを削除すれば、不要なプロキシ転送や将来の誤判定も減らせます。最終的には、ルールを増やすことよりも、目的、取得経路、適用順序を明確に保つことが安定運用につながります。