Clashの国内外ルール振り分け設定：プロキシグループ・ルールセット・フォールバック順を実践解説

Clashのルール振り分けは、単純に「中国国内のドメインはDIRECT、海外のドメインはプロキシ」と設定すればよいものではありません。実際の接続先を決めるのは、ルールが通信を識別し、プロキシグループが出口を選び、プロキシノードまたは内蔵アクションが処理するという3層構造です。いずれかの名称、順序、参照関係が一致していないと、サイトが意図しない経路を通る、LANサービスまでプロキシされる、アプリの接続がタイムアウトする、ノードを切り替えても一部の接続だけ古い経路を使い続ける、といった問題が起こります。

以下の設定方針は、ルールモードに対応するClashクライアントで利用できます。また、Clash Metaの名称で広まった、現在一般にmihomoと呼ばれるコアにも対応します。クライアントによって画面上の項目名は異なり、コアのバージョンによって対応するルール種別、ルールセット形式、プロセス照合機能にも差があります。変更前に実際に使用しているコアを確認し、正常に起動できる設定を1つ保存しておきましょう。

まずDIRECT・プロキシ・REJECT・フォールバックのモデルを決める

保守しやすい中国国内外の振り分け設定では、少なくとも4種類の処理結果を明確にします。1つ目はDIRECTで、接続をローカルネットワークへ直接渡します。2つ目はPROXYなどのカスタムプロキシグループです。3つ目はREJECTで、アクセス不要と判断したドメインやネットワークを遮断します。4つ目は最終フォールバックで、前のルールに一致しなかったすべての通信を受け取ります。

DIRECTは「中国国内」と同じ意味ではありません。LANアドレス、プリンター、ルーターの管理画面、社内システムは通常直接接続が必要ですが、中国国内のサービスでも、アカウントの地域、社内ネットワークの出口、テスト要件によってプロキシを指定する場合があります。逆に、海外サイトでも現在のネットワークから直接アクセスできることがあります。そのため、地域ルールは広範囲の基本判定に使い、業務上の例外は地域ルールより前に置くのが適切です。

DIRECT

直接接続の出口

現在のシステムネットワークから直接接続します。LAN、よく利用する中国国内サービス、ローカル回線からのアクセスが必要な業務に適しています。

PROXY

プロキシグループ

選択したノードまたは自動選択グループに接続を渡します。グループ名はルール内の指定名と完全に一致させる必要があります。

REJECT

遮断アクション

一致した接続を直ちに拒否します。ログイン、決済、リソース読み込みに影響しないよう、対象範囲が明確なルールを使用してください。

MATCH

未一致通信のフォールバック

それまでのルールに一致しなかった接続を処理します。後続ルールに照合の機会を与えるため、必ずルール一覧の末尾に置きます。

プロキシグループでノード選択と業務目的を分離する

ルールにノード名を直接書いても動作しますが、保守性は高くありません。購読の更新でノード名が変わる可能性があり、複数のルールが同じノードに重複して紐づくこともあります。より安定した方法は、意味の分かるプロキシグループをルールから参照し、グループ側でノード、自動速度テストグループ、または別のプロキシグループを選択することです。

よくある構成は、総合入口のPROXY、自動速度テストグループのAUTO、手動選択グループ、そしてメディア、業務、開発サービスごとのグループです。業務ルールは業務用プロキシグループだけを参照し、ノードの変更はグループ内で行います。これにより、ルールファイルを安定して保ちつつ、クライアント画面から一時的に出口を切り替えられます。

mode: rule

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: MANUAL
    type: select
    use:
      - airport

上記のairportは、あらかじめproxy-providersで定義されている必要があります。useが参照するのはプロキシプロバイダーであり、ルールプロバイダーではありません。url-testはテスト結果に基づいて条件に合うノードを選びますが、遅延が最小のノードがすべての業務で最も高速とは限りません。接続先サービスが出口地域を要求する場合は、地域別グループまたは手動選択グループを作成し、全体の速度テストだけに頼らないでください。

PROXYでDIRECTも選べるようにすると、一時的な切り分けに便利です。ただし、そのグループを切り替えると、参照しているすべてのルールの出口が変わります。必ずプロキシを通す業務には、DIRECTを含めない専用グループを作成できます。必ず直接接続する通信は、ルールからDIRECTを直接指定し、総合グループの切り替えに影響されないようにします。

プロキシグループ名の表記は統一する

YAMLでは、名前の文字列が区別されます。ルールがPROXYで、プロキシグループ名がProxyの場合、同じ対象とはみなされません。日本語名、空白、記号も通常は使用できますが、クライアント間で移行する場合は、短い英大文字名のほうが確認しやすくなります。名前に特殊文字を含める場合は引用符を使い、ルール、プロキシグループ、スクリプトからの参照で同じ表記を維持してください。

ルールセット購読とプロキシグループの連携

