この記事で分かること

Clash のルールを複数の端末で共有したいときや、独自の分流ルールを継続的に手入れしたいときは、ルール本体をプロファイルへ直接書き込むのではなく、GitHub 上のファイルとして管理する方法が便利です。Mihomo 系コアでは rule-providers にルールファイルの URL と取得方法を登録し、rules からプロバイダー名を参照できます。ルールを更新して GitHub に反映すれば、対応するクライアントが次回の更新時に新しい内容を取得できます。

本稿では、GitHub リポジトリの準備、ルールファイルの書式、behavior・format・interval などの設定項目、ルールの適用順、更新エラーの調べ方を順に説明します。設定例は Mihomo 系コアを前提にしています。Clash の派生クライアントは、同じ YAML を読み込めても搭載コアの機能やバージョンによって動作が異なることがあります。設定前に、使用中のクライアントが rule-providers に対応しているか確認してください。

GitHub にルールファイルを用意する

まず、GitHub にルール専用のリポジトリ、または既存リポジトリ内の専用ディレクトリを用意します。ファイルを用途ごとに分けると、更新内容を把握しやすくなります。たとえば、広告関連、社内サービス、特定アプリ向けなど、変更の理由が異なるルールを別ファイルにすると、誤編集したときの影響範囲も小さくできます。ファイル名は rules.yaml のように用途が伝わるものにし、運用を始めたあとで頻繁に変更しないようにします。

ルールファイルの例は次のとおりです。これはルールプロバイダーでよく使われる classical 形式で、ドメインだけでなく IP 範囲やプロセス名など複数のルールタイプを記述できます。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,api.example.net
  - DOMAIN-KEYWORD,media
  - IP-CIDR,192.0.2.0/24,no-resolve

payload: の下には、Clash が解釈できるルールを一行ずつ並べます。ドメイン全体を対象にする場合は DOMAIN-SUFFIX、特定のホストだけなら DOMAIN、IP 範囲なら IP-CIDR のように、対象に合うタイプを選びます。DOMAIN-KEYWORD は名前に指定した文字列を含むドメイン全体へ作用するため、意図しないサービスまで一致しないか慎重に確認してください。必要以上に広い条件を使うと、正常なサイトまで同じポリシーへ送られることがあります。

GitHub の公開リポジトリでファイルを開き、「Raw」表示からファイルの URL を確認します。通常のファイル閲覧ページの URL ではなく、ファイル本文を返す Raw URL を url に指定してください。ブランチ名やディレクトリを変更すると URL が変わるため、運用開始後にファイルを移動する場合は Clash 側の設定も更新します。公開リポジトリは誰でも取得できますが、非公開リポジトリの Raw URL には認証が必要です。トークンを YAML や公開リポジトリに書く方法は避け、非公開ファイルを配信する場合は、利用するクライアントが安全な認証方法に対応しているかを別途確認してください。

TIP：公開リポジトリには、個人情報、社内限定のホスト名、認証情報を含めないでください。ルールの変更履歴を残したい場合は、編集前に GitHub の差分を確認し、変更理由をコミットメッセージに記録しておくと、問題発生時に戻しやすくなります。

rule-providers を設定する

Clash のメイン設定では、rule-providers に取得元と形式を登録し、その後 rules から名前を参照します。以下は基本的な設定例です。proxy は利用中のプロキシグループ名に置き換えてください。

rule-providers:
  my-github-rules:
    type: http
    behavior: classical
    format: yaml
    url: "https://raw.githubusercontent.com/USER/REPO/main/rules.yaml"
    path: ./ruleset/my-github-rules.yaml
    interval: 86400

rules:
  - RULE-SET,my-github-rules,proxy
  - MATCH,DIRECT

ここでの type: http は HTTP または HTTPS の URL から取得する設定です。behavior はルールの意味と構造を示し、例の classical は DOMAIN や IP-CIDR など複数種類を含む形式に使います。ドメイン名だけのリストを扱う場合は、内容に合った domain 形式を選び、ルールファイルの構造もその形式に合わせます。プロバイダーの形式と実際のファイル内容が一致しないと、取得自体は成功しても解析で失敗することがあります。

format: yaml は YAML 形式のルールファイルを指定します。コアや設定方式によって対応する形式が異なる場合があるため、古いクライアントを含む環境では対応状況を確認してください。url は GitHub の Raw URL、path は取得したファイルをローカルに保存する場所です。相対パスを使う場合、その基準となる設定ディレクトリはクライアントによって異なることがあります。複数のプロファイルで共有する場合は、保存先が衝突しないようプロバイダーごとに異なるファイル名を付けます。

interval: 86400 は更新確認の間隔を秒で表し、この例では 24 時間です。短く設定すれば変更が反映されるまでの待ち時間は減りますが、GitHub へのアクセス頻度が上がります。ファイルの更新が少ないなら、数時間から 1 日程度の間隔で十分なケースが多いでしょう。なお、間隔は必ずしも「指定時刻に更新される」という意味ではありません。アプリの起動状態、コアの実装、ネットワーク状況などによって取得タイミングが前後するため、急ぎの変更はクライアント側から手動更新できるか確認します。

