2026-09-09 ルール振り分け読了目安：12分

Clashのルール分岐設定ガイド｜国内直結・海外プロキシのrulesとrule-providers

よくある振り分け例をもとに、ルールの上から順に行われるマッチング、プロキシグループの指定方法、rule-providersで管理するリモートルールセットの構成を解説します。ルールの順番を誤って、通信が意図しない経路に流れるのを防ぎます。

まず振り分けの範囲を確認：ルールモード、通信の入口と出口

「ローカル通信は直接接続、海外向け通信はプロキシ経由」という設定は、3つに分けて考えます。LAN内のアドレスはDIRECTへ、国内サイトと明確に判断できる通信はドメインまたはIPの情報に基づいて直接接続し、それ以外はプロキシグループへ送ります。ここでいう「ローカル」にはルーター、NAS、イントラネット上のサービスが含まれます。「国内サイト」とは別の対象です。まずこの2つを区別すれば、社内ネットワークへのアクセスが遠隔ノード経由になるのを防げます。

この記事の例はmihomoコアを対象にしています。Clash NyanpasuはGUIクライアントであり、rulesを実際に処理するのは起動中のコアです。旧バージョンのClashでは、一部の項目、とくにここで使用するinclude-allの対応状況が異なります。mihomo向けの設定を、同じ名前のすべてのクライアントにそのまま適用しないでください。

プロキシモード：「ルール / Rule」を選択します。グローバルモードでは、この記事の通常の振り分けルールに従って出口を選びません。DIRECTモードでは、プロキシへのフォールバックも行われません。
通信の入口：ブラウザーでクライアントのプロキシポートを使用するか、TUNで通信を取り込む必要があります。システムプロキシでは、すべてのアプリの通信を処理できるとは限りません。
プロキシグループの出口：ルールがプロキシグループにマッチしても、使用可能なノードが選択済みとは限りません。グループ内で現在選択されている項目も確認してください。
設定の読み込み元：現在有効なサブスクリプションを確認し、オーバーライドやマージスクリプトによって最終的なルールが変更されていないか調べてください。

作業前に、使用中の設定をバックアップしてください。サブスクリプション管理機能によって、更新時に設定が再生成される場合があります。クライアントが対応する永続的なオーバーライドやマージ機能でカスタムルールを保存し、一時生成ファイルだけを編集するのではなく、最終的に適用される設定を確認しましょう。

rulesの評価順：具体的な例外を先に、MATCHは最後に

通常のrulesリストは上から順に評価され、最初にマッチしたルールのポリシーが適用されます。後続の「より具体的な」ルールまで検索されることはありません。ドメイン名の長さやIPネットワークの範囲に応じて、自動で並べ替える仕組みもありません。たとえば、サイト全体に適用されるサフィックスルールを先に置くと、後ろにある個別サブドメインの例外はマッチしなくなります。

