この記事で分かること

Clash のルールを自分で追加したいとき、プロファイル本体にルールを直接書き足す方法だけでなく、rule-providersとして別ファイルに分け、GitHub から取得する方法があります。ルールを専用ファイルにまとめれば、設定の差分を Git で確認でき、複数の端末やプロファイルへ同じリストを配布しやすくなります。ドメインの追加や削除も GitHub 上の変更として記録できるため、「いつ、何を変更したか」を後から追えるのも利点です。

本稿では、Mihomo 系コアを使う Clash クライアントを想定し、GitHub にルールファイルを置く準備、rule-providers の各フィールド、プロファイル側での呼び出し方、ルールの優先順位、更新・エラー確認までを順に説明します。クライアントの画面や設定項目はバージョンにより異なりますが、YAML の基本構造とルールプロバイダーの考え方は共通です。なお、コアやクライアントによって対応するフィールド、形式、更新操作に違いがあるため、実際の運用前に利用中の Mihomo コアが設定を受け付けるか確認してください。

rule-providers の役割と使う前の準備

rule-providers は、ルール一覧をプロファイル本体から分離して管理する仕組みです。プロファイルには「どこから取得するか」「どの種類のルールか」「どのくらいの間隔で更新するか」を記述し、実際のドメインや IP アドレスの一覧は別ファイルに置きます。起動時や更新時にコアがそのファイルを読み込み、RULE-SET ルールから参照します。

まず GitHub で公開リポジトリを作り、用途が分かるディレクトリにルールファイルを保存します。たとえば rules/streaming.yaml のように、ファイル名から内容を推測できる形にすると、複数のリストを扱うときに管理しやすくなります。公開リポジトリであれば、ファイルの Raw URL を取得して Clash 側の取得先に指定できます。ブランチ名やディレクトリを変更した場合は URL も変わるため、リポジトリの移動や名前変更を行う前に、既存プロファイルへの影響を確認しましょう。

ルールファイルには、購読 URL、認証トークン、個人情報、非公開の社内ホスト名などを含めないでください。公開リポジトリの内容は誰でも閲覧・複製でき、過去のコミットにも変更前の情報が残る場合があります。個人用・組織用のルールを公開できない場合は、公開 Raw URL を前提とする構成を避け、利用するコアが対応する認証方式や安全な配布先を確認してください。GitHub の認証情報を YAML に直接埋め込む運用も避けるのが基本です。

TIP：最初は公開情報だけを含む小さなテスト用ルールファイルで動作を確認しましょう。GitHub の Raw URL をブラウザーで開き、意図したブランチ・パスの内容がそのまま表示されるか確かめてから Clash に登録すると、URL の誤りと YAML の誤りを分けて調べられます。

設定例と各フィールドの意味

次の例は、GitHub 上のドメイン用リストを取得し、プロキシグループへ送る構成です。YOUR-NAME と YOUR-REPOSITORY は実際の GitHub ユーザー名とリポジトリ名に置き換え、Raw URL がファイルの場所と一致するようにしてください。Proxy も例示名なので、利用中のプロファイルに存在するポリシーグループ名へ変更します。

rule-providers:
  custom-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/custom-domains.yaml
    url: "https://raw.githubusercontent.com/YOUR-NAME/YOUR-REPOSITORY/main/rules/custom-domains.yaml"
    interval: 86400

rules:
  - RULE-SET,custom-domains,Proxy
  - MATCH,DIRECT

type: http は、HTTP または HTTPS の URL からリストを取得する指定です。GitHub の Raw URL は HTTPS を使います。behavior はリストの内容をどう解釈するかを示し、domain、ipcidr、classical など、ルールの性質に合う値を選びます。format: yaml はファイル形式の指定です。クライアントやコアのバージョンによって省略時の扱いや対応形式が異なることがあるため、明示しておくと設定意図が分かりやすくなります。

