広告をブロックしたいだけなのに、rulesに何百行もの広告ドメインを手書きする必要があるのでしょうか。そんなことはありません。ルールセット(rule-providers)を使えば、ノードを購読するのと同じようにルールを購読できます。コミュニティが管理し、定期的に更新してくれるので、設定ファイルには1行の参照を書くだけで済みます。
ルールセットとは何か
通常のルールはrulesに直接書き、1行で1つの条件をマッチさせます。それに対してルールセットは、同種のルールを何百・何千件もまとめて外部ファイル化したもので、Clashクライアントが定期的に取得・更新します。両者は次のように組み合わせて使います。
- rule-providers セクション:「どのルールパッケージを、どこから、どのくらいの頻度で更新するか」を宣言します。
- rules セクション:
RULE-SET,パッケージ名,出口という1行でパッケージ全体を参照します。
ルールセットを宣言する
rule-providers: reject-ads: type: http behavior: domain url: "https://example.com/ruleset/reject.yaml" path: ./ruleset/reject.yaml interval: 86400 # refresh once a day jp-direct: type: http behavior: domain url: "https://example.com/ruleset/direct-jp.yaml" path: ./ruleset/direct-jp.yaml interval: 86400 telegram-cidr: type: http behavior: ipcidr url: "https://example.com/ruleset/telegram.yaml" path: ./ruleset/telegram.yaml interval: 86400
各フィールドの意味は次のとおりです。
| フィールド | 説明 |
|---|---|
type | http(リモート購読、推奨)またはfile(ローカルファイル) |
behavior | ルールの形式:domain(ドメインのみ)/ ipcidr(IPレンジのみ)/ classical(複数種類が混在する完全なルール) |
url | ルールファイルのダウンロード先URL |
path | ローカルキャッシュのパス。オフライン時はこのキャッシュで代替します |
interval | 自動更新の間隔(秒)。86400 = 24時間 |
rulesから参照する
rules: - RULE-SET,reject-ads,REJECT # thousands of ad domains, one line - RULE-SET,jp-direct,DIRECT - RULE-SET,telegram-cidr,ノード選択 - GEOIP,JP,DIRECT - MATCH,ノード選択
ここでもポイントは順序です。ブロック系のルールセットを最前列に、直接接続系をその次に置き、最後の受け皿となるMATCHは必ず最後尾に置きます。なおGEOIP,JP,DIRECTは「解決されたIPが日本のIPアドレス帯に属していれば直接接続する」というルールで、GEOIPルールは着信IPの所属国・地域を自動判定してくれる仕組みです。国や地域のコードはISO 3166-1準拠の2文字(日本ならJP)を指定します。
behaviorの選び方
3つの形式はそれぞれマッチ性能が異なり、正しく選ぶことでマッチ速度が向上します。
- domain:内容がすべてドメインの場合に使用します。内部で接頭辞木(トライ木)を構築するため、数万件のルールでもマッチ時間はマイクロ秒単位で済みます。
- ipcidr:内容がすべてIPレンジの場合に使用します。内部は効率的なトライ構造です。
- classical:DOMAIN、IP-CIDR、PROCESS-NAMEなど複数の種類が混在する場合にのみ使用します。柔軟な反面、マッチのコストが最も高くなります。
ルールセットの更新が失敗したら
ルールセットは外部からのダウンロードに依存しているため、更新にたまに失敗することがあります。次の順番で調査しましょう。
- まずローカルキャッシュを確認する:
pathが指すファイルが存在していれば、Clashクライアントは古いバージョンで一旦代替するため、1回の更新失敗だけでルールセット全体が無効になることはありません。そのため問題に気づきにくいこともあり、時々更新日時を確認する習慣をつけることをおすすめします。 - ダウンロード先URLがまだ有効かを確認する:コミュニティ管理のルールセットは、リポジトリの移動やパスの変更が時々発生します。ブラウザで直接
urlを開いてアクセスできるか確認し、アクセスできない場合はルールセットのプロジェクトページで最新のURLを探して置き換えましょう。 - intervalが極端な値になっていないか確認する:数十秒に設定してしまい、配信元のレート制限にかかって頻繁に失敗するケースを見かけます。通常は43200〜86400秒(12〜24時間)程度で十分です。
定番のルールセットはどこで探せるか
ゼロからルールを組む必要はありません。GitHub上には長期的にメンテナンスされ、スター数も多いルールセットのリポジトリがいくつも存在し、広告ブロック、直接接続用ルール、動画配信サービスの解除、主要アプリの振り分けなどをカバーしています。「clash rule providers」や「ruleset」で検索すればほぼ見つかります。選ぶ際は、最近も更新されているかとbehaviorの種類が自分の参照方法と合っているかの2点を確認しましょう。ルールセットとClashクライアント本体はそれぞれ別の役割です——ルールセットは「どう振り分けるか」を決め、Clashクライアントは「どう接続し、どうスケジューリングするか」を担当します。両者が組み合わさることで、すっきりして使いやすい設定になります。
広告ブロック用のルールセットを組み込むと、多くのウェブページ上の煩わしいバナー広告が根本から消えます。ブラウザ拡張機能を入れるより手間がかからないのは、ネットワーク層でブロックしているため、すべてのデバイス・すべてのアプリに一括で効果が及ぶからです。
手書きルールとルールセットは二択ではなく併用するもの
ルールセットを使い始めると、手書きのルールを全部削除してしまう人がいますが、そこまで徹底する必要はありません。両者の役割は異なります。ルールセットは「件数が非常に多く、更新頻度も高く、自分で維持するのが現実的でない」場面に向いています。たとえば数千件規模の広告ドメインや、頻繁に変化する動画配信サービスのIPレンジなどです。一方、手書きルールは「件数は少ないが優先順位や精密な制御にこだわりたい」場面に向いています。たとえば社内ネットワークのドメインや、自分がよく使う特定のサイトなどです。
おすすめの書き方は次のとおりです。個別対応したい手書きルールを最前列に置いて確実に優先マッチさせ、その次にルールセットで大量の汎用的な分類を処理し、最後にGEOIP,JP,DIRECTとMATCHで受け止めます。これなら柔軟性を保ちながら、数百件の広告ドメインのために設定ファイルを数千行まで膨らませる必要もなく、メンテナンスの手間も大幅に減ります。
初心者が見落としがちな細部:ルールの順序は本当に結果を左右する
ルールは上から下へ順に評価され、最初にマッチした時点でそのルールが即座に適用されます。それより後にあるルールは、内容が正しく書かれていても実行されません。あるサイトで「ルールを設定したはずなのに反映されない」と感じたら、多くの場合ルールの書き方が間違っているのではなく、前にあるより広い範囲のルール(ルールセット内の汎用的な項目など)が先にマッチしてしまっていることが原因です。この種の問題を最速で調査する方法は、コントロールパネルの接続ページを開いて、その通信が実際にどのルールにマッチしたのかを直接確認することです。設定ファイルを見ながら当てずっぽうで推測するよりずっと効率的です——この点は「Clashコントロールパネル完全ガイド:接続・ログ・速度テスト」でも触れているので、両方を組み合わせて使うと効率がさらに上がります。
まとめ
ルールセットは「ルールを人力で維持する」という地味な作業をコミュニティと自動更新に任せてくれます。あなたがやるべきことは、取得元を宣言し、正しいbehaviorを選び、正しい順序で参照することだけです。3つのポイントを覚えておきましょう。ブロック系を最前列に、直接接続系をその次に、MATCHは常に最後の受け皿にする。behaviorはルールセット自体の内容形式と一致させる必要があり、選択を誤るとマッチが遅くなったりエラーになったりする。更新が失敗したときは、まずローカルキャッシュが有効に機能しているかを確認し、それからダウンロード先URLと更新間隔を調査する。設定が一度整えば、その後はほとんど手をかけなくても、ルールセット自体がコミュニティの更新に合わせて自動的に新しい状態を保ってくれます。
もし今の設定ファイルにまだ数百件の手書きドメインルールが残っているなら、週末に30分ほど時間を取って、ルールセットに置き換えられる部分を整理してみましょう。設定ファイルは一気にすっきりし、今後のメンテナンスも負担にならなくなります。