Clashのカスタムルール設定ガイド｜ルールの種類・評価順序・スマホでの上書き方法

ルールモード・振り分け先・コアを確認する

Clashのカスタムルールは、接続をどのアウトバウンドに振り分けるかを指定するもので、プロキシノードを作成するものではありません。ルールに一致した接続は、組み込みのDIRECTやREJECT、または設定済みのノードやプロキシグループに振り分けられます。実際に使うアウトバウンドはプロキシグループが選択するため、「プロキシグループに一致した」からといって、必ずプロキシノード経由になるとは限りません。グループでDIRECTが選択されている場合もあります。

変更する前に、次の3点を確認してください。ルールが読み込まれるか、判定対象になるか、判定後にどこへ振り分けられるかが決まります。

動作モード：ルールモードに切り替えます。画面上では「ルール」またはRuleと表示されることがあります。グローバルモードやDIRECTモードでは、ここで説明する通常のルール一覧に沿った振り分けは行われません。
プロキシグループ名：設定のproxy-groupsで振り分け先のグループ名を確認します。大文字・小文字、空白、日本語を含め、名前は完全に一致させてください。名前が違うと、設定の読み込みに失敗することがあります。
コアの種類：クライアントがオリジナル版Clash、Clash Meta、mihomoのどれを使っているか確認します。Meta系は後にmihomoへ名称変更されていますが、新しいルールやルールセットの形式が旧コアでも使えるとは限りません。

よく使うルールの種類と基本構文

多くのルールは「ルールタイプ、マッチ条件、振り分け先」の形式で、各項目を半角カンマで区切ります。MATCHにはマッチ条件がなく、振り分け先を直接指定します。YAMLでは各ルールをリスト項目として記述し、インデントにはスペースを使います。タブを混ぜないでください。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,振り分け先
  - DOMAIN-KEYWORD,example,振り分け先
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,振り分け先

このコードは構文を示す例であり、単体で動作する完全なサブスクリプションではありません。既存の設定に追加する場合は、トップレベルのrulesフィールドを1つだけ残し、各ルールが実際の要件に合っているか確認してください。

タイプ	マッチ条件	ポイント
`DOMAIN`	完全一致のドメイン	`example.com`は`www.example.com`には一致しません。
`DOMAIN-SUFFIX`	ドメインとそのサブドメイン	`example.com`を指定します。`*.`を付ける必要はありません。
`DOMAIN-KEYWORD`	ドメインに含まれるキーワード	サフィックス一致より対象範囲が広く、関係のないドメインまで一致することがあります。
`IP-CIDR` / `IP-CIDR6`	接続先のIPv4 / IPv6ネットワーク	接続先のアドレスが対象です。スマホが接続しているWi-Fiのネットワークではありません。
`GEOIP`	接続先IPの地理データベース上の分類	使用するデータベースによって結果が異なります。サイトの言語や企業の登記所在地と同じ意味ではありません。
`RULE-SET`	ルールプロバイダー内の項目	名前は`rule-providers`で定義したものと一致させてください。
`MATCH`	それまでのルールに一致しなかったすべての接続	通常は一覧の末尾に置き、フォールバックとして使います。

ドメインルールにURL全体は指定しない

https://www.example.com/accountに一致させるには、ドメインwww.example.comを指定します。DOMAINにhttps://、パス、クエリパラメーターを含めないでください。通常のドメインルールはURLパスのフィルターではなく、同じHTTPSドメイン内のページを区別することもできません。

DOMAIN-SUFFIX,example.com,DIRECTはルートドメインとサブドメインに一致しますが、notexample.comは対象になりません。ログイン用の接続だけを処理する場合は、完全一致のドメインを使い、ドメイン全体に広くDIRECTやREJECTを設定しないようにしましょう。

IPルールとno-resolveの違い

接続にドメイン名が含まれていて、判定に使える実際の接続先IPがない場合、IP系ルールによってDNS解決が行われることがあります。末尾のno-resolveは、このルールのためだけにドメインを解決しない指定です。利用可能な接続先IPがすでにあれば、引き続きマッチ判定が行われます。DNS全体を無効にする設定でも、「このルールを常に有効にする」指定でもありません。

そのため、GEOIP,CN,DIRECT,no-resolveは、no-resolveを付けない場合と同じドメイン接続でも結果が異なることがあります。中国国内のドメインがIPルールに一致しない場合は、ノードを何度も変更するのではなく、ログに記録されたドメイン、接続先IP、DNSの動作を確認してください。

