Clashの国内・海外向けルール設定｜GEOIP・GEOSITE・RULE-SETの実践ガイド

まずカーネルとルールモードを確認

中国本土と海外の通信振り分けは、「中国本土は直接接続」というルールを1つ追加するだけでは実現できません。ドメインの分類、IPアドレスの判定、個別の例外、最後の接続先がそれぞれ異なる役割を担います。実用的な設定では、まず明示した例外を処理し、次に中国本土のドメインを照合します。その後、中国本土のIPアドレスで漏れを補い、残りの通信を指定したポリシーグループに振り分けます。

この記事の設定はClash Meta、現在のmihomoカーネルを対象としています。Clashはカーネルやクライアントのエコシステムを指す一般的な呼称であり、すべての旧カーネルが同じ設定項目に対応しているわけではありません。特にGEOSITEやgeodataの設定は、従来のClashのすべてのバージョンにそのまま適用できません。設定を変更する前に、クライアントの「バージョン情報」やカーネル情報の画面で実際のカーネルを確認してください。ウィンドウのタイトルにClashと表示されているだけでは不十分です。

モードはRule／ルールを選択します。Globalモードではこの記事のルールに沿って接続先を選べず、Directモードも振り分けの検証には適していません。
利用可能なポリシーグループがあることを確認します。以下では既存の設定に境外出口という名前のグループがあり、利用可能なノードが登録済みであることを前提とします。グループ名は完全に一致させてください。
サブスクリプションの元ファイルは残してください。カスタムルールの追加には、クライアントの永続オーバーライドや設定のマージ機能を優先して使いましょう。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が失われることがあります。

ルールの数より並び順が重要

ルールは上から順に評価され、最初に一致したルールの接続先が適用されます。今回の振り分けで後続ルールが改めて判定に加わることはありません。「より具体的なルールが優先される」のはカーネルが自動的に比較するからではなく、設定を作成する人が前に配置する必要があるためです。

rules:
  - DOMAIN-SUFFIX,github.com,境外出口
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,境外出口

この4行では、まずgithub.comとそのサブドメインを指定したグループに振り分けます。中国本土のドメイン分類に一致した通信は直接接続し、接続先IPが既知でデータベース上で中国本土と判定された場合も直接接続します。それ以外はMATCHに渡します。最初のルールが対象とするのはこのドメインサフィックスだけで、GitHubが利用するすべての静的リソース用ドメインを自動的に含むわけではありません。

混同しやすい3つの用語

ルールの種類	判定の基準	適した用途
`GEOSITE`	ドメイン分類データベース上のカテゴリ	IPアドレスの所属先に頼らず、ドメインの種類で振り分ける
`GEOIP`	接続先IPアドレスの国・地域情報	ドメインリストでカバーできない通信を補う
`RULE-SET`	個別に宣言するルールプロバイダー	独自の例外リストやルールファイルを管理する

DIRECTは組み込みの直接接続ポリシー、境外出口はこの記事で定義したポリシーグループ名です。この2つは異なる種類の設定項目です。ルールの接続先にポリシーグループを指定しても、「そのグループに渡す」ことしか示しません。グループで現在ノードとDIRECTのどちらが選択されているかは、別途確認が必要です。

GEOSITEとGEOIPのデータを準備

GEOSITE,cnのcnはデータベース内のカテゴリ名であり、カーネルがその場で国を判定するためのラベルではありません。カテゴリが存在するか、どのドメインが収録されているかは、使用するgeosite.datによって異なります。同様に、GEOIP,CNが参照するのはIPデータベース上の所属情報です。Webサイト運営会社の登記国や、サーバーの物理的な所在地を示すものではありません。

以下の設定ではgeodata-mode: trueを明示し、GEOIPにはgeoip.dat、GEOSITEにはgeosite.datを使用します。クライアントに用意されたデータ管理機能を使って2つのファイルを準備し、起動ログで読み込みエラーがないことを確認してください。既存の設定がMMDBモードの場合、対応するデータを用意せずに切り替えだけを行わないでください。

データファイルは信頼できるメンテナーから入手し、使用中のカーネルとの互換性を確認してください。ファイル名が正しくても、内容の形式まで正しいとは限りません。
カテゴリが見つからないというエラーが出た場合は、まずデータベースに収録されているカテゴリ名を確認してください。思い込みでcnを別のカテゴリ名に変更しないでください。
データベースを更新すると分類結果が変わることがあります。以前の設定と正常に動作していたデータを残し、更新後は同じサイトを使って再テストしてください。

ここでは自動ダウンロード先を紹介しません。「ファイルの取得に失敗した」場合と「ルールの記述を誤った」場合を混同しないためです。初回の検証では、まずローカルのデータを安定して読み込める状態にしてから、更新間隔を検討すると原因を切り分けやすくなります。

RULE-SETで個別の例外を管理

