はじめに
Clash のルールを増やしていくと、設定ファイルが長くなり、複数の端末で同じルールを使うのも難しくなります。そこで便利なのが、Mihomo の rule-providers です。ルール一覧を GitHub に置き、Clash の設定から参照する形にすれば、メインの YAML を何度も編集せずに、ルールをまとめて管理できます。
この記事では、GitHub にルールファイルを作成し、Mihomo から取得して適用するまでの手順を紹介します。設定例では、ドメインを列挙する「domain」形式と、複数種類のルールを記述する「classical」形式を取り上げます。更新間隔の指定、動作確認、よくあるエラーの切り分けもあわせて確認しましょう。
この記事でできること
自作ルールを GitHub で管理し、Mihomo に定期取得させて、複数の設定から再利用できるようにします。
事前に確認すること
ルールプロバイダーの利用には、対応する Mihomo コアが必要です。クライアントのコアが古い場合や、別の Clash 互換コアを使用している場合は、ここで紹介する設定項目が利用できないことがあります。最初にクライアントの設定画面でコアの種類とバージョンを確認してください。
1GitHub にルールファイルを作成する
まず GitHub でリポジトリを作成します。すでに公開用のリポジトリがある場合は、それを利用しても構いません。例えば clash-rules というリポジトリを用意し、その中に用途ごとのファイルを置きます。仕事用、広告対策用、特定サービス用などに分けておくと、あとから修正する場所が分かりやすくなります。
- GitHub で新しいリポジトリを作成します。Mihomo から認証なしで取得する場合は、リポジトリを Public にします。
- ルールファイルを追加します。YAML 形式のルールセットなら、例えば
rules/work.yamlのようなパスに保存します。 - 変更をコミットしたら、ブラウザーの通常のリポジトリ画面ではなく、Raw ファイルの URL を確認します。
- Raw URL をブラウザーで開き、ファイルの内容がそのまま表示されることを確認します。
GitHub の通常のファイルページ URL は HTML 画面を返すため、Mihomo の url にそのまま指定できません。公開ファイルでは、一般に https://raw.githubusercontent.com/ユーザー名/リポジトリ名/ブランチ名/パス の形を使います。ブランチ名とファイルのパスは、実際に作成したものに置き換えてください。
ドメイン一覧を使う場合
サブドメイン全体をまとめて扱いたい場合は、behavior: domain が便利です。ファイルは Mihomo が解釈できる YAML とし、ドメインを payload のリストに記述します。エントリーには通常、ドメイン名のみを書きます。
+.example.com は、対象ドメインとそのサブドメインを含める書き方です。特定のホストだけを対象にするなら、static.example.net のように記述します。引用符を付けておくと、YAML の記号として解釈される可能性を抑えられます。
複数のルール種類をまとめる場合
ドメインだけでなく、IP アドレス範囲やキーワードなどをまとめたい場合は、behavior: classical を使います。この形式では、リストの各項目に Clash のルール形式を記述します。対象のルールタイプに応じて、必要なパラメーターを正しく指定してください。
ルールの範囲に注意
実際に利用するサービスのドメインや IP 範囲を確認してから追加してください。広すぎるキーワードや IP 範囲を登録すると、意図しない通信まで同じポリシーに振り分けられることがあります。
2Mihomo の設定で参照する
ルールファイルを用意したら、メイン設定の rule-providers に取得方法を定義し、rules から参照します。次の例は、公開 GitHub リポジトリにあるドメイン形式のファイルを読み込み、指定したプロキシグループに適用する構成です。Work は実際の設定に存在するグループ名へ置き換えてください。
type: http は HTTP 経由で取得する指定です。behavior はルールファイルの内容に合わせて domain または classical を選び、YAML の payload を使う場合は format: yaml とします。path は取得したプロバイダーをローカルに保存する場所、interval は再取得の間隔を秒数で表します。例の 86400 は24時間です。
RULE-SET の行は、通常のルールと同じく上から順に評価されます。対象のルールセットより前に、それを受け止める広いルールを置かないようにしてください。また、指定した Work グループが proxy-groups に存在しない場合、設定の読み込みでエラーになるか、意図した振り分けができません。
classical 形式の設定例
GitHub 側のファイルが先ほどの classical 形式であれば、プロバイダー側の behavior も同じ形式に合わせます。ルール一覧を流用する場合も、ファイル側と設定側の形式を一致させることが重要です。
path はクライアントや実行環境によって、設定ファイルからの相対位置の扱いが異なる場合があります。Clash Verge Rev などの GUI クライアントでプロファイルを使っている場合は、プロファイルを読み込んだ状態でプロバイダーの保存先が書き込み可能か確認してください。設定を直接編集する前に、元のプロファイルを複製しておくと、誤記があったときに戻しやすくなります。
自動更新の意味
interval は、Mihomo が URL からルールファイルを再取得する間隔です。GitHub 上のファイル自体を自動編集する機能ではありません。GitHub に変更をコミットすると、次回取得時にその内容が反映されます。
3更新をテストしてエラーを切り分ける
設定を保存したら、まずクライアントでプロファイルを再読み込みし、Mihomo が設定を受け付けるか確認します。正常に読み込めた場合でも、ルールファイルを取得できているとは限りません。ルールプロバイダーの状態やログを開き、取得時刻、エラー内容、ルール数などを確認してください。クライアントにプロバイダーの更新操作がある場合は、初回テスト時に手動更新を実行します。
- Raw URL をブラウザーで開き、ログイン要求ではなくファイル内容が表示されることを確認します。
- YAML のインデント、キー名、引用符を確認します。インデントはスペースで揃え、タブ文字を使わないでください。
- クライアントの設定検証またはプロファイル再読み込みを行い、構文エラーがないことを確かめます。
- ルールプロバイダーを更新し、取得に成功した後、対象通信が期待したポリシーに一致するかを確認します。
- GitHub のルールを変更してコミットし、手動更新で新しい内容が取得されることを試します。
- 404 エラー： URL のユーザー名、リポジトリ名、ブランチ名、ファイルパスを確認します。GitHub の通常ページ URL を指定していないかも確認してください。
- 403 エラーや認証失敗： リポジトリが Private になっていないか確認します。認証情報を URL に埋め込む方法は、設定ファイルやログから漏れるおそれがあるため避けてください。
- 形式エラー：
behaviorとファイルの内容が一致しているか、YAML のpayloadが正しく記述されているかを見直します。 - 設定は読み込めるがルールが当たらない：
rulesの順序、プロバイダー名のスペル、指定したポリシー名を確認します。ルールに一致する通信かどうかもログで調べます。 - 変更が反映されない： 次の自動更新を待つか、クライアントからプロバイダーを手動更新します。ブラウザーで Raw URL を開き、コミット後の内容が公開されていることも確認します。
- 保存先のエラー：
pathの書き込み権限と、クライアントが利用する設定ディレクトリを確認します。相対パスの解釈が不明な場合は、まず既存プロファイルのルールセット保存先を参考にします。
継続して運用するための管理方法
ルールセットは、追加した理由と最終確認日を README などに記録しておくと、不要なルールを整理しやすくなります。変更時には一度に大量の項目を入れず、少量ずつ追加して動作を確認してください。GitHub のコミット履歴を使えば、問題が起きた変更を特定して以前の内容へ戻すこともできます。
複数の端末で共有する場合は、端末ごとに異なるルールをメイン設定へ重複して書かず、共通部分をプロバイダーにまとめます。一方、個人情報、社内限定のドメイン、認証トークン、利用者が特定できる情報は公開リポジトリに含めないでください。Private リポジトリを使う場合も、Mihomo が認証なしで取得できると決めつけず、アクセス方法と秘密情報の保管場所を慎重に検討しましょう。
GitHub 側のファイルを編集しただけでは、実行中のルールがその場で必ず切り替わるわけではありません。更新間隔、クライアントのプロファイル状態、Raw URL の公開状況を含めて確認することが、安定した運用のポイントです。まずは影響範囲の小さいルールセットから始め、ログで一致状況を確認しながら段階的に拡張してください。