Clashのrule-providers自作術｜AI・開発ツール向けYAML設定

はじめに

Clash の設定ファイルが大きくなると、rules: の下にドメインを追加するだけでも、重複や記述ミスが発生しやすくなります。特に ChatGPT、Claude、Gemini などの AI サービス、GitHub、Docker Hub、npm、PyPI といった開発ツールを一つの YAML に詰め込むと、サブスクリプション更新時に自分の変更が上書きされる問題も起こります。

そこで役立つのが rule-providers です。ルール本体を専用の YAML ファイルへ分離し、メイン設定から名前を指定して読み込ませることで、設定を小さな部品として管理できます。Clash Verge Rev や Mihomo を使っている場合は、AI サービスだけを特定のプロキシグループへ送り、国内サービスや社内ドメインは直接接続する、といった分流を安全に整理できます。

1rule-providers を使う理由

通常の Clash 設定では、すべてのドメインルールをメインファイルの rules: に直接書きます。数個のサイトだけなら問題ありませんが、サービスの関連ドメインが増えると、設定全体の見通しが悪くなります。さらに、プロバイダーが配布する設定を定期的に更新する場合、手作業で追加した行と自動更新部分を区別しにくくなります。

• 役割ごとに分離： AI、開発ツール、広告、社内サービスなどを別ファイルで管理できます。
• 更新範囲を限定： GitHub 上のルールファイルだけを更新し、プロキシノードや DNS 設定を変更せずに済みます。
• 再利用しやすい： 複数のプロファイルから同じルールセットを読み込めます。
• トラブルを追跡しやすい： どのファイルを変更したかを Git の履歴で確認できます。

ただし、rule-providers は通信を自動的に高速化する機能ではありません。あくまでルールを整理して読み込む仕組みです。実際の速度や安定性は、選択したプロキシノード、DNS、回線品質、対象サービス側の状態にも左右されます。

2基本の YAML 構造を作る

ここではローカルファイルを読み込む方式を使います。まず、プロファイルと同じ管理フォルダー、またはクライアントが参照できる専用フォルダーに ai-tools.yaml を作成します。ルールプロバイダーの本文は、Mihomo で扱いやすい classical 形式にしておくと、ドメイン、キーワード、IP ルールを一つのファイルにまとめられます。

次に、メイン設定の rule-providers: でファイルを登録します。ローカルファイルを使う場合は type: file、インターネット上の URL を使う場合は type: http を指定します。下記の path は環境によって異なるため、Clash Verge Rev のプロファイルフォルダーからの相対位置を確認してください。

RULE-SET の第2項はプロバイダー名、第3項は一致した通信を送るポリシーグループです。ここでは、プロキシグループ名が実際に AI-開発 になっていることが前提です。名前が違う場合は、そのグループ名に置き換えてください。YAML のインデントはスペースで統一し、タブを使わないことも重要です。

3AI・開発ツール向けに設計する

ルールを分けるときは、サービス名をそのまま一つの巨大なリストにするより、通信の目的と変更頻度を基準に分類すると保守しやすくなります。たとえば AI サービスは認証、画面表示、API、静的ファイルなど複数のドメインを利用するため、公式ドメインをまとめたセットを用意します。開発ツールは Git の取得、コンテナイメージ、パッケージレジストリなど、用途ごとに分ける方法もあります。

ルールの順番は非常に重要です。Clash は上から順番に評価し、最初に一致したルールを採用します。したがって、特定の例外を先に置き、広いキーワードルールや MATCH を後ろに置く必要があります。たとえば、社内 Git サーバーを直接接続したい場合は、AI・開発用のルールセットより前に例外を追加します。

4Git で更新と検証を管理する

自作ルールを長く使うなら、ファイルを Git リポジトリで管理するのがおすすめです。変更履歴が残るため、あるドメインを追加した後に接続障害が起きても、直前の状態へ戻せます。公開リポジトリに置く場合は、購読 URL、認証情報、個人の社内ドメイン、ノード情報を絶対に含めないでください。

HTTP 形式で配布する場合は、ルールファイルを Raw URL で公開し、メイン設定側で更新間隔を指定します。URL の内容が壊れていると全体のルーティングに影響するため、変更後は YAML の構文チェックと実通信の確認を行ってから公開してください。

interval: 86400 は 24 時間ごとの更新を意味します。頻繁に変更しない自作ルールを数分間隔で取得する必要はありません。更新に失敗した場合に備え、ローカルのキャッシュファイルを残しておくと、前回正常に取得したルールを継続して利用できます。

5マッチング結果を確認する

設定を書いた後に最も大切なのは、「そのルールが本当に使われたか」を確認することです。Clash Verge Rev の Logs または Connections 画面を開き、対象サービスへアクセスします。接続先のドメイン、使用されたルール、選択された策略グループを確認し、意図したポリシーへ送られているかを見ます。

• ルールセット名を確認： ログに RULE-SET と関連するプロバイダー名が表示されるか確認します。
• サブドメインを確認： Web 画面だけでなく、API、画像、認証、WebSocket の通信も別ドメインとして確認します。
• 例外を確認： 社内サービスや国内サービスが意図せずプロキシへ送られていないか確認します。
• 再読み込みを確認： ルールファイルを変更したら、プロファイルまたはプロバイダーを更新してからテストします。

期待どおりに動かない場合は、まず YAML のインデント、ファイルパス、behavior の種類、プロバイダー名のスペルを確認してください。次に、同じドメインへ一致する上位ルールがないか調べます。DNS キャッシュやブラウザーの接続状態が残っていることもあるため、必要に応じて Clash を再起動し、対象アプリも再接続します。

よくある質問

rule-providers と外部ルール購読は同じものですか？

仕組みとしては似ていますが、必ずしも同じではありません。rule-providers は Clash の設定からルールセットを参照するための機能で、読み込み元はローカルファイルにも外部 URL にもできます。外部ルール購読は、その URL から定期的にルールを取得する運用を指すことが多く、自作ファイルをローカルだけで使う場合も rule-providers に含まれます。

AI サービスのドメインを一つ追加すれば十分ですか？

多くの場合は不十分です。トップページ、ログイン、API、静的コンテンツ、ファイル配信が別ドメインになっていることがあります。ブラウザーの接続ログを確認し、必要な通信だけを段階的に追加してください。広範囲なキーワード指定は便利ですが、無関係な通信まで同じグループへ送る可能性があります。

ルールが反映されないときはどうすればよいですか？

プロバイダーのファイルが存在するか、YAML が正しいか、RULE-SET の名前と behavior が一致しているかを確認します。その後、プロファイルを更新して接続を再作成してください。なお、クライアントやコアによって対応する形式が異なるため、Mihomo の仕様と使用中のバージョンも確認しましょう。

GitHub でルールを公開しても問題ありませんか？

一般的なドメイン一覧だけなら公開できますが、個人情報、社内ホスト名、購読リンク、アクセストークン、プロキシ設定は含めないでください。公開前にコミット履歴も確認し、過去のコミットに秘密情報が残っていない状態にします。変更後はまずローカルで検証し、安定してから Raw URL を Clash に登録するのが安全です。