ルーティング実践 読了目安 13分

Clashのルール分割設定を実践：国内・海外トラフィックのYAML記述例

よくある地域別ルーティングを題材に、プロキシグループ、ルールの優先順位、フォールバック、設定確認の方法を順に解説します。

国内は直結、海外はプロキシにするルーティングモデルを決める

Clashのルールモードでは、すべてのルールを同時に評価するわけではありません。接続情報を上から順に確認し、条件に一致する最初のルールが見つかると、そこで判定を終了します。国内・海外トラフィックを振り分ける際に結果を左右するのは、ルールで何を識別できるか、一致後にどのプロキシグループへ渡すか、そして一致しなかった場合にどのルールでフォールバックするかの3点です。

メンテナンスしやすい基本モデルは、通常4層に分けます。第1層では、LANアドレス、ループバックアドレス、本機のサービスを処理し、ルーター、プリンター、ネットワークストレージ、開発環境へのアクセスがプロキシ経由にならないようにします。第2層には、社内ドメイン、ダウンロードサイト、特定アプリのAPIなど、動作を明示的に指定したいドメインを置きます。第3層では、ドメインセットとIPの地理情報を使って、広範囲の地域トラフィックを処理します。第4層では MATCH を使い、それまで識別できなかった接続を受け止めます。

  1. LANとプライベートアドレス：DIRECT に渡し、ローカルデバイス間の通常の通信を維持します。
  2. 明示的なドメインルール：実際の要件に応じて直結、プロキシ、拒否を指定し、地域別ルールより優先します。
  3. 国内トラフィック：ドメインルールセット、GEOIP、またはmihomoの GEOSITE で判定できます。
  4. 未一致のトラフィック：通常は海外向けプロキシグループに渡し、特定のノードを直接指定しません。

ここでいう「国内」には2つの意味があります。1つはLAN内のプライベートアドレス、もう1つは直結したい国内インターネットのトラフィックです。前者は固定のアドレス帯で安定して識別できますが、後者はドメインだけで判定できる場合もあれば、最終的にCDNのアドレスへ接続する場合もあります。そのため、ドメイン判定とIP判定を組み合わせる必要があります。

プロキシグループが経路を選び、ルールはトラフィックを渡すだけ

ルール末尾の宛先には DIRECT、REJECT、またはプロキシグループ名を指定できます。長期運用では、海外トラフィックを特定のプロキシノードではなく、プロキシグループへ向けるのがおすすめです。ノード名はサブスクリプション更新で変わることがありますが、プロキシグループ名は固定できるため、ルールを何度も書き換える必要がありません。

以下の断片では、よく使う3つのプロキシグループを示します。「海外トラフィック」はユーザーが選択する入口で、自動テストグループまたは直結を手動で選べます。「自動選択」は候補ノードを定期的にテストし、「フォールバックトラフィック」は地域別ルールに一致しなかった接続を受け持ちます。この例では、サブスクリプションに airport というプロキシプロバイダーがすでに存在すると仮定しています。実際には現在の設定にあるprovider名へ置き換えてください。

proxy-groups:
  - name: 海外トラフィック
    type: select
    proxies:
      - 自動選択
      - DIRECT

  - name: 自動選択
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: フォールバックトラフィック
    type: select
    proxies:
      - 海外トラフィック
      - DIRECT

select グループは現在の選択を自動で変更しないため、経路を安定して手動管理したい場合に適しています。url-test はテスト結果に応じて候補ノードから応答の速いノードを選びます。ただし、遅延値はテスト先の応答状況を示すもので、すべてのサイトの実際のダウンロード速度を保証するものではありません。モバイル回線で状況が頻繁に変わる場合は、interval を少し長くして、繰り返しテストを減らすとよいでしょう。

ノードを proxies リストに直接記述する場合、ノード名はスペースや大文字・小文字も含め、サブスクリプション設定と完全に一致させる必要があります。use を使う場合は、proxy-providers 配下のキーに対応させます。どちらの方式を使うかはクライアントとコアの対応状況に応じて選べますが、provider名を通常のノードリストに誤って記述しないでください。

ルールの順序：具体的な条件を先に、地域判定とフォールバックを後に