rule-providersは、再利用可能なルールセットを宣言するために使います。ノード購読とは役割が異なり、ノード購読がプロキシサーバーの情報を提供するのに対し、ルールセットはドメイン、IPネットワーク、クラシックルールの項目を提供します。ルールセットだけでは出口は決まりません。rules内でRULE-SETを使って参照し、DIRECT、PROXY、または別のポリシーを指定して初めて接続の判定に参加します。

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/reject.yaml
    url: https://example.com/rules/reject.yaml
    interval: 86400

  cn-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml
    url: https://example.com/rules/cn-domain.yaml
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/cn-ip.yaml
    url: https://example.com/rules/cn-ip.yaml
    interval: 86400

サンプルURLは項目の構造を示すためだけのものです。実際の設定では、ルールの管理元が提供する元ファイルのURLを使用してください。pathはルールセットのローカルキャッシュ先で、クライアントには該当ディレクトリへの書き込み権限が必要です。intervalは通常秒単位で、1日に設定すると頻繁なリクエストを減らせます。更新間隔は上流のメンテナンス頻度に合わせて決めてください。短くしても照合精度は上がりません。

behaviorはルールセット内の項目を解釈する方法を決めます。domainはドメインやサフィックスの集合、ipcidrはIPv4・IPv6のネットワーク、classicalは種別付きのクラシックルールに適しています。ファイルの内容は宣言した形式と一致していなければなりません。ドメイン一覧をipcidrとして宣言したり、クラシックルールファイルを単なるドメイン集合として読み込んだりすると、解析に失敗したりルールが一致しなかったりします。

ルールの順序：具体的な例外から広範囲のフォールバックへ

Clashはルール一覧を上から順に確認し、最初に一致したルールで処理方針を直ちに決定します。すべてのルールを比較して「最も具体的な」ものを選ぶわけではありません。そのため、順序は「具体的な例外を前に、広範な集合を後ろに、最終フォールバックを末尾に」という原則で設計します。

基本的には、明示的な遮断、LANとプライベートアドレス、必ず直接接続する業務、必ずプロキシを通す業務、中国国内ドメインの集合、中国国内IPの集合、その他の地域またはプロキシの集合、最後にMATCHという順序がおすすめです。プロジェクトに応じて分類は調整できますが、広範囲のルールを、それがカバーする例外より前に置いてはいけません。

rules:
  - RULE-SET,reject-list,REJECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  - DOMAIN-SUFFIX,service-needs-proxy.example,PROXY
  - DOMAIN-SUFFIX,service-needs-direct.example,DIRECT

  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,PROXY
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  - MATCH,PROXY

上記の業務ドメインは順序を説明するための例です。運用時には、実際に制御したいドメインへ置き換えてください。「必ずプロキシを通す」ドメインが中国国内ドメインのルールセットにも含まれる場合は、cn-domainより前に置かなければなりません。そうしないと、先にDIRECTへ一致します。遮断ルールの範囲が広すぎると、後ろにプロキシルールがあっても、ログインAPI、静的リソース、認証コードのドメインまで先に拒否されます。

DOMAINは完全一致のドメイン、DOMAIN-SUFFIXは指定ドメインとそのサブドメイン、DOMAIN-KEYWORDはドメイン内にキーワードが含まれるかを照合します。キーワードルールは適用範囲が広く、名前が似ているだけで無関係なサイトに誤適用しやすいため、通常は完全なドメイン、サフィックス、または管理されたルールセットを優先します。

IP-CIDRとGEOIPはIPを基準に判定します。no-resolveを付けると、対象IPを取得するためにルールが追加の名前解決を開始するのを防げます。ただし、コアが対象IPをすでに取得している場合にだけ照合されます。このパラメーターを付けるかどうかは、DNSモード、接続メタデータ、コアの挙動を確認して判断し、すべてのルールに機械的にコピーしないでください。

MATCHはDIRECTとプロキシのどちらにするか

フォールバックの経路は設定の目的によって決まります。「中国国内は直接接続し、それ以外はプロキシ」という一般的な構成では、MATCH,PROXYを使うと、まだルールセットに登録されていない新しいドメインもまずプロキシグループへ渡せます。デフォルトは直接接続で、一部の業務だけプロキシを通す環境ではMATCH,DIRECTを使えますが、プロキシ対象のルールを漏れなく用意する必要があります。どちらが優れているというものではなく、未知の通信に対してどちらの出口がより安全に管理できるかが重要です。

DNSとTUNモードが振り分け結果に与える影響

ルールの順序が正しいのにアクセス結果が異常な場合は、DNSを確認する必要があります。ドメインリクエスト、名前解決の結果、実際の接続が異なる経路を通ることがあるためです。システムDNSがネットワーク環境の影響を受けたアドレスを返すと、ドメインルールが想定したポリシーに一致しても、その後の接続がタイムアウトする可能性があります。Clash内蔵DNSを使う場合は、nameserver、proxy-server-nameserver、フォールバックDNS、ルール振り分けの関係を確認し、コアログで実際にどのサーバーへ問い合わせが渡ったかを確認してください。

fake-ipモードでは、コアがアプリに予約済みアドレスを返し、接続時にマッピングから元のドメインを復元します。これによりドメインルールを安定して判定に使えますが、一部のLAN機器、LANドメイン、ゲームプラットフォーム、実IPに依存するアプリではfake-ip-filterへの追加が必要になる場合があります。除外項目を無制限に増やしてはいけません。範囲が広すぎると、より多くのリクエストが実IPでの名前解決へ戻り、ドメイン振り分けの一貫性が低下します。

