なぜルール分岐が必要なのか
ルール分岐の目的はシンプルです。日本国内のサイトへのアクセスはローカル直結にし、海外サイトへのアクセスはプロキシノード経由にすることで、2つの経路が互いに干渉しないようにします。直結の利点は低遅延でノードの帯域を消費しないこと、プロキシノードの利点は制限されている、あるいは速度が遅い海外リソースにアクセスできることです。分岐設定をしないと、グローバルモードでは全通信がプロキシを経由するため、国内サイトへのアクセスも遠回りして遅延が増え、ノードの上り帯域も消費してしまい、混雑時にサーバーの速度制限に当たるとさらに体感が悪化します。
分岐を実現するには、Clash(およびそのコア実装である Clash Meta / mihomo)の設定ファイルにある互いに連携する2つの部分を理解する必要があります。proxy-groups は「選択可能な出口ポリシーにどんなものがあるか」を定義し、rules は「どのような通信をどのポリシーに振り分けるか」を定義します。ルール自体はノードを選びません。ノードを選ぶのはポリシーグループであり、ルールは通信を特定のポリシーグループに振り分けるだけで、実際にどの経路を通るかはポリシーグループ内部の選択ロジックが決めます。この階層関係を理解することが、以降のすべての設定を理解する前提になります。
proxy-groups の書き方
ポリシーグループとは本質的に複数のプロキシノード(または他のポリシーグループ)の集合に、選択方式を組み合わせたものです。よく使う type には次の3種類があります。
- select:手動選択。クライアントの画面にドロップダウンリストが表示され、ユーザーが選んだノードをそのまま使用し、自動切り替えはしません。
- url-test:自動速度計測。
urlとintervalに従い定期的にグループ内ノードの遅延を測定し、最も速いものを自動選択します。 - fallback:フェイルオーバー。ノードリストの順に接続を試み、現在のノードが使えなくなると自動的に次のノードへ切り替えます。
典型的な地域別分岐のシナリオでは、少なくとも3つのポリシーグループが必要です。「海外通信」用の自動速度計測グループ、固定の DIRECT(直結、コア内蔵のため自分でノードを定義する必要はありません)、そして最後の手動選択グループです。例:
proxy-groups:
- name: 節点選択
type: select
proxies:
- 自動選優
- DIRECT
- name: 自動選優
type: url-test
proxies:
- HK-01
- HK-02
- SG-01
- JP-01
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 国内直連
type: select
proxies:
- DIRECT
- 節点選択
HK-01 などの名称は、サブスクリプションから解析される実際のノード名と一致させる必要があります。通常はクライアントでサブスクリプションを取り込んだ後、ノードリストで実際の名前を確認できるので、それに合わせてポリシーグループの proxies フィールドを調整してください。url は速度計測用のリクエスト先アドレス、interval は計測間隔(秒単位)、tolerance は切り替えの許容差で、遅延差がこの範囲内であれば頻繁な切り替えは発生しません。
rules のルール種別とマッチ順序
ルールは上から下へ順番にマッチが行われ、いずれかのルールが一致した時点で即座に適用され、それ以降のルールはチェックされません。つまりルールの並び順がそのまま分岐結果を決定するため、順序を誤ることが最もよくある失敗の原因になります。よく使うルール種別は以下の通りです。
- DOMAIN-SUFFIX:ドメインの末尾でマッチします。例えば
DOMAIN-SUFFIX,taobao.comは該当ドメインとそのすべてのサブドメインに一致します。 - DOMAIN-KEYWORD:ドメイン内のキーワードでマッチします。条件が緩いため誤爆しやすく、キーワードの一意性が明確な場合にのみ使うことを推奨します。
- DOMAIN:単一のドメインを完全一致でマッチします(サブドメインは含みません)。
- GEOIP:宛先 IP が属する国・地域でマッチします。例えば
GEOIP,CN,DIRECTは宛先 IP が中国本土と判定された場合に直結するという意味です。GEOIP のマッチは内蔵または外部の IP 地理データベースに依存するため、データベースが古いと誤判定が発生することがあります。クライアントで定期的に地理データベースファイルを更新することを推奨します。 - IP-CIDR / IP-CIDR6:IP アドレス範囲でマッチします。プライベートアドレスやローカルネットワークアドレスの直結処理によく使われます。
- MATCH:デフォルトルールで、ルールリストの最終行に置き、それまでのルールに一致しなかったすべての通信をマッチさせます。
ルールの書き方は統一的に 種別,マッチ対象,適用先ポリシー の3要素をカンマで区切ります。完全なルールリストの構成は概ね次のようになります。
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- DOMAIN-KEYWORD,baidu,DIRECT
- DOMAIN-SUFFIX,taobao.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- GEOIP,CN,国内直連
- MATCH,節点選択
このルールの読み方は次の通りです。まず明らかに国内に属するドメインとローカルネットワークアドレスを除外して DIRECT に渡します。残りの IP が中国本土と判定された場合は「国内直連」ポリシーグループに渡します(内部的には DIRECT ですが、手動切り替えの余地を残しています)。最後に、それまでのルールに一致しなかった通信はすべて「節点選択」という自動速度計測グループに渡して海外アクセスを処理させます。
順序ミスは最もよくある落とし穴です。MATCH,節点選択 を途中に置いてしまうと、それ以降に書かれた国内ドメイン向けのルールはすべてチェックされなくなります。MATCH はそれ以降に来るすべての通信判定を先取りしてしまうためです。MATCH は必ずルールリストの最終行に置いてください。
動画配信サービス専用のポリシーグループを作る
多くのユーザーは、動画配信サービスの通信を固定の特定ノード(例えば解除対応と明記されたノード)に振り分けたいと考えており、「自動選優」グループと一緒に速度計測で切り替わってしまうのを避けたいはずです。そうすることで、視聴中に突然ノードが切り替わって再バッファリングが発生するのを防げます。方法としては専用のポリシーグループを新設し、ルール内で該当ドメインを個別に振り分け、かつこのルールを汎用ルールより前に置く必要があります。
proxy-groups:
- name: 流媒体
type: select
proxies:
- HK-01
- SG-01
- 自動選優
rules:
- DOMAIN-SUFFIX,netflix.com,流媒体
- DOMAIN-SUFFIX,nflxvideo.net,流媒体
- DOMAIN-SUFFIX,disneyplus.com,流媒体
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,国内直連
- MATCH,節点選択
ここでのポイントは、動画配信関連のドメインルールを必ず MATCH より前に置き、できれば他の汎用ルールよりも前に置くことです。そうすることで、より前方にある広範なルール(例えば何らかの DOMAIN-KEYWORD)に先取りされてしまうのを避けられます。ルールリストの中で、より具体的で厳密な制御が必要な項目ほど前に、より汎用的なデフォルトルールほど後ろに置くべきです。
動画配信ドメインの管理にルールセット(rule-provider)形式のドメインリストを併用している場合も原理は同じで、個別の DOMAIN-SUFFIX を書く代わりにリモートまたはローカルで管理されたルールセットファイルを参照する形になります。書き方としては rule-providers フィールドと対応する RULE-SET ルール種別が増えるだけで、マッチ順序のロジックは完全に変わりません。
ルールモードとグローバルモードの違い
クライアントの画面では通常3種類の動作モードを切り替えられます。これらと上記の設定との関係を理解しておくことは重要です。
- ルールモード(Rule):
rulesリストに厳密に従って順番にマッチします。本記事で解説しているデフォルトの動作方式です。 - グローバルモード(Global):すべての
rulesを無視し、すべての通信を手動で選んだ単一のノード経由に統一します。あるノードが利用可能かを一時的に確認するのに向いていますが、日常的な使用には適しません。 - 直結モード(Direct):すべての
rulesを無視し、すべての通信をプロキシノードを経由せず直結します。プロキシがある接続問題に影響しているかを一時的に確認するのに向いています。
日常使用ではルールモードに固定しておき、問題調査のときだけ一時的にグローバルモードや直結モードに切り替えて比較テストを行い、テストが終わったら必ず元に戻してください。戻さないとルール分岐の効果が発揮されません。
ルールを書いた後の確認方法
- 設定を保存した後、クライアントで設定の再読み込みを実行してください(クライアントによって「リロード」や「更新」と表記されることがあります)。エディタのキャッシュによってルールが実際に反映されていないケースを避けるためです。
- クライアント内蔵の接続ログやトラフィックパネルを開き、既知の国内サイトにアクセスして、マッチしたルールと最終的なポリシーが DIRECT になっていることを確認します。
- 次に既知の海外サイトにアクセスし、マッチしたルールが想定したポリシーグループに落ちていること、そのポリシーグループで現在選択されているノードの状態が正常であることを確認します。
- あるドメインが想定と異なるポリシーに振り分けられていた場合は、そのドメインルールより前に置かれた、より広範なルール(特に DOMAIN-KEYWORD)に先取りされていないか確認してください。
- GEOIP の判定に異常がある場合は、クライアント内の地理データベースファイルの更新日時を確認してください。古いデータベースは一部 IP の帰属判定を不正確にする原因になります。
ルール分岐は一度書いたら放置しておけるものではありません。アクセスするサイトの変化やノードの増減に伴い、ポリシーグループのノードリストや一部のドメインルールを随時微調整する必要が出てきます。まずログを確認してからルールを修正する習慣をつけると、感覚で推測するよりも問題の特定がしやすくなります。
すべてのルールを自分で書きたくない場合、多くのプロバイダーやコミュニティが管理しているルールセット(国内直結、ローカルネットワーク直結、主要サービス分類などが整理済みのルールファイル)を rule-providers で参照することで、手動管理するドメイン件数を減らしつつ、独自ルールを優先的にマッチさせる仕組みは維持できます。