ホーム ブログ ルーティングルール実践
ルール設定

Clash ルーティングルール実践：ゼロから使いやすい rules 設定を書く

サブスクリプション付属のルールは大まかすぎるか、気になる App をそもそもカバーしていないことがあります。本記事ではマッチ順序から解説し、よく使うルールタイプの書き方を紹介した上で、ルールセットを使ってメンテナンスの手間を最小限に抑える方法を説明します。

2026年7月10日 読了時間約9分 難易度：上級

なぜサブスクリプション付属のルールでは足りないのか

多くのサブスクリプションには、国内直接接続・海外プロキシ・広告ブロックといった一般的なシーンをカバーするルーティングルールが付属しており、日常使用ではほぼ十分です。しかし要件が少し特殊になると——たとえば特定の国内 App だけプロキシを通したい、あるゲームクライアントは必ず直接接続にしたい、広告ドメインを自分で追加したいなど——サブスクリプション付属のルールは通常編集できません（サブスクリプションを更新すると上書きされてしまいます）。こうした場合は、設定に自分で rules を追加する必要があります。

多くのクライアントはサブスクリプションのルールとカスタムルールを分けて管理できます（例えば Clash Verge の「オーバーライド」/「マージ」機能）。カスタムルールをオーバーライドファイルに書いておけば、サブスクリプションを更新してもルールが上書きされることはありません。具体的な操作はクライアントのドキュメントを参照してください。本記事ではルール自体の書き方のみを解説します。

まずマッチ順序を理解してからルールを書く

rules は配列で、Clash は上から下の順に1件ずつマッチングを行い、最初にマッチしたルールの出口をすぐに使用します。以降のルールは確認されません。つまりルールは順序の方が内容そのものよりミスしやすいということです——広範なルールを前に書いてしまうと、後ろにあるより精密なルールが永遠に適用されなくなります。

config.yaml YAML
rules:
  # 上から下へマッチし、1件ヒットしたら停止
  - DOMAIN-SUFFIX,ad.com,REJECT
  - DOMAIN-SUFFIX,google.com,プロキシ
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ          # フォールバック、必ず最後に置く

よくある落とし穴：GEOIP,CN,DIRECT（国内直接接続）を広告ブロックルールより前に書いてしまうこと。広告ドメインが解決された IP がたまたま国内であれば、「ブロック」より先に「国内直接接続」がマッチしてしまい、広告ルールが無意味になります。ルールを書くときは常に次を意識してください：より具体的で優先的に適用したいルールほど、前に置く。

よく使うルールタイプの実践

ルールタイプは数十種類ありますが、日常的に使うのは実質以下の数種類だけです。使用頻度順に紹介します：

  • ドメイン系：DOMAIN-SUFFIX / DOMAIN-KEYWORD / DOMAINDOMAIN-SUFFIX,google.com は google.com とそのすべてのサブドメインにマッチする、最も一般的な書き方です。DOMAIN-KEYWORD はドメインに特定のキーワードが含まれているかをマッチし、「このキーワードを含んでいればブロック/プロキシする」場面に適していますが、誤爆に注意が必要です。DOMAIN は完全一致のドメインのみにマッチし、最も精密ですが使用頻度も一番低いです。
  • GEOSITE：ドメインをカテゴリ別にまとめるGEOSITE,youtube,プロキシ は YouTube 関連のドメインをまとめて一括でマッチさせるため、1つずつ書く必要がありません。ルールセットのコミュニティはほぼすべての主要サイト/App のドメイン分類をすでに整理済みで、手書きの DOMAIN-SUFFIX よりずっと手間が省けます。
  • GEOIP：IP の所属国・地域による判定GEOIP,CN,DIRECT はほぼすべての設定ファイルに標準搭載されているフォールバックルールの一つです——国内 IP に解決されたリクエストはすべて直接接続とし、プロキシの帯域を消費しません。
  • IP-CIDR：IP 帯による正確なマッチ内部ネットワークのアドレス帯（例：192.168.0.0/16）や CDN の固定 IP 帯などの場面に適しています。no-resolve パラメータを併用すると不要な DNS 解決を1回スキップでき、マッチ速度が上がります。