マッチ判定の順序：最初に一致したルールが有効、具体的なルールを先に

この記事で紹介する通常のルールは、一覧の上から順に判定され、最初に一致したルールの振り分け先が選ばれます。より「具体的」なルールを探して下まで判定することはありません。ルールタイプ自体に自動的な優先順位はなく、後に書いたDOMAINが前のDOMAIN-SUFFIXより優先されることもありません。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,振り分け先
  - MATCH,振り分け先

login.example.comは1つ目のルールに一致し、DIRECTに振り分けられます。
www.example.comは1つ目に一致せず、2つ目のルールに一致します。
example.netは最初の2つに一致せず、3つ目のルールがフォールバックとして適用されます。

最初の2つのルールを入れ替えると、ログイン用ドメインが先にサフィックスルールに一致し、後ろにある完全一致のDIRECTルールは適用されません。「Clashのカスタムルールを追加したのに効かない」ときは、追加したルールだけでなく、その上に広い範囲に一致するルールがないか確認してください。

MATCHを最後に置く理由

MATCHは、それまでのルールに一致しなかったすべての接続を処理します。その後ろにある通常のルールは実行されません。「明確な例外 → サービスや用途別のルールセット → 地域別の一般ルール → MATCH」の順に整理すると管理しやすくなります。必要に応じて調整してください。これは保守しやすくするための整理方法であり、コアが強制する分類順ではありません。

RULE-SET：プロバイダーと参照位置をあわせて確認

RULE-SETは、複数のマッチ条件を独立したファイルにまとめ、メインのルール一覧から参照する仕組みです。一覧の順序を無視することはありません。参照を記述した行で、そのルールセットが判定されます。プロバイダー名、動作タイプ、ファイル形式、ファイルの内容が互いに対応している必要があります。

以下はmihomoでローカルファイルを使う例です。まず、コアからアクセスできる設定ディレクトリに./rules/local-direct.yamlを用意し、次にプロバイダー定義を追加します。スマホでそのディレクトリに書き込めるかはクライアントによります。ファイルをシステムの「ダウンロード」フォルダーに置いただけで、コアから読み込めるとは限りません。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,振り分け先

対応するルールファイルの内容は次のとおりです。classicalの項目にはルールタイプを記述し、振り分け先は指定しません。振り分け先はメイン設定のRULE-SET,local-direct,DIRECTでまとめて指定します。

payload:
  - DOMAIN,example.com
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve

behavior: domain：ドメインの集合に使います。各項目は対応するドメイン集合の構文に従って記述し、上記のclassical形式をそのまま貼り付けないでください。
behavior: ipcidr：IPネットワークの集合に使います。ドメインルールを混在させる用途ではありません。
behavior: classical：ルールタイプを含む項目に使います。この記事のようにドメイン条件とIP条件を混在させる例に適しています。

リモートプロバイダーでは、ダウンロードURL、キャッシュ先、更新間隔も設定する必要があります。サブスクリプションの更新とルールプロバイダーの更新は別の処理です。メインのサブスクリプションを更新できても、外部ルールファイルがすべて更新されたとは限りません。スマホで例外ルールを2〜3個追加するだけなら、プロバイダーを新設するより通常のルールを直接記述したほうが原因を特定しやすくなります。

スマホでサブスクリプションを上書きする：リモートの設定を残し、ローカルルールを分けて管理

リモートサブスクリプションは設定の取得元で、クライアントの上書き機能は読み込み時に設定をローカルで変更する仕組みです。サブスクリプションから生成されたYAMLを直接編集すると、次回更新時に変更が消えることがあります。元のサブスクリプションはそのまま残し、クライアントの設定上書き、ルール管理、拡張設定などの機能を使ってローカルルールを保存する方法がおすすめです。

Androidクライアントでの操作手順

現在使っている設定の詳細を開き、どのサブスクリプションが実行中か確認します。別の設定を編集したまま、別の設定でテストしないようにしてください。
クライアントのルール管理または上書き機能を探し、「ルールの先頭に追加」「一覧をマージ」「全体を置き換え」のどれに対応しているか確認します。Androidクライアントによってメニュー名は異なります。
まず、DOMAIN,example.com,DIRECTのような完全一致ルールを1つ追加します。DNS、TUN、十数個のルールを同時に変更しないでください。
保存して設定を再読み込みし、未定義のポリシー、YAMLの解析エラー、ルールプロバイダーの読み込みエラーがないか確認します。
元のサブスクリプションを1回更新し、ローカルルールが最終的なルール一覧の前方に残っているか確認します。一度保存できても、サブスクリプション更新後も維持されるとは限りません。

