Clashのルール分岐設定を実践：国内は直接接続、海外はプロキシ経由にするrules記述とプロキシグループ設計

まずルール分岐の実行モデルを確認する

ClashとClash Meta（mihomo）のルールシステムは、リストの上から下へ順番に評価されます。接続が最初の条件一致ルールに該当すると、それ以降のルールは判定されません。そのため、設定結果はどのルールを書くかだけでなく、各ルールをどこに置くかにも左右されます。

国内サイトは直接接続、海外サイトはプロキシ経由にする構成では、「細かな例外を先に、広いルールを後に」並べるのが基本です。まずLANと直接接続が必要なドメインを処理し、次に拒否ルールと指定プロキシのドメインを処理します。その後、国内ドメイン、国内IPを照合し、最後に MATCH で未一致の通信を受けます。

rules:
  - DOMAIN,router.asus.com,DIRECT
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,github.com,海外プロキシ
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

www.qq.comへのアクセスは DOMAIN-SUFFIX,qq.com,DIRECT に一致します。GitHubへのアクセスは「海外プロキシ」グループへ送られ、名前解決後に中国本土のアドレスと判定されたその他の接続は GEOIP,CN,DIRECT が処理します。残りの通信は最終的に「海外プロキシ」へ渡されます。

3種類のアクションの意味

DIRECT：プロキシノードを経由せず、本体または現在のゲートウェイから直接接続します。
REJECT：カーネルが接続を拒否します。確認済みの広告ドメイン、トラッキングドメイン、アクセス不要な宛先に適しています。
プロキシグループ名：接続を指定したグループへ渡します。たとえば「海外プロキシ」「自動選択」「フォールバック」などです。具体的なノードはグループ内で決まります。

ルールの3番目の項目は、プロキシグループ名と中国語、スペース、大文字・小文字を含めて完全に一致させる必要があります。ルールが 海外プロキシ なのに、proxy-groups の実際の名前が 海外ノード だと、カーネルの検証時にプロキシグループが存在しないというエラーが表示されることがあります。

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの選び方

ドメインルールはIPルールより分かりやすく、サイト単位の振り分けに適しています。ルールタイプを選ぶときは、境界の明確なマッチ方式をできるだけ使い、短いキーワードが無関係な多数のドメインに影響しないようにしましょう。

ルールタイプ	マッチ範囲	適した用途
`DOMAIN`	完全なドメイン名だけに一致	特定のAPI、ダウンロードドメイン、イントラネットホストを個別に処理
`DOMAIN-SUFFIX`	メインドメインとサブドメインに一致	1つのサイトが提供する大部分のサービスを処理
`DOMAIN-KEYWORD`	ドメインに指定文字列を含む場合に一致	ドメインの規則性は明確だが、サフィックスではまとめられない限定的なケース

rules:
  - DOMAIN,api.example.net,海外プロキシ
  - DOMAIN-SUFFIX,example.org,海外プロキシ
  - DOMAIN-KEYWORD,cdnvideo,海外プロキシ

DOMAIN,api.example.net はこの完全なホスト名だけに一致し、www.example.net には自動的に一致しません。DOMAIN-SUFFIX,example.org は example.org、www.example.org、static.example.org に一致します。一方、DOMAIN-KEYWORD は適用範囲を直接把握しにくいため、使用数を制限してください。

局所的な例外は広いサフィックスより前に置く

同じサイトの大部分のリクエストをプロキシ経由にしつつ、ダウンロードサーバーだけを直接接続にする場合は、完全なドメイン名の例外を先に書き、その後にドメインサフィックスを記述します。

rules:
  - DOMAIN,download.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,海外プロキシ
  - MATCH,海外プロキシ

この2つのルールを入れ替えると、download.example.org は先にサフィックスルールへ一致し、直接接続の例外は適用されません。rulesを変更した後に「ルールは存在するのに実際には実行されない」場合の、よくある原因です。

手動選択・速度テスト・フォールバックをプロキシグループで分ける

rulesは通信をどのポリシーへ送るかを決め、proxy-groupsはそのポリシーでどのノードを使うかを決めます。多数のルールにノード名を直接書いても動作しますが、ノードの更新や名前変更のたびに個別修正が必要です。より安定した方法は、ルールの参照先をプロキシグループに統一し、ノードをグループ側で管理することです。

proxy-groups:
  - name: 海外プロキシ
    type: select
    proxies:
      - 自動選択
      - フォールバック
      - 香港ノード A
      - シンガポールノード A
      - DIRECT

  - name: 自動選択
    type: url-test
    proxies:
      - 香港ノード A
      - シンガポールノード A
      - 日本ノード A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: フォールバック
    type: fallback
    proxies:
      - 香港ノード A
      - シンガポールノード A
      - 日本ノード A
    url: https://www.gstatic.com/generate_204
    interval: 300

select、url-test、fallbackの違い