redir-hostモードは、実際に解決したアドレスをアプリへ直接返します。経路はfake-ipとは異なります。モードを切り替えた後も、古いDNSキャッシュや既存の接続が残ることがあるため、テスト前に対象アプリの接続を切断し、OSに応じてDNSキャッシュを消去してください。ブラウザーのページを更新するだけでは、完全な接続経路が再構築されない場合があります。

TUNモードは、より多くのシステム通信を取り込むためのもので、ルールを上から順に照合する基本的な仕組みを変えるものではありません。TUNを有効にすると、これまでシステムプロキシを回避していたアプリもClashを経由する可能性があり、ルールの一致件数が増えます。アプリが宛先IPしか提供しない場合、ドメインルールに利用できるメタデータがないことがあります。スニッフィングに対応したコアは、一部のHTTPやTLS通信からホスト情報を復元できますが、すべてのプロトコルで有効とは限りません。

「ブラウザーの振り分けは正常なのに、コマンドラインやデスクトップアプリだけ経路が違う」場合は、そのプログラムがコアに取り込まれているか、TUNルートが有効か、ドメインが認識されているか、最終的にどのルールへ一致したかを順に確認します。Webページに表示された出口アドレスだけでシステム全体を判断しないでください。プロセスによって、システムプロキシ、直接ソケット、QUIC、独自DNSを使う場合があります。

アクセス結果を推測せず、接続ログで検証する

振り分け設定が完了したら、最も有効なのはクライアントの接続パネルまたはコアログを確認することです。テストごとに、対象ホスト、一致したルール、選択されたプロキシグループ、実際のノード、接続結果を記録します。「開ける」ことだけではルールが正しい証拠になりません。対象が直接接続に対応している場合もあれば、キャッシュ、代替ドメイン、すでに確立された長時間接続が使われている場合もあります。

設定が読み込まれていることを確認します。設定の更新時刻とコアログを確認し、YAMLのインデント、フィールド名の誤り、ルールセットのダウンロード、プロキシグループの参照エラーを切り分けます。
テスト時のポリシーを固定します。一時的にPROXYで状態が明確なノードを選択し、テスト中に自動速度テストグループが出口を切り替えないようにします。
LANとプライベートアドレスをテストします。ルーターの管理画面、LAN機器、内部ドメインがDIRECTに一致することを確認し、TUNが予約済みネットワークを誤って取り込んでいないか確認します。
中国国内のドメインとIPをテストします。ドメインルールセット、IPルールセット、GEOIPのどれに一致したかを確認します。直接MATCHへ到達する場合は、ルールセットの内容またはドメイン認識の経路を確認してください。
プロキシ強制の例外をテストします。中国国内の広範な集合より前に置かれていること、前方のサフィックスルールに先取りされず、指定したプロキシグループに実際に一致することを確認します。
未知のドメインをテストします。カスタムルールに含まれない対象を選び、最終的にMATCHが受け取ることを確認して、フォールバックポリシーを検証します。

よくある症状と確認ポイント

症状	まず確認する項目	対処の方向性
中国国内のサイトがプロキシ経由になる	中国国内ルールセットが読み込まれているか、MATCHより前にあるか	プロバイダーの状態、ルール参照名、ドメインが実際に一致した項目を確認する
指定したドメインをプロキシ経由にできない	前方に、より広い直接接続用サフィックスルールがないか	具体的なプロキシ例外を、広範な直接接続集合より前へ移動する
LANアドレスへの接続がタイムアウトする	プライベートネットワークのルールとTUNルート	プライベートアドレスの直接接続を追加し、自動ルートとインターフェース選択を確認する
ルールセットの更新に失敗する	URLのレスポンス、形式、behavior、キャッシュディレクトリ	ルールファイルが返されていることを確認し、コアの対応状況とディレクトリ権限を確認する
プロキシグループを切り替えても結果が変わらない	既存の接続、DNSキャッシュ、アプリの接続プール	古い接続を終了してから再テストし、必要に応じてシステムDNSキャッシュを消去する

長期運用する設定では、カスタム例外、共通ルールセット、フォールバックルールを分けて管理するのがおすすめです。カスタム例外は通常少数なので、用途の説明を添えてメイン設定に記述します。共通のドメイン・IP集合はルールプロバイダーに更新を任せ、フォールバックポリシーは固定します。問題が起きたときに、ローカルの例外、リモート集合、出口ポリシーのどこが変わったのかをすばやく判断できます。

変更するたびに、調整する層を1つに絞ります。まずプロキシグループが接続できることを確認し、次にルールセットを読み込めることを確認し、最後にルールの順序を調整します。DNS、TUN、ルールプロバイダー、プロキシグループを一度に変更すると、ログに複数の変数が現れ、真の原因を特定しにくくなります。設定項目とクライアントの操作をさらに確認する場合は、設定詳細ガイドと使い方ガイドを項目ごとに照合してください。