Clashは最初に一致したルールを採用するため、同じドメインが複数のルールに該当することがあります。たとえば files.example.cn は完全一致のドメインルールにも DOMAIN-SUFFIX,example.cn にも該当しますが、最終的に採用されるルールは先に記述された方です。設定は「例外ルール、アプリルール、ドメインによる地域ルール、IPによる地域ルール、最終フォールバック」の順に並べると整理しやすくなります。

順序 ルールの種類 用途
1 DOMAIN 完全な単一ドメインの例外経路を処理
2 DOMAIN-SUFFIX 同じベースドメインとそのサブドメインを処理
3 DOMAIN-KEYWORD キーワード一致を補足するが、適用範囲に注意
4 GEOSITE またはドメインルールセット 整備済みのドメイン集合で地域を分類
5 IP-CIDR、GEOIP 接続先がIPに解決された場合に判定
6 MATCH それまで一致しなかったすべての接続を受け持つ

DOMAIN-KEYWORD は適用範囲が広いルールです。キーワードが短すぎると、名前は似ていても用途がまったく異なるドメインに一致することがあります。完全なドメイン名やサフィックスで表現できる場合は、より正確なルールを優先してください。プロセスルールも慎重に使う必要があります。PROCESS-NAME はOSやコアからプロセス情報を取得するため、プラットフォーム、コンテナ環境、通常のシステムプロキシだけを有効にした環境では、プロセスの識別結果が一致しないことがあります。

MATCH はルールリストの末尾に置く必要があります。途中に置くと、その後のルールは実行されません。「国内は直結、それ以外はプロキシ」という構成では、末尾を通常 MATCH,フォールバックトラフィック とします。これにより、新しいドメイン、地理情報のないアドレス、分類できない接続にも明確な行き先を指定できます。

国内・海外トラフィックのYAMLルール記述例

以下は、やや保守的なルール例です。まずループバックアドレスと一般的なプライベートネットワークを直結し、次に指定ドメインを処理します。その後、国内ドメインとIPの地理情報による直結を試み、残りのトラフィックをプロキシグループへ渡します。この断片はClash Meta（mihomo）でよく使われる設定に対応しています。古いClashコアを使う場合は、クライアントが GEOSITE に対応しているか確認し、必要に応じて互換性のあるrule-providerのドメインルールセットへ置き換えてください。

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve

  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,海外トラフィック

  - GEOSITE,CN,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,フォールバックトラフィック

no-resolve をIPルールの末尾に置くことが多い理由

ルールの判定がIPタイプに進んだ時点で、現在の接続にドメイン名しかない場合、一部の実装は対象IPを取得するために名前解決を開始できます。no-resolve を追加すると、このルールの判定目的で追加のDNS解決を行わないことを指定できます。ルール処理中に発生する問い合わせを減らし、解決経路の違いによる待ち時間の増加も避けられます。

ただし、no-resolve はClashがDNSを完全に無視するという意味ではありません。接続自体には、現在のDNSモードに応じたドメイン処理が必要です。これは対応するIPルールの判定動作だけを制限します。Fake-IPモードでは、ドメインは通常、予約アドレスへ先にマッピングされます。コアはドメイン情報を保持してドメインルールを適用し、実際に接続を確立する段階で設定に従って対象アドレスを解決できます。

GEOIP,CN,DIRECT ですべての国内サイトをカバーできるか

GEOIPだけを唯一の判定基準にすることはできません。サイトがグローバルCDN、クラウドサービス、地域間の負荷分散を利用している場合、同じドメインでもネットワークによって異なるアドレスが返されることがあります。国内向けサービスが海外のアドレスを使う場合もあれば、海外サービスが国内にノードを配置する場合もあります。そのため、ドメインルールは通常GEOIPより先に置きます。既知のサービスはまずドメインで分類し、残りの接続をIPの地理情報で補足判定してください。

地理データベースはコアまたはクライアントとともに更新する必要があります。データベースが古いと、新しく割り当てられたアドレス帯が誤った地域に分類されることがあります。「同じサイトが端末によって異なる経路になる」場合は、YAMLだけでなく、GeoIP・GeoSiteデータのバージョンとDNSの応答結果も比較してください。

rule-providerで大量のドメインを管理する

ルールが増えたら、数千件のドメインをメイン設定の rules にすべて詰め込むのはおすすめしません。mihomoやルールプロバイダーに対応したClashクライアントでは、rule-providers から独立したルールファイルを読み込み、ルールリスト内で RULE-SET を使って参照できます。メイン設定には優先順位だけを残し、具体的な項目はルールファイルで管理します。