select：グループ内の項目をユーザーが手動で選択します。rulesから最終的に参照する総合的な入口に適しています。
url-test：グループ内のノードを定期的にテストし、遅延の低い利用可能な項目を選びます。例では300秒ごとにテストし、tolerance: 50 は遅延差が50ミリ秒未満の場合に頻繁な切り替えを抑える設定です。
fallback：リスト順に、最初に利用できるノードを使います。単純に最低遅延を追求するのではなく、固定した優先順位を重視します。

遅延テスト用URLには、サイズが小さく応答状態が安定したものを指定します。1回の速度テストで分かるのはテスト先への往復時間だけで、動画のスループットやすべてのサイトの接続品質を直接示すものではありません。実際にノードを選ぶ際は、5〜10分間の接続失敗率、ページの最初のレスポンスまでの時間、ダウンロード速度も確認してください。

国内直接接続と海外プロキシの完全なrules順序

GEOIP,CN,DIRECT だけでは、国内のすべてのサービスをカバーできません。GEOIPは宛先IPの所属地域を基準に判定するため、接続がIPマッチング段階に入って初めて機能します。サイトによっては国際CDN、グローバルAnycast、海外アドレスを使用しており、国内ユーザー向けのサービスでもCNアドレスデータベースに該当しない場合があります。そのため、よく使う国内ドメインのルールは通常、GEOIPより前に置きます。

rules:
  # ローカルネットワークと予約アドレス
  - 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

  # 明示的なドメインアクション
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,weixin.qq.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,github.com,海外プロキシ
  - DOMAIN-SUFFIX,githubusercontent.com,海外プロキシ

  # IP地域判定と最終フォールバック
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

no-resolve は、IPルールを実行する際、ルール照合だけを目的とした追加のドメイン名前解決を行わないようカーネルに指示します。すでに宛先IPを取得している接続やLANのアドレス範囲に適していますが、通常のDNS設定の代わりにはなりません。ドメイン判定に依存するリクエストでは、ClashのDNSモジュールが安定して結果を取得できることを確認してください。

LANルールを前方に置く理由

プリンター、NAS、ルーターの管理画面、LAN上の開発サービスでは、通常 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 が使われます。これらのアドレスがフォールバックルールで遠隔プロキシへ送られると、接続がタイムアウトしやすくなります。TUNモードはより広範なシステム通信を処理するため、プライベートアドレスを明示的に直接接続へ残すことが重要です。

企業内ネットワークで独自のアドレス範囲を使っている場合は、実際の範囲も追加します。たとえば社内ネットワークのサービスが 100.64.20.0/24 にあるなら、IP-CIDR,100.64.20.0/24,DIRECT,no-resolve を追加できます。ただし 100.64.0.0/10 は通信事業者級NATにも使われるため、ネットワーク構成を把握しないまま直接接続の範囲を広げないでください。

RULE-SET：大規模なルールを独立ファイルに分ける

ドメインが数百、数千件に達すると、メイン設定を直接管理するのは難しくなります。mihomoは rule-providers でルールセットを読み込み、rules内で RULE-SET を参照できます。これにより、広告拒否、国内ドメイン、プロキシドメイン、プライベートネットワークを分けて管理できます。

rule-providers:
  reject-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/reject-domain.yaml

  domestic-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/domestic-domain.yaml

rules:
  - RULE-SET,reject-domain,REJECT
  - RULE-SET,domestic-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

対応するdomainタイプのルールファイルではpayloadリストを使用できます。以下は形式を説明するための内容です。実際に導入する際は、確認済みのドメイン集合に置き換えてください。

payload:
  - '+.ads.example.test'
  - '+.tracker.example.test'
  - 'metrics.example.test'

behavior: domain はドメイン集合、behavior: ipcidr はIPv4・IPv6のアドレス範囲、behavior: classical はルールタイプ付きの従来形式の項目に適しています。behaviorはルールファイルの内容と一致させる必要があります。IP範囲をdomain集合に入れると、読み込みに失敗したり一致しなかったりします。

リモートルールセットの更新方針

HTTPタイプのproviderを使う場合は、通常 url、ローカルキャッシュの path、更新間隔の interval を指定します。たとえば interval: 86400 は86400秒ごとに更新を確認する設定です。短時間ルールソースへ接続できない場合、カーネルは通常キャッシュ済みファイルを使い続けます。初回起動時にローカルキャッシュがなければ、読み込みを完了できないことがあります。

広告拒否ルールは国内直接接続の集合より前に置きます。そうしないと、両方の集合に含まれるドメインは先にDIRECTへ一致します。ログイン、決済、認証コード、メディア再生などの重要なリクエストを、ドメインに ad や track などの文字列があるという理由だけで拒否するのは避けてください。ページの一部が表示されない場合は、まず接続ログでREJECTされたホストを特定し、正確な許可ルールを追加します。

rules:
  - DOMAIN,login.example.test,DIRECT
  - RULE-SET,reject-domain,REJECT
  - RULE-SET,domestic-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,海外プロキシ

DNS、TUNモード、ルール結果の関係

システムプロキシモードは、主にHTTPまたはSOCKSプロキシ設定に従うアプリを処理します。一方、TUNモードは仮想ネットワークカードを通じて、より多くのTCP・UDP通信を処理します。どちらのモードでも同じrulesを使えますが、DNSの解決経路と通信の対象範囲は異なります。