ルールタイプ	例	マッチ対象
DOMAIN	`DOMAIN,example.com,DIRECT`	指定した完全一致のドメインのみ
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,プロキシ出口`	ルートドメインとそのサブドメイン
IP-CIDR	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	指定したIPv4ネットワーク
GEOIP	`GEOIP,CN,DIRECT`	この端末のIP位置情報データベースに基づいて判定
MATCH	`MATCH,プロキシ出口`	前のルールにマッチしなかった通信をすべて処理

ドメインの例外ルールでサフィックスルールを上書きする

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,プロキシ出口
  - MATCH,プロキシ出口

このルールでは、example.comは直接接続し、www.example.comはプロキシ出口へ送ります。2行を入れ替えると、ルートドメインも先にサフィックスルールへマッチします。例示用のドメインはマッチの仕組みを示すためのもので、実際の設定に追加する必要はありません。

no-resolveは、このIPルールの判定のためにドメインを積極的にIPアドレスへ解決しない、という意味です。接続中のDNS問い合わせをすべて禁止するものではありません。接続に宛先IPアドレスが含まれていれば、そのIPに基づいてルールを判定できます。LANのネットワーク範囲に適用すると、イントラネットのアドレス確認時に不要な名前解決を避けられます。

ローカル通信の直接接続と海外向けプロキシ：確認可能な設定例

以下は既存のmihomo設定にマージするための断片であり、ノード、DNS、待ち受けポートを含む完全なサブスクリプション設定ではありません。既存のproxiesまたはproxy-providersを残し、プロキシグループとルールを追加してください。同じ名前のトップレベル項目がすでにある場合は、既存の項目を編集します。rules:を重複して追加しないでください。

mode: rule

proxy-groups:
  - name: プロキシ出口
    type: select
    include-all: true
    proxies:
      - DIRECT

rules:
  # 個別の例外：ドメイン情報が利用できる場合に優先して判定
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,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-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve

  # 中国国内のIPは直接接続し、それ以外の通信はプロキシグループへ
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ出口

ノードを選択してからプロキシ接続を確認

include-all: trueを指定すると、このmihomoプロキシグループに既存ノードとプロキシプロバイダー内のノードが含まれます。例では選択肢としてDIRECTも残しています。適用後は「プロキシ出口」グループで使用可能なノードを必ず選択してください。DIRECTが選択されたままだと、ログにMATCHと表示されても最終的には直接接続します。ノードをまだインポートしていない場合、この設定だけでプロキシ接続が利用可能になるわけではありません。

既存の設定に使用可能なプロキシグループがある場合は、そのグループを残し、ルール内の「プロキシ出口」を正確なグループ名に置き換えるのが簡単です。名前は大文字と小文字を区別し、スペースも名前の一部です。例に合わせるために、サブスクリプションに含まれる自動選択グループを削除しないでください。

この基本的な振り分け設定で判断できる範囲

GEOIP,CNが判定するのは宛先IPアドレスのデータベース上の所在地です。サイトの言語、企業の登記地、トップレベルドメインを判定するものではありません。
中国国内のサービスが海外のCDNを利用することもあれば、海外のサービスに中国国内のIPアドレスが割り当てられることもあります。そのため、意図した振り分けにはドメインのルールセットも必要です。
GEOIPの判定には利用可能なローカルデータベースが必要です。ファイルがない、または読み込みに失敗する場合は、まず問題を修復してください。ルールの読み込み失敗を通常のフォールバックとして扱わないでください。
イントラネットのドメインは、正しく名前解決できる必要があります。DIRECTを指定しても、クライアントに企業DNSが追加されたり、NASが自動検出されたりするわけではありません。

ここではGEOIPルールにno-resolveを指定していないため、必要に応じてドメインを解決し、中国国内のIPかどうかを判定できます。その代わり、一部の通信では先にローカルDNSへの問い合わせが発生します。名前解決の経路を厳密に制御する場合は、DNSポリシーもあわせて設計してください。「プロキシ出口を通る」ことと「DNSも必ずプロキシ経由になる」ことは同じではありません。

rule-providersの設定：リモートルールセットとbehavior

ルールが多い場合は、ドメインリストをメイン設定から分離できます。rule-providersではルールセットの取得元、形式、更新方法を定義し、RULE-SETでルールリストから参照します。プロバイダーを定義しただけで参照ルールを書かなければ、通信の出口は変わりません。

以下では、公開されているLoyalsoldierの直接接続用ドメインルールセットを使い、HTTPプロバイダーの設定例を紹介します。このリストはメンテナーが選定した直接接続の推奨リストであり、中国国内の通信範囲を厳密に示すものではありません。利用前に対象範囲が用途に合っているか確認してください。アドレスはコアが設定に従ってルールを取得するためのもので、ページが自動的にアクセスすることはありません。

rule-providers:
  direct-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/direct-domains.yaml
    interval: 86400

interval: 86400の単位は秒です。24時間ごとに更新を確認します。pathはコアの作業ディレクトリ内にあるキャッシュファイルの場所で、現在のWebページからの相対パスではありません。初回読み込み時にはリモートデータを取得できるか、利用可能なキャッシュが必要です。ダウンロードに失敗しても、必ずルールをスキップして起動するとは限りません。

ルールセットを適切な位置に組み込む

前のセクションの個別例外とLAN向けルールを残し、その後、GEOIPルールの前に次の1行を追加します。ここではリストの末尾部分のみを示しています。既存のイントラネット向けルールを削除して、この例で置き換えないでください。

  - RULE-SET,direct-domains,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,プロキシ出口

推奨する順番は「個別例外 → LAN → 直接接続用ドメインセット → 中国国内IP → プロキシへのフォールバック」です。ドメインが直接接続リストに含まれていてもプロキシを使いたい場合は、RULE-SETより前に明示的なドメインルールを追加します。MATCHの後ろに置いた例外は適用されません。

behaviorとファイルの内容を一致させる

behavior	YAML payloadの例	対象となる内容
domain	`'+ .example.com'`は、プラス記号の後の空白を除いた`'+.`形式のドメイン指定	規定のワイルドカード構文に対応する、ドメインのみのルールセット
ipcidr	`'192.168.0.0/16'`	IPネットワークの集合
classical	`'DOMAIN-SUFFIX,example.com'`	ルールタイプを含む従来形式のルールセット

たとえば、ローカルにあるbehavior: domain、format: yamlのファイルは、次のように記述できます。+.example.comはルートドメインとそのサブドメインにマッチします。通常のrulesで使う3要素の形式と混同しないでください。

payload:
  - '+.example.com'
  - 'example.net'

classicalの内容は、DOMAIN-SUFFIX,example.comのようなマッチ条件で記述します。各payload項目の末尾にDIRECTを追加する必要はありません。使用するポリシーは、外側のRULE-SET,ルールセット名,ポリシーで指定します。ファイルの拡張子だけでは実際の形式を判断できません。上記のリモートURLは.txtで終わりますが、内容はYAML payloadです。

3種類の通信で確認：イントラネット、国内サイト、プロキシへのフォールバック

設定を保存しても、編集が完了しただけで、新しいルールが通信に適用されたとは限りません。再読み込み後、まずクライアントの設定画面で現在有効なプロファイルを確認し、接続一覧とコアのログを調べてください。画面の名称はバージョンによって異なる場合があります。「接続にマッチしたルールと最終的な出口経路を確認する」ことを目的にし、モードボタンの表示だけで判断しないでください。

