ルール・ルーティングとは?
従来のプロキシツールでは、多くの場合「グローバルプロキシ」か「ダイレクト(直結)」の二択しかありませんでした。しかし、現代のインターネット環境は複雑です。Google にはプロキシ、国内ニュースサイトには速度重視で直結、仕事用の特定サービスには専用の経路が必要といった具合です。このように、宛先アドレス、IP、プロセス名などの条件に基づいて自動的に接続経路を選択する技術がルール・ルーティングです。
Clash の核心的な価値は、その強力で柔軟なルールエンジンにあります。適切なルール設定を行うことで、「意識することなく」快適なネット環境を構築できます。ブラウザは自動的に最適な経路を選び、ダウンロードは帯域の広いノード、ストリーミングは地域制限解除済みの特定ノードへと振り分けられます。
基本構造とマッチングロジック
config.yaml の rules: セクションにある各行が一つのルールです。基本的なフォーマットは以下の通りです:
- タイプ,条件,ポリシー[,オプション]
例:- DOMAIN-SUFFIX,google.com,Proxy。このルールは「リクエストドメインの末尾が google.com であれば、Proxy という名前のポリシーグループを使用する」という意味になります。
MATCH ルールのポリシーが適用されます。
各ルールタイプの詳細解説
効果的なルールを書くためには、サポートされているタイプを理解する必要があります。
1. ドメインマッチング
- DOMAIN: ドメインの完全一致。例:
DOMAIN,www.google.com,Proxy。 - DOMAIN-SUFFIX: ドメインの末尾一致。最も多用されます。例:
DOMAIN-SUFFIX,google.com,Proxyはwww.google.comとmail.google.comの両方にマッチします。 - DOMAIN-KEYWORD: ドメイン内のキーワード一致。例:
DOMAIN-KEYWORD,google,Proxy。
2. IP マッチング
- IP-CIDR: 特定の IP 範囲の一致。例:
IP-CIDR,192.168.1.0/24,DIRECT。 - GEOIP: 国・地域による一致。例:
GEOIP,JP,DIRECTは既知の日本の IP アドレスすべてにマッチします。
3. その他のマッチング
- SRC-IP-CIDR: リクエスト元のソース IP に基づく一致。LAN 内のデバイスごとに振る舞いを変えたい場合に便利です。
- PROCESS-NAME: リクエストを発行したプロセス名に基づく一致(一部のカーネルでのみサポート)。
- MATCH: すべてにマッチするルール。通常、最後に「その他」として記述します。例:
- MATCH,FinalProxy。
マッチング順序:なぜ順番が重要なのか
「最初にマッチした時点で終了」という特性上、ルールの記述順序が結果を左右します。よくある間違いは、一番上に MATCH,Proxy を置いてしまうことです。これではすべてのトラフィックがプロキシ経由になり、それ以降のルールは一切意味をなさなくなります。
推奨される順序:
- LAN / ダイレクト ホワイトリスト:
localhostや127.0.0.1など。 - 特定のドメインマッチ: 特殊な扱いが必要なサービス。
- ドメイン末尾マッチ: 多くの海外サービス。
- IP ベースの振り分け(GEOIP を含む): ドメインで識別できないトラフィック。
- 最終ルール (MATCH): 漏れたトラフィックの受け皿。
応用:Rule Providers による効率的な管理
ルールが数千行に及ぶようになると、管理は困難を極めます。Clash Meta で導入された rule-providers は、外部のルールセットファイル(Rule Sets)を参照することを可能にします。
rule-providers:
google:
type: http
behavior: domain
url: "https://raw.githubusercontent.com/.../google.yaml"
path: ./ruleset/google.yaml
interval: 86400
rules:
- RULE-SET,google,Proxy
- GEOIP,JP,DIRECT
- MATCH,Final
Rule Providers のメリット:
- 自動更新: コミュニティで維持されている高品質なルールセットを引用でき、Clash が
intervalに従って自動更新します。 - 設定ファイルの整理: メインの設定ファイルが非常に短くなり、可読性が向上します。
- パフォーマンス: カーネル側でこれらのルールセットに最適化されたインデックスが作成されます。
DNS とルールの微妙な関係
「GEOIP,JP,DIRECT と書いたのに、国内サイトへの接続が遅い、あるいは失敗する」という声をよく聞きます。
これは多くの場合、DNS 解析が関係しています。Fake-IP モードでは、Clash はブラウザに即座にフェイク IP を返し、内部で DNS 解析を並行して行います。もし DNS 設定が適切でなく、国内ドメインに対して海外の IP を返してしまった場合、GEOIP,JP ルールは正しく発動しません。
nameserver に信頼できる国内 DNS を含め、適切な fallback ロジックを構築することが重要です。
トラブルシューティングとデバッグ
1. ルールにマッチしているはずなのに効いていない?
より上部にある別のルールが先にリクエストをキャッチしていないか確認してください。Yacd や MetaCubeX などのダッシュボードの「接続」タブでは、各接続がどのルールにマッチしたかをリアルタイムで確認できます。これはデバッグの「黄金の鍵」です。
2. なぜ IP ではなくドメインで分流すべきなのか?
現代の CDN などを用いた大規模サービスは、複数の国で同じ IP 範囲を使用していることがあります。IP だけで判断すると、ルーティングが不安定になる可能性があります。ドメイン分流はアプリケーション層での判断となるため、より精密です。
3. ルールの衝突が起きたら?
「より具体的な条件を上に」という原則に従ってください。例えば DOMAIN,test.google.com,DIRECT は DOMAIN-SUFFIX,google.com,Proxy よりも上に記述すべきです。
実戦例:理想的な設定テンプレート
以下はベストプラクティスに基づいたルール設定の抜粋です。パフォーマンスと精度のバランスが取れています。
rules:
# 1. ローカル / ダイレクト
- DOMAIN-SUFFIX,local,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- IP-CIDR,172.16.0.0/12,DIRECT
- IP-CIDR,127.0.0.0/8,DIRECT
# 2. 特定サービスの優先分流
- DOMAIN-SUFFIX,apple.com,AppleServices
- DOMAIN-SUFFIX,netflix.com,Streaming
# 3. Rule Sets による広範囲な分流
- RULE-SET,proxy,Proxy
- RULE-SET,gfw,Proxy
# 4. IP による最終確認
- GEOIP,JP,DIRECT
# 5. 全体の受け皿
- MATCH,FinalProxy
この構造により、ネットワークリクエストは各々の役割を果たします:国内トラフィックは GEOIP,JP で DIRECT(直結)となり低遅延を維持、既知の海外サービスは RULE-SET で Proxy へ、そして未知のトラフィックはすべて MATCH で FinalProxy へと送られ、確実な疎通が確保されます。
ルール分流は一度設定して終わりではありません。ネット環境の変化に合わせて、ルールセットを定期的に更新し、自身のポリシーグループを調整し続けることが快適な体験を維持するコツです。
このガイドが、皆さんの完璧な Clash 設定構築の一助となれば幸いです。真の自由は、一つひとつのリクエストを精密に制御することから生まれます。
結語:手動設定からインテリジェントなルーティングへ
ルール分流の極意をマスターすれば、Clash は単なるプロキシツールを超え、あなた専用のインテリジェントなネットワーク・ディスパッチャーへと進化します。初期設定には多少の手間がかかりますが、一度構築してしまえば、従来の VPN とは比較にならないほど滑らかな体験が得られます。
もし複雑な YAML ファイルの編集を避け、よりシンプルでモダンな体験を求めるなら、タイムリーなカーネル更新と優れた UI を備えたクライアントを選択することも同様に重要です。