rule-providers:
  regional-direct:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/regional-direct.yaml
    url: https://rules.example.net/regional-direct.yaml
    interval: 86400

rules:
  - RULE-SET,regional-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,フォールバックトラフィック

behavior: domain はドメイン項目だけを含むルールセットに適しています。完全なルール構文を含む場合は通常 classical を使い、IPネットワークだけなら ipcidr を使えます。ルールファイルの内容はbehaviorと一致していなければならず、合わない場合は読み込みに失敗したり、一部の項目が一致しなかったりします。リモートルールセットにはローカルの path も設定し、クライアントがダウンロード結果をキャッシュできるようにしてください。

DNS、システムプロキシ、TUNモードがルーティング結果に与える影響

ルールを正しく書いても、実際の接続経路はトラフィックの取り込み方式に左右されます。システムプロキシを有効にすると、通常はシステムプロキシ設定に従うアプリだけがClashに入ります。ゲーム、コマンドラインツール、仮想マシン、自ら接続を確立するプログラムなどは、システムプロキシを迂回することがあります。TUNモードを有効にすると、コアはより広い範囲のIPトラフィックを取り込めるため、同じルールでも「より多くの接続に一致した」ように見えます。

TUNモードは地域別ルールの代わりではありません。TUNが解決するのはトラフィックをどのようにコアへ入れるかであり、ルールが解決するのは入った後にどの経路を通すかです。アプリのトラフィックがClashをまったく通っていなければ、GEOIP、MATCH、プロキシグループを調整しても結果は変わりません。切り分けでは、まず接続パネルに対象接続が表示されているか確認し、その後どのルールに一致したかを確認してください。

DNSも観測結果を変えます。redir-hostでは、ルール判定が実際の解決先アドレスにより強く依存することがあります。Fake-IPでは、コアが早い段階でドメインのコンテキストを保持できるため、ドメインルールが適用されやすくなります。LANのデバイス名、プリンターのドメイン、社内DNS、実IPに依存する一部のアプリについては、該当ドメインをFake-IPの除外項目に追加し、必要に応じて直結ルールを補ってください。

クライアントでIPv6も有効にしているのに、ルールがIPv4のプライベートネットワークしか対象にしていない場合、LANのIPv6接続が最終的なプロキシポリシーへ入ることがあります。ネットワーク環境に応じて IP-CIDR6 ルールを追加し、選択したプロキシノードが必要なIPv6接続に対応しているか確認してください。IPv6を完全に無効にすると一時的に現象が変わる可能性はありますが、すべての環境で固定的に行う処理ではなく、切り分けの手順として扱うのが適切です。

設定確認：構文チェックからルール一致の記録まで

YAMLはインデントに敏感です。リスト項目の前のスペース、コロンの後のスペース、名前の参照方法はいずれも読み込みに影響します。プロキシグループ名に日本語やスペースを含めることはできますが、ルールの宛先はプロキシグループ名と完全に一致させる必要があります。編集後はまずクライアントの設定チェック機能を使います。コマンドラインでmihomoを実行する場合は、設定ディレクトリを対象にテストすることもできます。

mihomo -t -d /etc/mihomo

テストに合格しても、設定を解析できることが分かるだけで、すべてのルールが想定どおりとは限りません。次の順番で確認するのがおすすめです。

  1. 設定を再読み込みし、プロキシグループが表示され、プロキシプロバイダーとルールセットに更新エラーがないことを確認します。
  2. ルーターの管理アドレスやLANデバイスへアクセスし、接続記録に DIRECT と表示されることを確認します。
  3. ドメインルールに明示的に追加したサイトへアクセスし、一致したルール名と宛先ポリシーを確認します。
  4. 国内でよく使うサイトへアクセスし、ドメインルールとGEOIPルールがそれぞれ有効になっているかを確認します。
  5. 明示的なルールを設定していない海外サイトへアクセスし、最終的に MATCH から「フォールバックトラフィック」へ渡されることを確認します。
  6. 「海外トラフィック」でノードを切り替えて再接続し、プロキシグループの選択が新しい接続に反映されることを確認します。