LANをテスト：ルーターの実際のアドレスが192.168.1.1の場合、プロキシの入口からアクセスして、192.168.0.0/16にマッチし、DIRECTと表示されることを確認します。家庭内ネットワークのゲートウェイがすべてこのアドレスとは限りません。
中国国内サイトをテスト：国内サイトへの接続を新たに開始し、direct-domainsまたはGEOIP CNにマッチするか確認します。MATCHになった場合は、対象ドメインがリストに含まれているかを確認してから、名前解決されたIPアドレスの所在地を調べてください。
プロキシへのフォールバックをテスト：直接接続用のリストに含まれない海外サイトにアクセスし、MATCHにマッチすることを確認します。出口経路がDIRECTで止まらず、選択した実際のノードにつながっている必要があります。
例外ルールをテスト：一時的に指定した完全一致ドメインのルールをリストの先頭に追加し、接続を開始し直して、ルールセットより先にマッチすることを確認します。テスト後は、不要な一時ルールを削除してください。

curlで使用するプロキシポートを指定する

実際の設定がmixed-port: 7890の場合、以下のコマンドでHTTPプロキシの入口を明示的に通る接続を発生させられます。ポート番号は現在有効な設定を確認してください。7890がすべての環境で固定値というわけではありません。Windows PowerShellでは、コマンドの別名による違いを避けるためcurl.exeを使えます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

このコマンドは、通信が実際にローカルの入口を通ることを確認するためのものです。特定のサイトが必ずプロキシ経由になるべきだと証明するものではありません。接続一覧でリクエスト時刻、対象ドメイン、マッチしたルール、出口経路の4点を照合してください。SOCKS専用の入口には、対応するポートを指定します。socks5h://を使うとドメイン名の処理をプロキシ側に任せられるため、テストツールが先にローカルで名前解決し、確認結果に影響するのを避けられます。

ルールを変更しても、すでに確立したTCP接続の出口が再選択されるとは限りません。ブラウザーの接続プール、HTTP/2、QUICではセッションが再利用される場合があります。テスト前に関連する既存接続を終了してから新しいリクエストを送ってください。そうしないと「ルールが適用されない」と誤判定しやすくなります。

ルール振り分けが機能しないときの確認項目

プロキシグループにマッチしても直接接続される

まず、プロキシグループの最終的な出口を展開して確認します。手動選択グループでDIRECTが選ばれていたり、ネストされた別の選択グループの最終出口がDIRECTになっていたりする場合があります。完全な経路に実際のプロキシノードが表示されて初めて、そのノードに通信が渡されたと判断できます。グループ名が「プロキシ出口」でも、プロキシ経由を強制する効果はありません。

設定は保存できるが、リモートルールセットが使えない

ログでプロバイダー名、HTTPステータス、解析エラーを確認します。ステータスコード403はサーバーによるリクエスト拒否、404は通常、パスやブランチの誤りを示します。HTMLのエラーページが返された場合、HTTPリクエストが完了していても有効なルールを取得できたとは限りません。サブスクリプションのプロキシノード用URLをルールプロバイダーに設定しないでください。データ形式が異なります。

ブラウザーは正常だが、ゲームやコマンドラインの通信がルールに従わない

まず接続一覧に該当する通信があるか確認します。記録がない場合は、アプリがシステムプロキシを使用しているか、独自に直接接続しているか、TUNが実際に通信を取り込んでいるかを優先して調べてください。TUNは通信の入口を広げる機能であり、rulesの順序を自動で修正するものではありません。UDP通信には入口、コア、ノードの経路がすべて対応している必要があります。

IPアドレスでは直接接続できるが、イントラネットのドメインが開けない

この場合は、名前解決を確認してください。printer.home.arpaのレコードはルーターまたは企業DNSから提供されていますか？アプリはシステムのリゾルバーを使っていますか、それとも独自の暗号化DNSを使っていますか？ドメインが正しいイントラネットIPアドレスに解決されていなければ、DIRECTルールを追加しても名前解決の問題は解決しません。また、.localはmDNSに関連することが多いため、一般的なユニキャストDNSのサフィックスとして単純に扱わないでください。

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

変更が永続化されるオーバーライド層に保存されているか確認し、マージルールも調べてください。配列への追加を行う場合もあれば、配列全体を置き換える場合もあります。カスタムルールが既存のMATCHの後ろに追加されると、設定に残っていても実際にはマッチしません。更新のたびに、リストの先頭、RULE-SETの参照、最後のMATCHを確認してください。

ルールの管理では、内容を説明しやすい少数の例外を優先して残し、複数のドメインは提供元が明確なルールセットに任せ、接続ログで結果を確認しましょう。基本設定は使い方ガイドをご覧ください。DNS、TUN、コアの設定項目の関係を確認する場合は、技術リファレンスも参照してください。ルールを増やせば精度が上がるわけではありません。入口、評価順、最終的な出口をそろえることが、安定した振り分けの基本です。