この記事で分かること

Clash の設定にサービス別ルールを何行も追加していると、プロファイルを更新したときに手元の変更が消えたり、別の端末へ同じルールを移すのが面倒になったりします。そこで役立つのが rule-providers です。ルール本体を独立した YAML ファイルとして GitHub などに置き、Clash のメイン設定から読み込めば、プロファイルを直接編集せずに自分用のルールセットを管理できます。

この記事では、Mihomo 対応の Clash クライアントを想定し、GitHub でルールファイルを作成する方法、rule-providers の設定、ルールの評価順、更新の確認、マッチしないときのログ調査を順に説明します。ここでいう「自作ルール」は、接続先ドメインなどをどのポリシーグループへ送るか指定するルールです。利用中のクライアントやコアのバージョンによって対応項目や画面名が異なることがあるため、適用前に現在のコアが Mihomo であることと、そのバージョンの設定仕様を確認してください。

rule-providers の仕組みと準備

rule-providers は、ルールを取得・保存する設定です。どの通信にそのルールを適用するかは、メイン設定の rules に RULE-SET を書いて決めます。つまり、プロバイダーを定義しただけでは分流は始まりません。ルールセットの名前、参照先、最終的なポリシーが正しくつながっている必要があります。

管理を始める前に、Clash の設定をバックアップし、テスト用の小さなルールセットを作るのがおすすめです。いきなり多数のドメインを移すのではなく、まず一つのサービスだけで読み込みからログ確認まで試すと、YAML の構文エラーとルールの設計ミスを分けて調べられます。GitHub のリポジトリを公開する場合は、購読 URL、認証情報、社内専用ドメインなどを誤って含めないようにしてください。

設定項目 役割 確認ポイント
type ルールの取得方法 GitHub の raw URL を使う場合は通常 http
behavior ルールの種類 domain、classical、ipcidr など、内容に合うものを選ぶ
url と path 取得元とローカル保存先 URL がファイルを直接返すこと、保存先のパスが他の設定と重ならないこと
interval HTTP プロバイダーの更新間隔 秒単位。頻繁に変わらない自作リストなら短くしすぎない
format ルールファイルの形式 YAML ファイルとして管理する場合は yaml を指定

ルールの分類は用途に合わせて選びます。ドメイン名を並べる用途では domain、通常の Clash ルール形式を複数種類まとめたい場合は classical、IP アドレス範囲を扱う場合は ipcidr が候補です。異なる種類のルールを一つのファイルへ詰め込むより、内容ごとに分けるほうが、読み込みエラーや意図しない一致を見つけやすくなります。

GitHub に YAML ルールセットを作成する

GitHub に専用リポジトリを作り、たとえば rules フォルダーの中へ work-services.yaml を追加します。公開リポジトリなら、Mihomo から参照する URL は通常、GitHub のファイル閲覧ページではなく raw ファイルの URL です。ブラウザーでファイルを開いて Raw を選び、取得先が YAML の本文を直接返すことを確認してください。ファイルの表示ページ URL をそのまま設定すると、HTML が返されて読み込みに失敗する場合があります。

domain 型の例では、ファイル内に payload を置き、その配下にドメインルールを並べます。ここでは、社内向けサービスのドメインをまとめる例を示します。実際には自分が管理するサービスや、分流したい対象に置き換えてください。

payload:
  - DOMAIN-SUFFIX,example.org
  - DOMAIN,portal.example.net
  - DOMAIN-KEYWORD,work-chat

次に、メインの Clash 設定へプロバイダー定義と RULE-SET を追加します。以下の PROXY は例です。実際に使う設定に存在するプロキシグループ名へ置き換えてください。グループ名は大文字・小文字や記号も含めて一致させます。

rule-providers:
  work-services:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/your-name/clash-rules/main/rules/work-services.yaml"
    path: ./ruleset/work-services.yaml
    interval: 86400
    format: yaml

rules:
  - RULE-SET,work-services,PROXY
  - MATCH,DIRECT

your-name やリポジトリ名、ブランチ名、ファイルの場所は実際のものに変更します。path は Mihomo が取得したファイルを保存する場所です。環境によって相対パスの基準が異なる場合があるため、設定画面で指定された作業ディレクトリやコアの仕様を確認してください。既存の設定が rules をすでに持っている場合は、例のブロックを丸ごと重ねて追加するのではなく、既存の同名キーへ内容を統合します。YAML ではインデントに意味があり、タブではなくスペースを使うのが基本です。

GitHub の更新を検出させたいからといって、interval を極端に短くする必要はありません。編集直後に反映を確認したい場合は、クライアントのプロバイダー更新操作を使うほうが分かりやすく、通常運用では変更頻度に合わせた間隔にします。また、非公開リポジトリは認証なしの raw URL から取得できないことがあります。アクセストークンを URL に埋め込んだり、秘密の情報を含むファイルを公開リポジトリに置いたりするのは避け、利用環境に合う安全な配布方法を選んでください。