rules 内の RULE-SET,my-github-rules,proxy は、登録したプロバイダーに一致した通信を proxy グループへ送る指定です。グループ名は設定内に存在する名前と完全に一致させてください。存在しない名前やタイプミスがあると、設定の読み込みでエラーになるか、意図した経路になりません。

ルールの順序と端末間共有を確認する

Clash のルールは上から順に評価され、最初に一致したルールが使われます。そのため、プロバイダーを登録しただけでは動作せず、RULE-SET の位置も重要です。独自ルールより前に広い MATCH,DIRECT や大きな範囲に一致するルールがあると、独自ルールへ到達する前に通信が処理されます。通常は、対象を限定した個別ルール、独自ルールセット、一般的なルール、最後に MATCH の順で並べ、既存設定の順序と照らし合わせてください。

変更時は一度に多くのルールを追加せず、まず一つのテスト用ドメインを登録して、接続ログや現在の接続一覧に想定したルール名とポリシーが表示されるか確認します。ブラウザのキャッシュや既存の接続が残っていると、変更後も古い経路に見えることがあります。確認対象のアプリを再起動するか、新しい接続を発生させてからログを見ます。ドメインルールと IP ルールのどちらに一致したのかも確認し、想定外のルールが先に処理していないかを切り分けます。

端末間で設定を共有するときは、GitHub のルールファイルだけでなく、各端末のコアが同じルール形式をサポートしているかも揃える必要があります。Windows の Clash Verge Rev では読み込めても、古いモバイルクライアントでは format や特定のルールタイプに対応せず、同じプロファイルがエラーになる場合があります。全端末で同一の設定を使う前に、代表的な端末でプロファイルを検証し、問題がなければ他の端末へ展開する方法が安全です。

GitHub に公開したルールは、プロファイルを更新するたびに取得される可能性があります。作業中の不完全な変更がそのまま配信されないよう、構文と差分を確認してから確定してください。ルールの追加・削除を記録しておけば、特定のサイトが突然 DIRECT になった、またはプロキシ経由になった場合に、変更履歴から原因を探せます。端末ごとに違うファイルを参照していると、同じ設定に見えても結果が揃わないため、URL、ブランチ、ファイル名を端末間で照合することも大切です。

更新エラーとルール不一致を調べる

更新されない場合は、まず Clash のログでプロバイダー名とエラー内容を確認します。HTTP エラーなら URL の誤り、ファイル移動、ブランチ名の変更、GitHub 側の応答制限などが候補です。ブラウザで Raw URL を開き、YAML の本文が表示されるか確認すると、通常の GitHub 閲覧ページを指定していないか、公開設定が意図どおりかを切り分けられます。ログに DNS エラーやタイムアウトがあるなら、ルール内容より先に、Clash 自体が GitHub へ接続できるかを確認してください。

取得は成功しているのにルールが反映されない場合は、次の点を順に見直します。

  • プロバイダー名：rule-providers のキーと RULE-SET の名前が同じか確認します。大文字・小文字やハイフンの違いも見落としやすい箇所です。
  • ファイル形式：behavior と format がファイルの内容に合っているか、先頭の payload: やインデントが正しいかを確認します。
  • ルール順：より上にあるルールが先に一致していないか、特に広いドメイン条件や MATCH が独自ルールより前にないか調べます。
  • 取得先：Raw URL が最新のブランチとファイルを指しているか確認します。GitHub 上でファイルを移動した場合は古い URL が残っていないか確認してください。
  • コアの互換性：クライアントのバージョンと搭載コアを確認し、同じ設定が別端末でも認識されるか小規模にテストします。

エラーを直した後は、設定全体を再読み込みし、プロバイダーの更新時刻と接続ログの両方を確認します。設定の構文エラー、URL からの取得失敗、ルールのマッチ順は別々の問題です。たとえば YAML の読み込みに成功しても、対象ホスト名がリストに存在しなければ一致しません。逆にルールが一致しているのに接続できない場合は、選択したプロキシグループやノード側を調べる必要があります。問題が再現する条件、対象ドメイン、ログの時刻を記録しておくと、ルール更新とネットワーク障害を混同しにくくなります。

ルールを手作業でプロファイルへ貼り付ける方法は、少数の端末では手軽ですが、更新のたびに各端末を編集する必要があり、端末ごとの設定差も生まれやすくなります。GitHub 管理なら変更履歴を追え、複数端末で同じルールを取得できるため、分流ルールを継続運用する際の確認と共有がしやすくなります。利用するコアの互換性を確かめながら運用したい方は、各プラットフォーム向けの Clash クライアントも確認してみてください。

Clash をダウンロード →