「YAMLをマージ」する欄がある場合は、配列の扱いに関する説明を先に確認してください。rulesは配列です。マージ機能によって、配列全体を置き換えるものもあれば、先頭への追加や末尾への追加に対応するものもあります。ルールが1つだけのrules:ブロックをそのまま貼り付けると、サブスクリプションに含まれるルール一式が置き換わることがあります。上書き形式はクライアントの機能によって異なり、すべてのスマホで使える共通の「先頭追加」フィールドはありません。

iOSクライアントでは、ルールの移行前に設定形式を確認

iOS向けのプロキシクライアントは、設定構文、モジュール、ローカルルールの仕組みがそれぞれ異なります。サブスクリプションに対応しているからといって、Clash YAMLをそのまま実行できるとは限りません。まずクライアントが明示的に対応している形式を確認してください。別のルール構文を使う場合は、rules:ブロック全体を貼り付けず、そのクライアント専用のルール設定から条件を追加します。

システムのVPN権限はクライアントが通信を処理するためのもので、Clashルールを別の設定形式に変換する機能ではありません。インストール方法を選ぶ際は、まずスマホクライアントの選び方ガイドを確認し、選んだクライアントの設定形式と上書き機能を確認してください。

ルールが効かないときの確認方法：ページの表示だけでなく接続ログを見る

ページが開くかどうかは、DNS、ノードの状態、サーバーの状態、既存の接続など複数の要因に左右されます。ルールを検証するときは、クライアントの接続一覧やログで、接続先ドメイン、適用されたルール、プロキシグループ、最終的なアウトバウンドを確認してください。ページの表示が速くなった、または遅くなっただけでは、特定のルールが適用された証拠になりません。

症状	まず確認する項目	対処方法
設定を保存した後に読み込めない	インデント、半角カンマ、プロキシグループ名	最後に加えた変更を戻し、ルールを1つずつ確認します。
ルールはあるのに一致しない	動作モード、上位の広範囲ルール、MATCHの位置	ルールモードに切り替え、テスト用ルールを適切な前方の位置に移動します。
プロキシグループに一致したのにDIRECTになる	プロキシグループの現在の選択先とネストされたグループ	プロキシグループをたどり、最終的にDIRECTが選ばれていないか確認します。
ドメインルールに一致しない	接続ログにドメイン名が記録されているか	ブラウザーのアドレスバーだけで判断せず、DNSと通信の取り込み方法を確認します。
サブスクリプション更新後にルールが消える	編集したのが元ファイルか、独立した上書き設定か	クライアントが対応する永続的な上書き機能に移し、更新後も保持されるかテストします。

TUN / VPNによる通信の取り込みとルール判定は別の処理

TUNやシステムVPNを有効にしても、通信を取り込める状態になるだけで、すべてのアプリの通信がコアに届くとは限りません。Androidのアプリ別設定、除外アプリ一覧、クライアントのルーティング設定によって、特定のアプリが通信を迂回することがあります。コアに届かない接続は、設定内のルールにも一致しません。

もう一つよくある問題は、コアがIPアドレスしか認識できず、ドメイン名を取得できないことです。アプリ独自の暗号化DNS、IPアドレスへの直接接続、DNSの取り込み設定の違いなどが、ドメイン情報に影響します。mihomoのドメインスニッフィングは対応するプロトコルで識別を補助できますが、すべての暗号化通信を識別できるわけではありません。まず現在のDNS設定を理解したうえで、関連機能を有効にするか判断してください。概念の確認にはDNS技術リファレンスも参考になります。

一度に変更するのは1項目だけにし、新しい接続で確認

ルールを変更しても、既存の接続は接続開始時のアウトバウンドを使い続けることがあります。保存して再読み込みしたら、対象アプリの既存接続を閉じるか、アプリを再起動して、新しい接続のログを確認してください。「完全一致ルールを1つ追加 → 一致を確認 → サブスクリプションを更新 → 再度確認」の順にテストするのがおすすめです。異常が起きた場合は、アプリのデータをすぐ消去するのではなく、直前の正常な設定に戻してください。