fake-ipモードで予約アドレスが表示されても正常か

enhanced-mode: fake-ip を有効にすると、クライアントはまずアプリへ 198.18.0.0/15 の範囲にあるマッピングアドレスを返し、その後カーネルが元のドメイン名に基づいてルールを実行することがあります。これは対象サイトが実際にそのアドレス範囲にあることを意味しません。調査時はアプリに表示された宛先IPだけで判断せず、接続詳細のHost、Rule、Rule Payloadを確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853

例では、ローカルの53番ポートで動作するサービスとの直接的な競合を避けるため、Clash DNSを1053番ポートで待ち受けさせています。実際のクライアントは通常、待ち受けアドレスとDNSハイジャックを自動管理します。上書きの仕組みを理解しないまま、グラフィカルな設定画面とサブスクリプションの元ファイルを同時に変更しないでください。

TUNを有効にするとLANへアクセスできない

まず、プライベートネットワークのDIRECTルールがMATCHより前にあることを確認し、次にTUNのルート除外、厳格ルート設定、DNSハイジャックを確認します。mihomoでよく使われるDNSハイジャックの記述には any:53 があり、TUNに入った53番ポートの問い合わせをカーネルで処理するためのものです。ローカルでAdGuard Home、systemd-resolved、企業VPNのDNSを同時に動かしている場合は、複数サービスが同じポートを奪い合わないようにしてください。

設定の検証、マッチング確認、よくあるエラー

変更後は、まず構文を検証してから設定を再読み込みします。mihomo 1.19.xでは、コマンドラインから設定ディレクトリを指定してテストできます。インストール方法によってバイナリ名やディレクトリは異なる場合があります。

mihomo -t -d /etc/mihomo

テストに成功したら、クライアントで「設定」→「再読み込み」を実行するか、サーバーで対応する再起動コマンドを実行します。デスクトップクライアントによっては、設定ディレクトリへの入口が「設定」→「設定ディレクトリ」にあります。サブスクリプション設定を更新すると、直接編集したファイルが上書きされることがあります。長期的に使うカスタムルールは、クライアントが対応する上書き設定、マージ設定、または個別管理のproviderファイルに入れてください。

ルールに一致しない場合の確認手順

接続ページで対象ドメインを見つけ、実際に一致したRuleとポリシーグループを記録します。
対象ドメインがCNAME転送を経由していないか確認します。実際に接続するホストは、ブラウザーのアドレスバーとは異なる場合があります。
rulesの上に、より広いDOMAIN-SUFFIX、RULE-SET、GEOIPルールがないか検索します。
ルールが参照するプロキシグループ名が proxy-groups と完全に一致していることを確認します。
設定を再読み込みし、現在有効なのが変更後の設定ファイルであることを確認します。
アプリ自体のDNSキャッシュを消去するか古い接続を切断してから、新しいリクエストを送信します。

国内サイトがなおプロキシ経由になる

まず、GEOIPより前にプロキシルールセットへ一致していないか確認します。ドメインルールがない場合は、対象IPがCNとして判定されているか確認してください。グローバルCDNを使うサイトは海外アドレスへ解決されることがあるため、GEOIPやIP-CIDRの範囲を広げるのではなく、主要なサービスドメインにDOMAIN-SUFFIXの直接接続ルールを追加します。

海外サイトが断続的に直接接続される

広すぎる国内ドメイン集合、キーワードルール、カスタムIP直接接続範囲がないか確認します。また、ブラウザーで独自のセキュアDNSが有効になっていないかも確認してください。ドメイン解決と接続を別のソフトが処理すると、ログに想定したドメイン情報が残らないことがあります。調査中は一時的にClash DNSへ統一し、その後ほかのDNS設定を1つずつ戻します。

プロキシグループにノードはあるが利用不可と表示される

ノード自体とヘルスチェック先をそれぞれテストします。すべてのノードが同時に失敗する場合、テスト先が現在のネットワークで制限されているだけで、ノード全体が停止しているとは限りません。安定した小容量レスポンスのURLへ変更し、テスト間隔は300〜600秒にして、頻繁な探査による接続数の増加を避けます。

保守しやすい分岐設定に必要な条件

安定したルール設定は項目数を増やすことではなく、優先順位を明確に保つことが重要です。プライベートネットワークと正確な例外を先に置き、拒否集合とサービスドメインを続け、国内ドメインとGEOIPで広い範囲を分類し、MATCHで最終的に受けます。プロキシノードはselect、url-test、fallbackなどのプロキシグループで一元管理し、rulesが頻繁に変わるノード名へ直接依存しないようにします。

調整するたびに1つの階層だけを変更し、接続ログで検証することをおすすめします。DNSモードの変更、TUNの有効化、ルールセットの入れ替え、プロキシグループの変更を一度に行うと、原因を特定しにくくなります。「構文検証、再読み込み、新しい接続の発生、マッチしたルールの確認」の順にテストすれば、問題がルール順序、DNS、ノード、システムの処理範囲のどこにあるかを通常数分で判断できます。