path は取得したファイルをコアが保存するローカルの場所です。相対パスの基準は実行環境や設定の読み込み方に依存する場合があるため、書き換え可能な設定ディレクトリ内の場所を選び、実際の保存先を確認してください。複数の provider で同じ path を使い回すと、内容が上書きされたり、誤ったリストを参照したりする原因になります。provider ごとに異なるファイル名を割り当てるのが安全です。

interval: 86400 は更新間隔を秒で指定し、この例では 24 時間ごとの確認を意図しています。これは GitHub に変更を保存した瞬間に全クライアントへ配布する仕組みではありません。次の取得まで待つか、クライアントやコアが提供する provider 更新操作を実行する必要があります。また、短すぎる間隔は取得先へのリクエストを増やします。ルールの変更頻度と運用上の必要性を考え、無理のない値に設定しましょう。

ルールファイル側は、behavior: domain に対応するドメイン一覧として管理します。たとえば次のように、対象ドメインを一行ずつ記述します。

payload:
  - example.com
  - "+.example.net"
  - media.example.org

エントリーの意味は利用するコアの仕様に従います。一般に +.example.net のような表記は対象ドメインとサブドメインを含める用途で使われますが、採用前に小さなテストリストで実際のマッチ結果を確認してください。ドメインリストに DOMAIN-SUFFIX,... のようなルール行を混在させるのではなく、指定した behavior が期待する形式に揃えることが重要です。

behavior の選び方とルール順序

behavior とファイルの中身が一致しないと、取得自体は成功しているように見えても、ルールの解析に失敗したり、期待した通信にマッチしなかったりします。使い分けの目安は次のとおりです。

behavior 用途 ファイルに入れる内容
domain ドメイン単位でまとめる ドメイン名の一覧
ipcidr IP アドレス範囲をまとめる CIDR 表記のアドレス範囲
classical 複数種のルール条件をまとめる コアが受け付ける形式のルール行

classical は、単一のドメイン一覧では表しにくい条件を管理するときに便利です。ただし、ルール行にポリシー名まで含めるか、provider の外側でポリシーを指定するかなど、書式の細部はコアの仕様を確認してください。異なる behavior の内容を一つのファイルに混在させると、後から形式を判断しにくくなります。用途ごとにファイルと provider を分け、名前も custom-domains、office-ipcidr のように内容が伝わるものにすると、メンテナンスしやすくなります。

プロファイル内のルールは上から評価され、先に一致したルールが使われます。そのため、特定の例外や個別ルールを provider より先に書くと、provider の項目へ到達する前に処理される場合があります。逆に、広い範囲を対象にする provider を先頭近くへ置くと、後続の個別ルールが効かなくなることがあります。社内ドメインを DIRECT にする例外、特定サービスを別グループへ送るルール、一般的な provider、最後の MATCH というように、狭い条件から広い条件へ並べると意図を整理しやすいです。

RULE-SET,custom-domains,Proxy の custom-domains は rule-providers 内のキーと完全に一致させます。大文字・小文字やハイフンの違いも確認してください。Proxy は実際に存在するポリシーグループ名でなければなりません。ルールセットが正しく読み込まれていても、対象グループ名がプロファイルと一致しないと、設定検証でエラーになったり、通信が意図した出口に進まなかったりします。

GitHub で変更を配布・更新する手順

日々の更新では、ルールを直接編集する前に現在の内容を確認し、変更する理由を小さく分けて記録します。たとえば「サービスの新しい API ドメインを追加」「誤って含めたホストを削除」のようにコミットの目的を明確にすると、動作が変わったときに原因を追いやすくなります。変更前後の差分をレビューし、対象範囲が広がりすぎていないか、無関係なルールを誤って消していないかも確認してください。

  1. ルールを編集する：behavior に合う形式を保ち、同じ意味のエントリーや誤記がないか確認します。変更内容に個人情報や秘密情報が含まれていないことも、コミット前に見直します。
  2. GitHub へ反映する：変更をコミットし、Clash 側の URL が参照しているブランチとパスに保存します。別ブランチで作業している場合は、意図した変更が配布対象のブランチへ反映されたか確認します。
  3. Raw URL を確かめる：ブラウザーで URL を開き、404 ではなく更新後の内容が表示されるか確認します。ファイル名の大文字・小文字、ディレクトリ、ブランチ名の違いは取得失敗のよくある原因です。
  4. provider を更新する：クライアントの provider 更新機能、またはコアの再読み込みを使います。項目の名称や更新方法はクライアントごとに異なるため、画面上の状態表示も併せて確認してください。
  5. 実際の通信を検証する：対象ドメインへ接続し、ログや接続一覧でマッチしたルールと選ばれたポリシーを確認します。ファイルを取得できたことだけで完了とせず、通信が意図した経路へ進むところまでテストします。

