この記事で分かること
Clash の設定ファイルに AI サービス、開発者向け SaaS、GitHub、パッケージレジストリなどのドメインを直接書き続けると、ルールが長くなり、重複や記述漏れを見つけにくくなります。特に AI ツールは、API 本体だけでなく認証、モデル一覧、ファイル配信、テレメトリなど複数のホストへ接続するため、最初は動いていてもアップデート後に一部だけタイムアウトすることがあります。
このようなときに役立つのが rule-providers です。ルールを外部の YAML ファイルへ切り出し、メイン設定から参照することで、用途ごとの分流リストを独立して管理できます。本稿では Clash Verge Rev や Mihomo 系クライアントを想定し、GitHub 上のルールを取得する基本構文、AI・開発ツール向けの分類、ルールの優先順位、更新失敗時の確認方法までを順番に説明します。
rule-providers は、単に「たくさんのドメインを別ファイルに保存する機能」ではありません。更新頻度の異なるルールを分離し、変更履歴を Git で追跡し、問題が起きたときに一つの用途だけを無効化できる運用部品です。自分で管理する場合は、接続先の正当性とライセンスを確認し、公開リストを無条件に信頼しないことも重要です。
rule-providers の仕組みと基本構文
通常のルールは、メイン設定の rules: 配下に一行ずつ記述します。これに対して rule-provider では、まず rule-providers: に外部ファイルの取得方法と形式を定義し、その後の rules: で RULE-SET として呼び出します。役割を分けることで、プロファイルの本体には「どの集合をどのポリシーへ送るか」だけを残せます。
代表的な設定は次のような形です。実際のフィールド名や利用可能な形式は、使用している Clash 系コアのドキュメントに合わせてください。Mihomo では YAML 形式の外部プロバイダーを扱う構成が一般的です。
rule-providers:
ai-services:
type: http
behavior: domain
url: https://raw.githubusercontent.com/example/project/main/rules/ai-services.yaml
path: ./providers/ai-services.yaml
interval: 86400
proxy: DIRECT
developer-tools:
type: http
behavior: domain
url: https://raw.githubusercontent.com/example/project/main/rules/developer-tools.yaml
path: ./providers/developer-tools.yaml
interval: 86400
proxy: DIRECT
rules:
- RULE-SET,ai-services,AI
- RULE-SET,developer-tools,Developer
- MATCH,DIRECTtype: http はリモート URL から取得する方式です。behavior: domain は、プロバイダー内にドメイン形式のルールを置くことを意味します。内容が IP CIDR の集合なら ipcidr、完全な Clash ルールを含む場合は classical を使うなど、ファイルの中身と behavior を一致させる必要があります。一致しない場合、更新自体は成功しているように見えても、実際のルールマッチが発生しません。
path は取得したファイルを保存する場所です。相対パスの基準はクライアントやコアによって異なるため、既存のプロファイルが使用しているディレクトリ構成に合わせます。ファイル名を用途ごとに固定しておくと、GUI のプロバイダー一覧で状態を確認しやすくなります。interval: 86400 は 24 時間間隔の更新例です。頻繁に変わらないリストを毎回取得する必要はなく、更新間隔を短くしすぎると GitHub 側の負荷や一時的な取得制限にもつながります。
AI と開発ツールを用途別に分ける方法
一つの巨大な provider にすべての外部サービスを入れると、管理は簡単に見えても、経路を細かく調整できなくなります。たとえば AI API は安定性を優先し、GitHub の公開リポジトリは別のグループへ送り、国内の社内 Git は DIRECT にする、といった判断が難しくなります。最初からサービスの性質と利用目的で分割しておくと、障害時の切り分けも容易です。
- ai-services：モデル API、AI 開発コンソール、認証や関連サービス。ストリーミング応答があるため、安定したプロキシグループへ送ります。
- developer-tools：GitHub、GitLab、コード検索、開発者向けドキュメントなど。ブラウザだけでなく CLI や IDE から接続する点を考慮します。
- package-registry：npm、PyPI、Docker Registry など。大きなファイルを取得するため、速度だけでなく接続の持続性も確認します。
- direct-services：社内 Git、ローカル API、地域のミラーサイトなど。外部プロキシを通すと遅くなったり、認証条件が変わったりする接続をまとめます。
AI 用リストを作るときは、サービス名だけでドメインを推測しないことが大切です。API の本体、ログイン画面、認証トークン、画像やファイルの配信先が別ドメインになっている場合があります。まず Clash の接続ログで実際に発生したホスト名を確認し、必要なものだけを provider に追加します。ワイルドカードを広く使うと設定は短くなりますが、同じ親ドメインに通常のウェブサイトや別用途の API が含まれる場合は、意図しない通信まで同じノードへ送る可能性があります。
GitHub についても、すべてを一括でプロキシへ送る必要があるとは限りません。公開ページの閲覧、Git の clone、Release からのバイナリ取得、GitHub API は、それぞれ接続先や必要な帯域が異なることがあります。まずは一つの provider にまとめ、ログと体感を確認した後、必要なら github-web、github-api、github-download のように分けるのが現実的です。
実際に provider を追加して動作を確認する
ここでは、既存のプロファイルを壊さずに小さな provider を追加する流れを紹介します。設定変更の前に、Clash Verge Rev のプロファイルを複製するか、現在の YAML を保存してください。購読プロファイルを直接編集すると、次回更新時に変更が上書きされることがあるため、クライアントに拡張設定やオーバーライド機能がある場合は、その仕組みを優先します。
- ルールファイルを用意する。 GitHub のリポジトリ内に、用途が分かる名前の YAML ファイルを作成します。ドメイン型なら、重複を避けて一行に一つのドメインを置き、不要な説明文や HTML を混ぜないようにします。
- 取得 URL をブラウザで確認する。 Raw URL を直接開き、ログイン画面や 404 ページではなく、期待した YAML の内容が返ることを確認します。GitHub の通常ページ URL と Raw URL を取り違えないでください。
- provider 定義を追加する。 固有の provider 名、正しい
behavior、保存先のpath、更新間隔を設定します。既存の名前と重複させると、どの定義が使われているか分かりにくくなります。 - RULE-SET を上位へ置く。
rules:の中で provider を呼び出します。汎用的なDOMAIN-SUFFIXや地域別ルール、最後のMATCHより後ろに置くと、先に別ルールへマッチして provider が使われないことがあります。 - 設定を検証して再読み込みする。 YAML のインデント、コロン、引用符を確認し、クライアントの設定チェックを実行します。保存後はプロファイルを再読み込みし、プロバイダー一覧に取得済みまたは更新成功と表示されるか確認します。
- 対象サービスへ接続する。 AI のログイン、API 呼び出し、GitHub の clone や Release 取得など、実際に使う操作を一つずつ試します。ブラウザで成功しても、CLI が同じ経路を使うとは限らないため、両方を確認してください。
動作確認では、単にウェブページが開いたかだけで判断しません。Clash のログで対象ホストを検索し、マッチしたルール名と送信先プロキシグループを確認します。たとえば認証ホストは PROXY へ進んでいるのに、API 本体だけ DIRECT になっている場合、ユーザーからは「ログインはできるが生成が失敗する」と見えます。provider の中身とルールの順番を分けて調べると、原因を短時間で特定できます。
ルールの優先順位と安全な更新設計
Clash のルールは基本的に上から評価され、最初に一致したルールが採用されます。そのため、provider を追加しただけでは十分ではありません。先に広すぎるルールがあると、後ろの provider まで処理が到達しません。特に GEOIP、大きな DOMAIN-SUFFIX、既存の地域別ルール、MATCH は影響範囲が広いため、配置を必ず見直します。
優先順位の考え方は、例外、用途別 provider、一般ルール、最終フォールバックの順にすると整理しやすくなります。社内ドメインや localhost のように絶対に直結させたいものは先頭付近に置き、その後に AI や開発ツールの provider を置きます。最後に一般的な地域ルールと MATCH,DIRECT または既定のプロキシグループを置きます。プロバイダー間で同じドメインが重複する場合は、より限定的な用途を先に置く必要があります。
GitHub から自動更新する場合、更新元の変更を無条件に取り込むのではなく、差分を確認できる運用が望まれます。自分のリポジトリで管理するなら、Pull Request やタグ、コミット履歴を使って変更理由を残せます。第三者のリストを使う場合は、更新後に新しいドメインが追加されていないか、広すぎるワイルドカードが入っていないかを確認してください。ルールファイルは通信経路を変える設定なので、実行ファイルほどではないとしても、供給元の管理は必要です。
また、GitHub の Raw 配信が一時的に取得できないとき、すでに保存済みの provider がそのまま使われるか、クライアントが空のルールとして扱うかは実装によって異なります。重要な業務で使う場合は、更新失敗時の挙動を一度テストし、取得不能時に危険な DIRECT へフォールバックしない構成を選びます。更新間隔を適切に設定し、不要な強制更新を繰り返さないことも安定運用につながります。
更新失敗と分流漏れの確認手順
provider が更新されない場合、最初に URL を確認します。GitHub のリポジトリが private になった、ブランチ名が変わった、ファイルを移動した、Raw 配信が 404 や 403 を返している、といった単純な原因が少なくありません。ブラウザで URL を開けても、Clash が起動している環境から同じ URL に到達できるとは限らないため、クライアントのプロバイダーログも確認します。
次に、設定ファイルの構文と保存先を調べます。YAML ではインデントが意味を持つため、タブとスペースの混在、provider 名の重複、URL の引用符漏れ、同じ階層に置くべき項目のずれが典型的な原因です。path のディレクトリが作成されていない場合や、プロファイルが読み取り専用の場合もあります。GUI にエラーが出ないときは、実際に保存先へファイルが作られているかを確認してください。
更新成功後も通信が DIRECT になるなら、次の順番で切り分けます。
- 対象ホストが provider のファイルに本当に含まれているか確認する。
behaviorとファイルのルール形式が一致しているか確認する。RULE-SETの provider 名が定義側と完全に一致しているか確認する。- 上にある既存ルールが先に一致していないか、ログのマッチ結果を見る。
- 対象アプリが DNS キャッシュや既存の Keep-Alive 接続を保持していないか確認する。
- CLI や IDE がシステムプロキシを使わず、別の
HTTP_PROXY設定を持っていないか調べる。
AI サービスでは、同じ操作を「ログイン」「モデル一覧の取得」「短い生成」「長いストリーミング生成」に分けて試すと、どの段階で経路が崩れているか分かります。GitHub では、ウェブ閲覧、API、Git over HTTPS、Release ダウンロードを別々に確認します。すべてを一度に試すより、Clash の接続ログと操作時刻を照合しやすくなり、provider の不足なのか、ノードや TLS、アプリ側のプロキシ設定なのかを切り分けられます。
固定リストを手作業で増やすだけの運用では、設定ファイルが肥大化し、同じドメインの重複や優先順位の事故が起こりやすくなります。一方、rule-providers は GitHub 上の変更履歴を確認しながら用途別に更新でき、AI API と開発ツールを別グループへ送る設計にも向いています。一般的な GUI だけのプロキシツールでは、外部ルールの再利用やルール順序の検証が難しい場合がありますが、Clash は YAML とログを通じて経路を説明しやすく、更新間隔やフォールバックまで自分で管理できます。複数サービスの分流を安全に整理したいなら、まず小さな provider から試し、動作ログを確認しながら Clash の設定を組み立ててみてください。