Clash の基本設定を終えると、すぐに次のような要望にぶつかります。国内サイトは直接接続、海外サイトはプロキシ経由、社内ネットワークはプロキシを通さない、ゲームのトラフィックは別扱い、ついでに広告もブロックしたい。これらは「プロキシをオンにする」だけでは解決できず、Clash のルールエンジンの中核的な能力で対応するものです。本記事ではルール構文から説き起こし、自分だけの分岐戦略を一歩ずつ組み立てていきます。
ルールエンジンの動作の仕組み
Clash はネットワークリクエストを処理するたびに、rules リストのルールを上から順番に1つずつマッチングします。いずれかのルールにヒットした時点で対応するアクション(特定のプロキシグループ経由、直接接続、または拒否)を直ちに実行し、それ以降のマッチングは行いません。そのため、ルールの並び順が極めて重要です。具体的なルールほど前に、広範なルールほど後ろに配置すべきです。
典型的なルールリストの構造は次のとおりです。
rules:
- DOMAIN-SUFFIX,company.internal,DIRECT
- DOMAIN-SUFFIX,google.com,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy
最後の MATCH は受け皿となるルールで、必ずリストの末尾に置きます。そうしないと、それ以降のルールは決して実行されません。
GEOSITE、PROCESS-NAME、RULE-SET など)に対応しており、オリジナルの Clash より強力です。本記事の例はすべて Mihomo コアの構文に基づいています。
よく使うルールタイプの詳解
ドメイン系ルール
DOMAIN は完全なドメインを厳密に一致させ、DOMAIN-SUFFIX はドメインとそのすべてのサブドメインに一致し、DOMAIN-KEYWORD はドメインに指定したキーワードを含むリクエストに一致します。3 つは厳密なものから曖昧なものまであり、使いどころが異なります。
DOMAIN,www.google.com,Proxy— www.google.com のみに一致DOMAIN-SUFFIX,google.com,Proxy— google.com とすべてのサブドメイン(mail.google.com など)に一致DOMAIN-KEYWORD,google,Proxy— ドメインに google を含むすべてのリクエストに一致
日常的な設定では DOMAIN-SUFFIX が最もよく使われます。サブドメインをカバーしつつ、無関係なドメインを誤って一致させることもありません。厳密な制御が必要なときだけ DOMAIN を使います。
IP 系ルール
IP-CIDR と IP-CIDR6 は IP アドレス帯で一致させるもので、内部ネットワークの直接接続や特定 IP 帯のブロックによく使われます。例えば次のようになります。
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
この3つは RFC 1918 で定義されたプライベートアドレス帯で、ほぼすべてのサブスクリプション設定に含まれており、LAN 機器同士の通信がプロキシを経由しないようにします。no-resolve は、このルールのために DNS 解決をトリガーしないことを意味し、循環的なクエリを避けます。
地理的位置ルール
GEOIP は IP の所属地で一致させ、GEOSITE はドメイン分類データベースで一致させます。これは「国内は直接接続、海外はプロキシ経由」を実現する最もシンプルな方法です。
- GEOSITE,cn,DIRECT
- GEOSITE,google,Proxy
- GEOIP,CN,DIRECT
- GEOIP,LAN,DIRECT
GEOSITE はドメイン分類に基づくため、GEOIP より正確です。例えば海外に配置された CDN ノードは、GEOIP では海外と誤判定されることがありますが、GEOSITE,cn なら国内サービスとして正しく識別できます。
プロセスとポートのルール
PROCESS-NAME はリクエストを発したプログラム名で一致させ、特定のソフトウェアを指定の回線経由にするのに適しています。
- PROCESS-NAME,Telegram.exe,Proxy
- PROCESS-NAME,WeChat.exe,DIRECT
- PROCESS-NAME,steam.exe,Game
DST-PORT と SRC-PORT は宛先または送信元のポートで一致させます。単独で使われることは少ないですが、ゲームの UDP トラフィックを細かく制御する際に役立ちます。
プロキシグループ:ルールのターゲット
ルールの右側にある3つ目のパラメータは、プロキシグループ名またはアクションです。DIRECT(直接接続)、REJECT(拒否)、REJECT-DROP(無応答で破棄)以外は、すべて自分で定義したプロキシグループです。
よく使われるプロキシグループのタイプは次のとおりです。
- select — 手動選択。画面上にはドロップダウンリストとして表示され、最もよく使われます
- url-test — 自動速度計測。遅延が最も低いノードを選びます
- fallback — 順番に試し、現在のノードが使えなくなると自動的に切り替えます
- load-balance — 負荷分散。複数のノード間でトラフィックを振り分けます
- relay — チェーンプロキシ。トラフィックが複数のノードを順番に経由します
実用的なマルチグループ戦略の例を示します。
proxy-groups:
- name: Proxy
type: select
proxies: [Auto, HK, JP, US, DIRECT]
- name: Auto
type: url-test
proxies: [HK, JP, US]
url: http://www.gstatic.com/generate_204
interval: 300
- name: AdBlock
type: select
proxies: [REJECT, DIRECT]
Rule-Provider:サードパーティルールセットを購読する
数百ものルールを手作業で維持するのは現実的ではありません。Rule-Provider を使えば、リモートの URL からルールセットを購読でき、Clash が定期的に取得して更新します。設定の形式は次のとおりです。
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/rules/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
direct:
type: http
behavior: domain
url: "https://example.com/rules/direct.txt"
path: ./ruleset/direct.yaml
interval: 86400
rules:
- RULE-SET,reject,AdBlock
- RULE-SET,direct,DIRECT
- GEOSITE,cn,DIRECT
- MATCH,Proxy
behavior は domain、ipcidr、classical から選べます。domain と ipcidr は最適化されたバイナリ形式で、マッチング速度が速くなります。classical は完全な Clash ルール構文に対応し、柔軟性が最も高いです。
REJECT に向けてサービスを利用不能にしたり、悪意あるノードに向けてトラフィックを盗んだりする恐れがあります。
広告ブロック実践
Clash の広告ブロックの原理はとてもシンプルです。広告ドメインを REJECT または REJECT-DROP に一致させると、リクエストがローカルで破棄され、広告コンテンツが一切読み込まれなくなります。ブラウザの拡張機能と比べ、Clash はシステムレベルでブロックするため、すべてのアプリ内の広告リクエストをカバーできます。
おすすめの広告ブロックルールの並び順は次のとおりです。
- LAN と内部ネットワークの IP を直接接続(ローカルサービスの誤ブロックを防ぐため)
- 広告ドメインのルールセット →
REJECT - 国内ドメイン →
DIRECT - 海外ドメイン →
Proxy MATCHで受け止め
広告ブロックを有効にすると、一部のサイトの「広告ブロック対策」検出が作動し、広告ブロッカーを無効にするよう促されることがあります。これは正常な現象で、ルールの中で特定のドメインに例外を追加できます。
- DOMAIN-SUFFIX,anti-adblock-example.com,DIRECT
例外ルールを広告ルールセットの前に置くと、拒否されるのではなく直接接続が優先的にヒットします。
実践:自分の分岐戦略をカスタマイズする
以下は多くのユーザーに適した完全なルールのフレームワークです。これをベースに増減できます。
rules:
# 1. ローカルと内部ネットワーク
- GEOIP,LAN,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# 2. 広告ブロック
- RULE-SET,reject,REJECT
# 3. カスタム直接接続(会社、銀行、行政)
- DOMAIN-SUFFIX,company.com,DIRECT
- GEOSITE,cn,DIRECT
# 4. カスタムプロキシ(特定サービスを特定ノード経由に)
- DOMAIN-SUFFIX,openai.com,US
- DOMAIN-SUFFIX,netflix.com,Proxy
# 5. 国内 IP は直接接続
- GEOIP,CN,DIRECT
# 6. 受け皿
- MATCH,Proxy
Clash Verge Rev などのクライアントでは、「設定 → ルール」画面でビジュアルに編集することも、YAML ファイルを直接編集することもできます。変更後に「設定を再読み込み」をクリックすれば反映され、クライアントを再起動する必要はありません。
ルールのデバッグ:トラフィックの行き先を確認する
ルールを書き終えたら、あるトラフィックが本当に意図どおりに振り分けられているかをどう検証すればよいでしょうか。Clash には接続ログ機能があります。Clash Verge Rev で「接続」パネルを開くと、各リクエストが一致したドメイン、宛先 IP、使われたルール、最終的に経由したプロキシグループをリアルタイムで確認できます。
デバッグのコツ:
- まず対象のサイトにアクセスし、接続ログで該当する項目を見つけます
- 「ルール」列を確認し、どのルールにヒットしたかを把握します。意図したルールでなければ、並び順を調整する必要があります
MATCHと表示される場合は、それ以前のすべてのルールにヒットしていないということなので、より具体的なルールを追加する必要があります- ルールを変更したら設定を再読み込みし、ページを更新して再テストします
一括で検証したい場合は、Clash の API を使ってルールのヒット状況を照会できます。上級ユーザーは LOG-LEVEL を debug に設定すると、ログファイルでルールマッチングの全過程を確認できますが、日常利用では info レベルを保ち、ログファイルが肥大化しないようにすることをおすすめします。
ルールのマージ:上書き vs 置換
サブスクリプションを使う場合、自分のカスタムルールはサブスクリプション提供のルールとどう共存させればよいでしょうか。一般的に2つの方法があります。
- 前置ルール(prepend-rules) — 自分のルールをサブスクリプションルールの前に挿入します。優先度が最も高く、直接接続の例外や広告ブロックの追加に適しています
- 後置ルール(append-rules) — 自分のルールをサブスクリプションルールの後ろに追加します。受け皿戦略の変更に適しています
Clash Verge Rev の「設定 → 上書き」機能では、完全な設定ファイルを変更することなく、YAML の断片でルールを追加できます。例えば広告ブロックとカスタム直接接続だけを追加する場合は次のようになります。
prepend-rules:
- RULE-SET,reject,REJECT
- DOMAIN-SUFFIX,mycompany.com,DIRECT
この方式の利点は、サブスクリプションを更新しても自分のカスタムルールが上書きされないことで、日常的な運用で最もおすすめの方法です。
よくある問題のトラブルシューティング
ルールを変更したのに反映されない
設定を再読み込みしたか確認してください(ファイルを保存しただけではありません)。一部のクライアントには「ルール」と「設定」の2つの編集入口があり、間違った場所を変更しても反映されません。YAML のインデントが正しいかも確認しましょう。YAML はインデントに極めて敏感で、スペースが1つ足りないだけでルール全体が無視されてしまいます。
国内サイトがプロキシを経由してしまう
多くの場合、GEOIP,CN,DIRECT の位置が後ろすぎて、前にある MATCH,Proxy に先に一致しています。GEOIP/GEOSITE のルールを上に移動し、受け皿のルールが最後に来るようにしてください。
広告ブロックでアプリの機能が正常に動作しない
一部のアプリの統計・プッシュ通知・更新サービスのドメインが、広告ドメインと同じルールセットに含まれていることがあります。影響を受けるアプリ向けに DOMAIN-SUFFIX の例外を追加するか、一時的に広告ルールセットを REJECT から DIRECT に変更して、具体的なドメインを切り分けてください。
まとめ
Clash のルールシステムは、振り分けプロキシの要です。DOMAIN-SUFFIX、GEOSITE、GEOIP の3つの中核ルールを押さえ、Rule-Provider による購読管理と組み合わせれば、安定した個性的な分岐戦略を構築できます。広告ブロックは広告ドメインを REJECT に向けるだけで、ルールの順序が正しければシステムレベルでの広告除去が実現します。
ルール設定に「一度で完璧」はありません。利用シーンの変化に応じて、何度も微調整していくものです。サブスクリプション提供のデフォルトルールから出発し、一度に1〜2 条だけカスタムルールを追加してテストするのが、すべてのルールを一気に書き直すよりもずっと確実です。