更新の反映には、GitHub 側の配信キャッシュ、クライアントの更新間隔、ローカルに保持された provider の状態が関係することがあります。コミット直後に古い内容が見える場合は、まず Raw URL の表示を再確認し、その後にクライアントから明示的な更新を試します。URL のブランチ部分を変更して急場をしのぐ方法はありますが、設定との対応が複雑になるため、恒久運用では一つの配布先を決め、更新手順を記録するほうが安全です。

複数端末で共有する場合、各端末が同じ URL と provider 名を参照しているかを確認します。プロファイル本体は別々でも、共通のルール一覧を参照すればルールの重複を減らせます。一方、端末固有の例外を共通ファイルへ無理に詰め込むと、全ユーザーへ不要な変更が届きます。共通ルールと個別ルールを分け、変更の影響範囲が分かる構造にしておくのが実務的です。

取得エラーとマッチしないときの確認ポイント

provider が更新されないときは、画面に表示されるエラーを大きく「URL に届かない」「ファイル形式を解析できない」「読み込みは成功したが対象にマッチしない」に分けて考えます。すべてを同時に変更するのではなく、ログのエラー時刻と内容を確認し、一つずつ原因を切り分けると設定を壊しにくくなります。

  • 404 または取得失敗：Raw URL のユーザー名、リポジトリ名、ブランチ名、ファイルパスを見直します。GitHub の通常のファイル閲覧 URL と Raw URL は形式が異なるため、ブラウザーで対象ファイルの実データが表示される URL を指定してください。
  • タイムアウトや TLS エラー：実行端末のネットワーク、DNS、プロキシ経路を確認します。ブラウザーで開けても、Clash コア自身の取得通信が別の経路を使う場合があります。ログに出る接続先とエラーの段階を見て、まず通信経路の問題かを判断します。
  • YAML の解析エラー：インデント、コロン、引用符、リストの書式を確認します。YAML はインデントが構造の一部です。タブとスペースを混在させず、特殊文字を含む値は必要に応じて引用符で囲みます。
  • 取得済みなのにルールが効かない：behavior とファイル内容の形式、RULE-SET の provider 名、ルールの順番、対象グループ名を確認します。さらに、実際に接続しているホスト名がリストに含まれるかをログで照合してください。
  • 変更が反映されない：参照先のブランチとコミット先、更新間隔、手動更新の結果、ローカルキャッシュの状態を順番に調べます。古いファイルを参照している場合と、取得後のマッチ条件が異なる場合を混同しないことが大切です。

GitHub 上でファイルを編集できたからといって、すべての端末に即時反映されるわけではありません。クライアントが古いコアを同梱している場合、設定の一部や形式に対応していない可能性もあります。まず利用中のコアのバージョンとログを確認し、問題を再現できる最小の provider で試すと、複雑な本番ルールを壊さずに検証できます。検証用ファイルで成功してから本番の一覧へ変更を移す運用が安全です。

設定を GitHub に分離すると、ルールを直接編集するだけのクライアントでは差分管理や複数端末への再利用が難しく、更新のたびにプロファイル全体を複製する手間が生じることがあります。Clash の rule-providers なら、リストを用途ごとに分け、Git の履歴で変更を追いながら、設定側から同じ provider を参照できます。自作ルールを管理しやすい環境を整えたい場合は、利用端末に合う Clash クライアントをダウンロードページで確認してください。

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