個別の例外はカテゴリルールより前に配置します。サイトの分類が適切でない場合も、小さなリストを変更するだけで済み、大規模なルールデータベース全体を複製する必要がありません。ここではローカルのYAMLファイルを使うため、ルールファイルをオンラインからダウンロードせずに済み、実際に読み込まれた内容も確認しやすくなります。

手順1：2つのルールプロバイダーを定義

以下の項目を既存設定のトップレベルにマージします。すでにrule-providersがある場合は、その下に2つの項目を追加し、同じ名前のトップレベルキーをもう1つ作らないでください。相対パスの基準は実際のカーネルの作業ディレクトリです。ダウンロードしたファイルの保存先とは限りません。また、サンドボックス型のクライアントでは、読み取り可能なパスが制限されることがあります。

mode: rule
geodata-mode: true

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

  local-proxy:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-proxy.yaml

behavior: classicalは、ファイル内にDOMAIN-SUFFIXなどルールの種類を含む項目を記述する設定です。プロバイダーの項目には接続先を記述しません。接続先はメイン設定のRULE-SET行で指定します。behavior: domainに変更する場合はファイルの書式も合わせて変更してください。異なる形式をそのまま混在させることはできません。

手順2：ローカルのリストを作成

以下の2つの例では、「指定したドメインを直接接続」と「指定したドメインをプロキシ経由」にする方法を示します。example.comは説明用のドメインであり、接続テスト用として推奨するサイトではありません。実際に使う際はこの項目を削除し、用途に合わせて管理してください。

rules/local-direct.yaml：

payload:
  - DOMAIN-SUFFIX,example.com

rules/local-proxy.yaml：

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

プロキシ接続の例外2件は設定方法を示すためのもので、すべてのネットワーク環境で対象サービスにプロキシが必須という意味ではありません。また、関連するドメインを網羅した一覧でもありません。ページは表示されるのに画像が読み込まれない場合は、失敗したリクエストのドメインを追加で調べてください。CDN全体のIP範囲をまとめて同じ接続先に変更するのは避けましょう。

手順3：rulesを段階的に並べる

既存のrulesリストを、以下の順に整理します。例にはIPv4のループバック、一般的なプライベートアドレスに加え、IPv6のループバック、ユニークローカルアドレス、リンクローカルアドレスを含みます。すべての特殊用途アドレスを網羅したリストではありません。

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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - RULE-SET,local-direct,DIRECT
  - RULE-SET,local-proxy,境外出口
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,境外出口

ローカルアドレスを先に処理し、ルーターやイントラネットのサービスへのアクセスが最後のプロキシ接続先に流れないようにします。ただし、これらのアドレスルールにはno-resolveが付いているため、未解決のドメインを判定する目的でDNSを積極的に問い合わせることはありません。イントラネットのドメインを利用する場合は、実際のドメインを直接接続リストに追加し、アクセス可能なイントラネットDNSも設定してください。

2つのカスタムリストに同じドメインが含まれる場合、先にあるlocal-directが優先されます。管理時はリストが重複しないようにし、数か月後にルールが効かない理由を忘れてしまう事態を避けましょう。サブスクリプションに拒否ルール、アプリ用ルール、特殊なサービス向けルールが含まれている場合は、用途に合わせて順序を調整してください。既存のルールをそのまま削除しないでください。

no-resolveとMATCHの適用範囲を理解する

no-resolveはDNSを無効にする設定ではない

GEOIP,CN,DIRECT,no-resolveは、判定に使える接続先IPがまだない場合、このIPルールのためだけにドメインを積極的に名前解決しない、という意味です。IPアドレスに直接接続している場合や、カーネルがすでに利用可能な実際の接続先IPを取得している場合は、引き続きルールの判定対象になります。このパラメーターによってブラウザーの名前解決が止まったり、DNS機能全体が無効になったりすることはありません。

その代わり、想定される制約もあります。中国本土のドメインがGEOSITE,cnに含まれず、GEOIPルールに到達した時点でも利用可能なIPがない場合、その通信はMATCHまで到達し、最終的にプロキシを使う可能性があります。これは慎重な設定に伴う想定内の動作であり、GEOIPが無視されたとすぐに判断する必要はありません。

まずドメインリストを見直します。直接接続が必要だと確認できたドメインをlocal-directに追加します。結果が明確で、元に戻すのも簡単です。
必要に応じて名前解決を許可します。GEOIPルール行からno-resolveを外すと、IP判定に伴って名前解決が行われる場合があります。名前解決の待ち時間とDNSの経路もあわせて確認してください。
fake-ipアドレスをサーバーのアドレスとみなさないでください。たとえば198.18.0.0/16がfake-ip用のプールとして使われることがあります。このアドレスだけを根拠に、サービスサイトの所属先を判定することはできません。