サンプルコード YAML
rules:
  # 内部ネットワークは直接接続、no-resolve で DNS 解決をスキップ
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # ドメインカテゴリで一括マッチ
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,netflix,プロキシ
  # フォールバック：国内 IP は直接接続、それ以外はプロキシ
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ

ルールが多すぎる・長すぎる？RULE-SET でルールセットを読み込む

ブロックしたい広告ドメインが数百件ある場合、それらを直接 rules 配列に書くと設定ファイルが極端に肥大化し、再利用もできません。こうした場合は rule-providers（ルールプロバイダー）を使い、大量のルールを別のファイル/サブスクリプションリンクにまとめ、設定側では RULE-SET の1行で参照するだけにします。

config.yaml YAML
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject-list.txt"
    path: ./rule_providers/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ
  • behavior はルールセットファイルの内容形式を決定します：domain（ドメインリスト）、ipcidr（IP 帯リスト）、classical（完全なルール、ほぼすべてのタイプに対応）。この3つは書き方がそれぞれ異なります。
  • interval によりルールセットはサブスクリプションと同様に定期的に自動更新され、広告ドメインリストが更新されても設定を手動で変更する必要がありません。
  • コミュニティが管理している一般的なルールセット（広告ブロックリストや一般的なストリーミングサービスのドメインリストなど）は基本的にそのまま利用でき、ゼロから自分で整理する必要はありません。

ルールセットの内容自体の詳しい形式（3種類の behavior それぞれの書き方）については、ドキュメントの《ルールセットの内容》を参照してください。ここでは重複した説明は省略します。

実践：「広告ブロック＋国内直接接続＋特定 App プロキシ」設定を構築する

これまで紹介した数種類のルールタイプを組み合わせれば、多くの人の日常的なニーズを満たす設定の骨格を構築できます：

config.yaml YAML
rules:
  # 1. LAN / 内部ネットワークのアドレス、直接接続、解決をスキップ
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 2. 広告ブロック、ルールセット、優先度最高
  - RULE-SET,reject,REJECT

  # 3. 特定の App/サイト、必ずプロキシを通す（国内ルールより前に書く！）
  - PROCESS-NAME,SomeApp.exe,プロキシ
  - GEOSITE,netflix,プロキシ
  - GEOSITE,youtube,プロキシ

  # 4. 国内のドメイン/IP、直接接続
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 5. フォールバック：残りはすべてプロキシ
  - MATCH,プロキシ

ステップ3（指定した App/サイトをプロキシにする）は、ステップ4（国内直接接続）の前に置く必要があります。順序が逆になると、これらのドメインが解決した IP が国内の IP 帯に該当する場合、ステップ4の GEOIP,CN,DIRECT に先に捕まってしまい、プロキシルールが永遠に適用されません。

よくある質問

ルールを変更したらクライアントを再起動する必要がありますか？

多くのクライアントは設定のホットリロードに対応しています（通常「設定を再読み込み」や「Reload」と表示されます）。保存後にクリックするだけで反映され、クライアント全体を再起動する必要はありません。変更が反映されない場合は、編集したファイルが間違っていないか確認してください（サブスクリプションのルールとオーバーライドのルールは別々に管理されています）。

ルールが多い場合、プロキシの速度が落ちませんか？

ルールのマッチング自体は純粋なメモリ操作で、数百件のルールのマッチにかかる時間は通常マイクロ秒単位であり、遅延として感じることはありません。実際に体感速度に影響するのは DNS 解決やノード自体のネットワーク品質であり、ルールの数ではありません。

追加した IP-CIDR ルールが効かないのはなぜですか？

最も多い原因は順序の問題です——前に、より広範なルール（例えば MATCH や範囲の広い GEOIP）が先にマッチしてしまっています。コントロールパネルの「ルール」ページで対象の IP/ドメインを検索し、実際にどのルールにマッチしているかを確認すれば、通常はすぐに問題を特定できます。

さらに詳しく

学び終えたら、Clash をインストールして試してみましょう

全プラットフォームのインストーラーを1か所で入手できます。おすすめタグに沿って選べば間違いなく、数分で使い始められます。

ダウンロードページへ
#ルール設定 #RULE-SET #ルーティング実践
ブログ一覧に戻る

こちらもおすすめ

Clash クライアントをダウンロード全プラットフォーム対応、今すぐ開始