rule-providers を使う理由：ルール本体と設定を分けて管理する

Clash の rules にドメインや IP の判定をすべて直接書くと、例外を追加するたびに設定ファイルが長くなり、更新履歴も追いにくくなります。とくに複数の端末で同じ判定リストを使う場合、各端末の YAML を個別に編集する運用では、端末ごとに内容がずれたり、購読更新で手作業の変更が消えたりしがちです。rule-providers は、ルール一覧を本体の設定から分離し、URL などで取得したリストを名前付きのプロバイダーとして参照する仕組みです。接続先を選ぶための通常の proxy-providers とは役割が異なり、rule-providers が配布するのは通信先を分類するルールです。

GitHub にルールファイルを置けば、変更をコミット単位で記録でき、差分を見ながら追加・削除の理由を確認できます。メインの Clash 設定はプロバイダー名とポリシーの対応だけを持ち、細かなドメイン一覧はリポジトリ側で管理する形にできます。ただし、GitHub に置けば内容が自動的に正しくなるわけではありません。ルールの書式、更新時の取得可否、対象アプリのコアが使う構文を別々に確認する必要があります。以下の例は Mihomo 系コアを想定した出発点です。利用中のクライアントが別のコアや古いバージョンを使っている場合は、対応する設定項目をそのコアの仕様で確認してください。

ℹ 設計の基本：GitHub 側には「どの通信先を同じ種類として扱うか」を置き、Clash 側の rules には「その集合をどのポリシーへ送るか」を置きます。分類と出口を分けておくと、リストだけを更新してもポリシー全体の意味を見失いにくくなります。

GitHub にルールファイルを作り、raw URL を登録する

まず GitHub のリポジトリに、用途が分かる名前の YAML ファイルを作成します。公開リポジトリで管理するなら、ファイルの閲覧画面の URL ではなく、Clash から直接取得できる raw コンテンツの URLを使います。たとえば https://raw.githubusercontent.com/OWNER/REPOSITORY/main/rules/private-domain.yaml のような形式です。OWNER と REPOSITORY は実際のアカウント名とリポジトリ名に、ブランチ名とパスは自分の配置に合わせて置き換えてください。GitHub の通常のファイル表示ページを URL に指定すると、YAML そのものではなく HTML が返り、読み込みに失敗する原因になります。

プロバイダーの behavior は、ファイルの中身に合わせて選びます。ドメインだけを列挙するなら domain、IP CIDR のみなら ipcidr、DOMAIN-SUFFIX などの Clash ルール形式を混在させるなら classical が基本です。形式を混ぜたまま誤った behavior を指定すると、URL 自体は取得できてもルールとして解釈されないことがあります。利用する形式を決めてからファイルを作り、別形式の行を同じリストへ無造作に追加しないでください。

Mihomo の設定例 — URL、保存先、ポリシー名は環境に合わせて変更

rule-providers:
  custom-sites:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/custom-sites.yaml
    url: "https://raw.githubusercontent.com/OWNER/REPOSITORY/main/rules/custom-sites.yaml"
    interval: 86400

rules:
  - RULE-SET,custom-sites,PROXY
  - MATCH,DIRECT

ここでは、GitHub 上の custom-sites.yaml の内容を次のようにします。classical のリストでは、各行にルールタイプと対象を記述します。最後のポリシー名は配布ファイル側ではなく、親設定の RULE-SET 行で指定するのがポイントです。そのため、同じリストを別の設定で使う場合も、利用者ごとに出口だけを選び直せます。 

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,api.example.net
  - DOMAIN-KEYWORD,media

format: yaml を使う場合、ルールファイルは YAML として読み取れる形にし、上の例のように payload の配下にリストを置きます。インデントはスペースで揃え、タブ文字を混ぜないようにします。リポジトリ内でファイルを保存したら、raw URL をブラウザーで開き、YAML の内容だけが表示されることも確認してください。リンク先が 404 になる、認証画面へ転送される、または HTML が返る状態では、Clash 側の設定を直しても取得できません。

更新間隔とルールの優先順位を整える

interval はプロバイダーの更新を試みる間隔を秒単位で指定します。例の 86400 は 24 時間です。短くすれば常に最新になるように見えますが、GitHub やネットワークへの問い合わせが増えるうえ、短時間に何度も取得しても内容が変わるとは限りません。個人用の小さなリストなら一日程度から始め、変更頻度や配信環境に応じて調整するのが実用的です。重要な修正をすぐ反映したい場合は、クライアントにプロバイダーの手動更新機能があればそれを使い、定期更新を待つ場合と区別して確認してください。