ルールの優先順位と分流例

Clash のルールは上から順に評価され、最初に一致したルールのポリシーが使われます。そのため、特定サービス用の RULE-SET は、広い条件のルールや MATCH より上に置きます。末尾に MATCH,DIRECT がある状態で、その後ろにルールセットを追加しても、先に MATCH してしまうため届きません。既存設定の中に GEOIP や別の RULE-SET がある場合も、どの条件が先に一致するかを考えて並べ替えます。

たとえば、仕事用サービスをプロキシへ送り、それ以外の通信は既存ルールへ渡す構成なら、次のような順序を検討できます。ポリシー名は環境に合わせて読み替えてください。

rules:
  - RULE-SET,work-services,PROXY
  - DOMAIN-SUFFIX,example.jp,DIRECT
  - GEOIP,JP,DIRECT
  - MATCH,PROXY

この例では、work-services に一致した通信が先に PROXY へ送られます。続いて日本国内向けのドメインや IP のルールを評価し、どれにも一致しなかった通信は最後の MATCH へ進みます。実際の設定では、国内サービスを DIRECT にするのか、既定通信を DIRECT にするのかは利用目的によって変わります。例をそのまま貼り付けるのではなく、現在のルール全体と既定ポリシーを確認してください。

domain のように対象を絞ったルールセットは、管理しやすい反面、リストに入っていないサブドメインには一致しません。たとえば DOMAIN,portal.example.net はそのホストを対象にしますが、別のサブドメインも対象にしたいなら、意図を確認したうえで DOMAIN-SUFFIX を検討します。キーワード一致は便利ですが、名前に同じ文字列を含む無関係なドメインにも当たる可能性があります。対象範囲を広げるほど誤分流の確認が重要になります。

大きなルールセットを複数のポリシーへ分けたい場合は、用途や更新担当ごとにファイルとプロバイダーを分割すると、変更の影響範囲を追いやすくなります。一方、細かく分けすぎると参照設定や更新確認の箇所が増えます。「どの通信を、なぜ、このグループへ送るのか」を説明できる単位にするのが、長期間運用しやすい設計です。

GitHub 更新とログでのトラブル調査

ルールを変更するときは、まず GitHub 上のファイルを編集し、差分を確認してコミットします。変更後は Clash クライアント側で該当プロバイダーの更新を実行し、更新日時や状態が変わったかを確認します。自動更新を待たずに検証できるため、ルールの追加や削除を試す段階では手動更新が便利です。アプリによってはプロバイダー管理画面の名称や更新操作が異なるので、画面上の項目は利用中のバージョンに合わせて読み替えてください。

読み込みに失敗した場合は、まず設定全体の構文検証を行い、インデント、コロン、引用符、重複したトップレベルキーを確認します。次に、raw URL がファイル本文を返すか、ブランチ名とパスが正しいか、GitHub 上のファイル名と大文字・小文字まで一致しているかを調べます。path に指定した場所へファイルを保存できるかも確認してください。エラーが続くときは、変更したルールセットだけを一時的な最小構成で試すと、問題が URL、YAML、またはメイン設定のどこにあるか切り分けやすくなります。

設定が読み込めても通信が想定どおりにならない場合は、Clash Verge Rev などのクライアントの接続ログを開き、対象ドメインの接続先、マッチしたルール、選ばれたポリシーを確認します。ログに出たホスト名と、ルールファイルの記述を照合してください。別のサブドメインへ接続していたり、広いルールが先に一致していたりすると、期待した RULE-SET は使われません。DNS モードや IP 解決を使うルールでは、ドメインだけで判断できないケースもあるため、ログに表示される接続先とルールタイプを併せて確認します。

設定変更のたびに通信が変わる場合は、直前の変更を一つずつ戻して再現性を見ます。プロバイダー更新が古いファイルを使っていないか、更新後に設定を再読み込みする必要があるか、同じドメインを扱うルールが他にもないかも確認しましょう。GitHub のコミット履歴を使えば、いつどの行を変更したかを追跡でき、問題が起きたときに正常だった版へ戻しやすくなります。

GUI でルールを直接追加する方式は始めやすい一方、プロファイル更新で変更が消えたり、複数端末間で差分が生まれたりすることがあります。単独ファイルの管理だけなら他のルール編集ツールでも対応できますが、GitHub の履歴、差分確認、Mihomo の rule-providers を組み合わせると、変更理由と配布元を一か所で追いやすくなります。自分のルールを YAML で管理し、接続ログで結果まで確認したい場合は、Clash のクライアントとコアを用途に合わせて選ぶと運用を続けやすくなります。

Clash を無料でダウンロードして、快適なネット体験を →