MATCHはルール未一致時の最終処理であり、障害時の切り替えではない

MATCH,境外出口は、前のルールに一致しない場合の接続先を明示するだけです。プロキシノードへの接続に失敗しても、直接接続を試すためにルールへ戻ることはありません。ノード障害時の切り替えが必要なら、ポリシーグループで適切なグループタイプを使い、ヘルスチェックを正しく設定してください。逆にMATCH,DIRECTとすると、「判定できなかった通信はすべて直接接続」となり、未収録の海外ドメインまで直接接続される可能性があります。

この記事では「中国本土のホワイトリストは直接接続、それ以外はプロキシ」という方針を採用しています。新たに追加された海外ドメインもプロキシ経由にできますが、中国本土のサービスがすべて正しく識別されるとは限りません。振り分け設定だけで誤判定をなくすことはできないため、最後は少数の例外を手動で設定する必要があります。

接続ログで実際の接続先を確認

設定を読み込めたことから分かるのは、構文や参照先がおおむね正しいということだけです。通信が必ず想定どおりカーネルを通るとは限りません。まず、ブラウザーがシステムプロキシを使用しているか、またはTUNが対象アプリの通信を正しく取り込んでいるかを確認してください。システムプロキシが影響するのは通常、プロキシ設定に従うアプリだけです。すべてのUDP通信や独自のネットワークスタックを使うアプリも取り込まれているとは限りません。

設定を再読み込みしてログを確認します。ルールファイルの読み込み失敗、GEOSITEカテゴリの不足、接続先ポリシーの未定義などのエラーがないことを確認してください。まずはログレベルをinfoに設定し、情報が足りない場合は一時的にdebugに切り替えます。再現できたら元のレベルに戻してください。
最初に個別の例外をテストします。リストに登録したドメインへアクセスし、接続の詳細画面でRuleSetに一致しているか、該当するプロバイダーと最終的なポリシーの経路を確認します。
次にドメイン分類をテストします。使用中のデータベースで実際にcnカテゴリに登録されているドメインを選び、ルールの種類がGeoSite、ポリシーがDIRECTになっていることを確認します。
最後に最終処理を確認します。前のルールに一致しない接続を1つ選び、Matchに到達することと、境外出口で現在選択されているノードを確認します。

テストのたびに該当する既存の接続を終了してから、新しい接続を開始してください。確立済みのTCP接続は、ルールファイルを変更しても接続先が自動で切り替わりません。ブラウザーが接続を再利用すると、「ルールを変更したのに変化がない」と誤解しやすくなります。ドメイン、接続先IP、一致したルール、最終的な接続先を記録すると、アクセス失敗の画面を撮影するだけよりも有用です。

よくある誤判定を直す順序

状況	まず確認する項目	具体的な対処
中国本土のサイトがプロキシ経由になる	Matchに一致しているか、ドメインが収録されているか	対象ドメインを確認してlocal-directに追加し、GEOIPで名前解決がスキップされていないか確認する
海外のサイトが直接接続になる	GeoIPまたは先行する直接接続リストに一致していないか	ドメインをlocal-proxyに追加し、GEOSITEとGEOIPより前に配置する
RULE-SETがまったく動作しない	プロバイダー名、パス、ファイル形式	classical項目の構文とpayloadの階層を確認し、再読み込み後にエラーログを見る
プロキシグループに一致しているのに直接接続と表示される	グループ内の現在の選択項目と、入れ子になったポリシーの経路	グループでDIRECTが選択されていないか確認し、最終的な接続先まで順に調べる
トップページは表示されるがリソースの読み込みに失敗する	読み込みに失敗したリソースが使う個別のドメイン	実際の接続ログをもとにリソースのドメインを追加し、共有IP範囲全体に広げない
サブスクリプションを更新すると設定が元に戻る	一時的に生成されたファイルを編集していないか	クライアントの永続オーバーライド機能に設定を移し、マージ後の最終的なルール順を確認する

中国本土のサイトが海外CDNのIPアドレスに解決される場合、ドメインルールをGEOIPより前に置く意味があります。ドメインが直接接続リストに一致すれば、後続の海外IP判定によって結果が覆ることはありません。逆に、海外向けサービスが中国本土のIPアドレスを使っている場合、GEOIPだけでは直接接続になる可能性があります。そのため、明示的なプロキシ例外はIP判定より前に配置してください。

最後に、小規模で安定したテストリストを用意します。個別に直接接続するドメイン、プロキシ経由にするドメイン、中国本土のカテゴリに含まれるドメイン、最終処理に到達する接続をそれぞれ1つ選びます。変更は一度に1か所にとどめ、毎回同じリクエストで再テストしてください。各接続がなぜその接続先を選ぶのか説明できて、初めて振り分け設定が機能していると言えます。ルールの数を増やし続けても、順序やDNS、ポリシーグループの選択ミスは解決しません。