path は取得したファイルをコアが保存する場所です。相対パスの基準や書き込み可能な領域はクライアントごとに異なるため、設定ファイルを編集できても保存先に書き込めないケースがあります。アプリのデータ領域を使う構成では、その領域を不用意に削除するとキャッシュが消え、ネットワーク接続中に再取得できない場合があります。初回に読み込んだ後、クライアントを再起動してもプロバイダーの状態が保たれるかを確認し、必要ならバックアップ対象に含めてください。

取得に成功しても、ルールの順番が不適切なら意図した振り分けにはなりません。Clash は通常、上から順に評価し、最初に一致したルールで処理を決めます。対象ドメインをより広い既存ルールが先に拾っていたり、GEOIP や別の RULE-SET が先に一致していたりすると、自作セットまで到達しません。自作の RULE-SET は、その対象を先に判定したい既存ルールより前に置きます。一方で、最後に置く MATCH は残りすべてを受けるため、必ず具体的なルール群より後ろに置いてください。

リストの範囲も意識しましょう。たとえば DOMAIN-KEYWORD,media は、意図したサービス以外のホスト名にも一致する可能性があり、対象を広げすぎると別サイトまで同じポリシーへ送られます。最初は DOMAIN や DOMAIN-SUFFIX のように範囲が読み取りやすい条件を優先し、ログで確認した実際のホストだけを追加します。上流サービスの構成変更で使われなくなったドメインを残し続けると、後からルールの意図が不明になります。追加日や判断理由を GitHub のコミットメッセージに残すと、定期的な見直しもしやすくなります。

⚠ GitHub の認証情報に注意：公開リポジトリのファイルにアクセストークン、購読 URL、個人情報を含めないでください。非公開リポジトリを使う場合も、認証情報を YAML に直書きして公開したり、ログやスクリーンショットに含めたりしないことが重要です。クライアントが非公開 URL の認証に対応しているとは限らないため、導入前にコアと取得方式の仕様を確認してください。

読み込みエラーと誤振り分けを切り分ける

プロバイダーが一覧に現れない場合は、まず設定ファイル全体の YAML 構文を検証します。コロンの後の空白、階層ごとのインデント、引用符の対応を確認し、rule-providers と rules がトップレベルの同じ階層にあるかを見ます。次に、プロバイダー名が RULE-SET の名前と完全に一致しているか、URL が raw ファイルを指しているか、ファイルの behavior と内容が対応しているかを確認します。名前の大文字・小文字やハイフンの違いも、意図しない参照エラーにつながります。

更新エラーでは、クライアントのログに表示された HTTP 状態や取得先を手掛かりにします。404 ならブランチ名やファイルパス、403 なら公開範囲やアクセス制御、タイムアウトなら接続経路や DNS を順に確認します。raw URL をブラウザーで開いて成功しても、Clash のコアが使うネットワーク経路で取得できるとは限りません。コアのログと接続一覧を同じ時間帯で見比べ、GitHub への接続自体が失敗したのか、取得後の YAML 解釈で失敗したのかを分けると、むやみに設定全体を書き換えずに済みます。

誤った振り分けは、Clash の接続ログから対象のホスト名、適用されたルール、選択されたポリシーを一組として確認します。意図した RULE-SET が記録されていなければ、プロバイダーが読み込まれていない、対象行が一致していない、または上位のルールが先に一致した可能性があります。自作セットが適用されているのに通信結果が期待と違うなら、ポリシーグループの選択やノード状態を別に調べます。ルールの一致と、その先の接続品質を同じ問題として扱わないことが切り分けの近道です。

運用では、最初に小さなリストを作り、ひとつのテスト用ドメインで取得・一致・ポリシー選択の順に確認します。正常に動いた後で用途ごとにファイルを分け、GitHub のコミット差分をレビューしてから変更を反映すると安全です。巨大な第三者ルールセットは手軽な一方、どの行が追加され、何に一致するのか追跡しにくいことがあります。Clash V.CORE を使えば、設定編集や接続ログの確認をひとつの作業環境で進めやすく、GitHub 管理の小さなルールセットとも組み合わせられます。クライアントごとに画面やコアの対応状況を確認しながら運用したい方は、Clash V.CORE のダウンロードページから利用環境に合う版を確認してください。