テストでは新しい接続を作成してください。既存のTCP、QUIC、長時間接続は以前の経路を使い続けることがあり、プロキシグループを切り替えてもすぐには移行しません。対象のタブやアプリの接続を閉じてから再アクセスすると、より確実な結果が得られます。ブラウザーがDNSをキャッシュしたり接続を再利用したりする場合もあるため、必要に応じてクライアントの接続パネルから古い接続を閉じてください。

ログに記録されたルール名は、「Webページを開けるかどうか」よりも診断に役立ちます。ページの読み込み失敗は、ノード、DNS、TLS、対象サーバー、ネットワーク経路などが原因かもしれません。まず一致したルールと宛先ポリシーを確認して初めて、問題がルール層にあるのかプロキシ経路にあるのかを判断できます。

よくあるルーティング異常と切り分けの順番

国内サイトがプロキシへ送られる

まず接続記録で対象ホストと一致したルールを確認します。MATCH に直接一致しているなら、前段のドメインセットとGEOIPのどちらでもカバーできていません。安定したドメインには DOMAIN-SUFFIX ルールを追加するか、GeoSite・GeoIPデータを更新します。接続記録にIPしか表示されない場合は、DNSモード、アプリがIPへ直接接続していないか、ドメインスニッフィング関連の設定を確認してください。

海外サイトが直結になる

範囲が広すぎる直結ルールがないか確認します。たとえば短すぎる DOMAIN-KEYWORD、誤ったドメインサフィックス、または早い位置にある MATCH,DIRECT などです。プロキシグループで現在 DIRECT が手動選択されていないかも確認してください。ルールが「海外トラフィック」に一致していても、そのグループ内で直結が選ばれていれば、必ずしもプロキシ接続になるとは限りません。

LANデバイスにアクセスできない

プライベートネットワークのルールが最終フォールバックより前にあることと、LANで実際に使っているアドレス帯を確認します。一般家庭のネットワークでは 192.168.0.0/16 がよく使われますが、オフィスネットワーク、仮想ネットワーク、コンテナでは 10.0.0.0/8 や 172.16.0.0/12 が使われることもあります。デバイス名でアクセスしている場合は、ローカルDNS、mDNS、検索ドメインがリモートの名前解決経路に干渉されていないことも確認してください。

サブスクリプション更新後にカスタムルールが消える

サブスクリプションから生成されたメイン設定を直接編集すると、更新時にクライアントがファイルを書き戻すことがあります。カスタム内容は、クライアントが対応するオーバーライド、Merge、スクリプト設定へ移してください。安定したルールを自分で管理するrule-providerに入れる方法もあります。更新は、サブスクリプションのノードを更新し、次にオーバーライドを読み込み、最後にルールセットを更新して設定チェックを実行する順番がおすすめです。

ルールは正しいのにアプリの接続記録がない

これは通常、ルールの並び順ではなく、トラフィックがClashに入っていないことが原因です。システムプロキシが有効か、アプリがプロキシ設定に従うか、端末にプロキシ環境変数が設定されているか、TUNモードが正常に起動しているかを確認します。TUNを使う場合は、ルーティングの競合、権限、他のVPNソフト、仮想ネットワークアダプターの状態も確認してください。まず接続をパネルに表示させてから、一致したルールを分析します。

メンテナンスしやすい設定の最終チェックリスト

  • LANとループバックアドレスのルールが地域別ルールより前にある。
  • 具体的なドメインルールが、広範なキーワードルールやGEOIPルールより前にある。
  • ルールが、変わりやすいノード名ではなく固定したプロキシグループを参照している。
  • MATCH はルールリストの末尾に1つだけ置き、明確なフォールバックポリシーを指定している。
  • ドメインルールセットとIPルールセットで、behaviorと内容形式が一致している。
  • IPv4、IPv6、DNSモード、トラフィックの取り込み方式が現在のネットワーク環境に合っている。
  • サブスクリプションの内容と個人用オーバーライドを分離し、更新後に構文チェックと一致テストを再実行できる。

地域別ルーティングに、すべてのネットワークで永久に使えるルールはありません。より確実なのは、まず明確な4層構造を作り、接続記録を見ながら少数の例外を追加する方法です。プロキシグループの命名が安定し、ルールの順序が読みやすく、フォールバックの動作が明確であれば、サブスクリプションのノードや地理データが更新されても、設定のメンテナンスコストを低く保てます。

Clashをダウンロード