mihomoのルール分岐設定ガイド：GEOSITE・GEOIP・MATCHで中国本土と海外を振り分ける

1. 最小構成のルールを書く

利用中のサブスクリプションがある場合は、ノードとプロキシグループをそのままにして、ルール部分だけを置き換えます。以下の設定では、プライベートアドレス、中国本土のドメイン、中国本土のIPアドレスを直接接続し、それ以外の通信をPROXYに振り分けます。これは既存設定に追加する断片であり、そのまま接続できる完全な設定ではありません。

mode: rule
geodata-mode: true

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
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

統合前に確認する3つの依存項目

PROXYは、既存のノード名またはプロキシグループ名である必要があります。また、グループ内で利用可能なプロキシノードが選択されていることを確認してください。名前の大文字・小文字は区別されます。
GEOSITE,cnを使うには、cnカテゴリを含むドメインデータベースが必要です。この例ではgeodata-mode: trueを設定し、GEOIPが対応するGeoIPデータファイルを使うようにしています。
YAMLのトップレベルに置くrulesキーは1つだけにしてください。完全なルール設定を2つ、そのまま連結してはいけません。

ここでいう「中国本土への直接接続」は、データベースの分類に基づくルーティング設定であり、サイトの運営主体、使用言語、サーバー所在地を断定するものではありません。データベースに登録漏れがある場合や、CDNのIPアドレスが変更される場合もあります。重要なサービスには明示的なドメインルールを追加し、接続ログで動作を確認してください。

サブスクリプションを利用するクライアントでは、編集内容を保存する場所も確認してください。クライアントが対応する上書き設定、設定のマージ機能、または永続化される拡張設定に保存します。サブスクリプションから生成されたファイルを直接編集すると、次回の更新時に変更が上書きされることがあります。設定方法はクライアントごとに異なるため、使用中のクライアントの説明を確認してください。

2. ルールの順序：上から順に評価し、最初に一致したルールを適用

mihomoはrulesを上から順に評価します。有効なルールに一致すると、そのルールで指定された通信先が適用され、「より具体的な」後続ルールは評価されません。ドメイン名の長さに応じてルールが自動的に並べ替えられることもありません。

明示的な例外は、汎用カテゴリより前に置く

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,downloads.example.org,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ここに挙げた2つのドメインは、構文を説明するための例であり、実在のサービスを示すものではありません。DOMAIN-SUFFIX,example.comはルートドメインとサブドメイン（例：api.example.com）に一致します。DOMAINは指定したホスト名だけに一致します。あるドメインが先行ルールでプロキシに振り分けられた場合、後続の中国本土向けIPルールで直接接続に変更されることはありません。

第1層：プロキシ経由、直接接続、または拒否を指定する個別の例外。
第2層：ローカルネットワークのアドレスと、用途別に設定したルールセット。
第3層：GEOSITEやGEOIPなど、広い範囲を対象とするカテゴリ。
最後の層：MATCHで、先行ルールに一致しなかった通信を処理します。

MATCHは「海外のアドレスを判定する」ルールではなく、条件なしで適用されるフォールバックです。この例では、一致しなかった通信をプロキシに送るため、データベースに登録されていない中国本土のドメインもプロキシ経由になる場合があります。先頭に置くと、後続の振り分けルールが機能しません。

3. GEOSITEとGEOIPの役割

ルールの種類	判定基準	適用する位置
GEOSITE,cn	ドメインデータベースのcnカテゴリ	ドメインの例外ルールの後、IPカテゴリの前
GEOIP,CN	宛先IPアドレスのデータベース分類	ドメインルールで対象にならなかった通信を補完
MATCH	追加のマッチ条件なし	ルールリストの末尾でフォールバック

GEOSITEはサーバーの所在地を先に判定する必要がない

接続に利用可能なドメイン名が含まれている場合、GEOSITE,cn,DIRECTでドメインのカテゴリを直接判定できます。中国本土のウェブサイトが海外のCDNを利用していても、ドメインデータベース上の分類が自動的に変わるわけではありません。反対に、海外のサービスが中国本土のIPアドレスを使っていても、GEOSITEでcnに分類されるとは限りません。

GEOIPではドメインの名前解決が発生する場合がある

接続にドメイン名しかなく、宛先IPアドレスがまだ分からない場合、IPルールの評価時にDNSで名前解決が必要になることがあります。そのため、GEOIP,CN,DIRECTを使うと、ドメインカテゴリに一致しなかった通信を補完して判定できます。ただし、名前解決の結果やDNSの経路によって最終的な判定は変わります。

# 必要に応じてドメインを名前解決し、宛先IPを判定する
- GEOIP,CN,DIRECT

# このルールではドメインの名前解決を行わない
- GEOIP,CN,DIRECT,no-resolve

no-resolveは「すべてのDNSを無効にする」設定でも、「すべての通信を高速化する」汎用オプションでもありません。この設定は、対象のIPルールで名前解決を行わないようにします。接続に宛先IPアドレスがすでにある場合は、引き続きルールの判定対象になります。GEOIPでドメイン名の通信も補完判定したいのにno-resolveを付けると、一部のリクエストが末尾のMATCHに振り分けられる可能性があります。

4. rule-providersでルールセットを分離する

ルールが増えてきたら、ドメイン一覧をメイン設定から分離できます。rule-providersではルールセットの取得元と形式を定義し、RULE-SETではメインルールの適用位置と、一致した場合の通信先を指定します。providerを定義しただけでは振り分けは行われず、ルール内で参照する必要があります。

まずは確認しやすいローカルのドメイン一覧を使う

以下では、local-directという名前のファイル型ルールセットを定義します。パスはmihomoの作業ディレクトリからの相対パスです。ファイルはクライアントが読み込める設定ディレクトリに置き、ターミナルの現在のディレクトリから推測せず、実際の作業ディレクトリを確認してください。

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

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

rules/local-direct.yamlを作成し、以下の内容をすべて記述します。これは直接接続するドメインを明示した2件のルールであり、中国本土のドメインデータベース全体ではありません。

payload:
  - '+.baidu.com'
  - '+.qq.com'

behavior: domainは、このファイルにドメインのマッチ条件だけを記述する設定です。DOMAIN-SUFFIX,baidu.com,DIRECTのようなルール全体を入れることはできません。通信先は、メイン設定のRULE-SET,local-direct,DIRECTで決まります。+.を使うと、そのドメイン自体とサブドメインの両方に一致します。

複合ルールにはclassicalを使う

同じファイルでドメイン条件とIP条件を併用する場合は、behavior: classicalに変更し、対応するルール構文を使います。以下はルールセットファイルの内容です。各項目の末尾に通信先は記述しません。

payload:
  - DOMAIN-SUFFIX,baidu.com
  - IP-CIDR,192.168.0.0/16,no-resolve

ファイルの内容だけを変更して、providerのbehaviorを変更し忘れないようにしてください。リモートルールセットを使う場合は、宣言されている形式も確認します。YAML、プレーンテキスト、バイナリ形式のルールセットを任意に混在させることはできません。HTTP形式ではinterval: 86400を指定すると、86400秒ごとに更新を確認できます。ローカルファイル形式では、このパラメーターによるファイル同期は行われません。

5. DNS・fake-ip・TUNの役割の違い

ルールで振り分けられるのは、mihomoに到達した通信だけです。システムプロキシが対象にするのは、プロキシ設定に従うアプリに限られます。コマンドラインツール、ゲーム、独自にネットワーク接続するアプリは、システムプロキシを経由しない場合があります。TUNモードでは仮想ネットワークアダプターを使って、より多くのIP通信を取り込みます。ただし、実際に取り込める範囲はルーティング、権限、除外設定によって異なります。

通信の取り込み：まず、アプリのリクエストがクライアントの接続一覧に表示されるか確認します。接続記録がない場合は、システムプロキシ、アプリ側のプロキシ設定、またはTUNのルーティングを確認してください。
接続情報の識別：接続記録にドメイン名があるか、IPアドレスだけかを確認します。ドメイン名が分からない場合、GEOSITEが照合できるドメイン情報がないのが一般的です。
ルールの適用：一致したルール、選択中のプロキシグループ、実際のノードを確認し、ルールによる振り分けとノードの選択を切り分けます。

fake-ipモードでは、DNSが合成アドレスを返すことがあります。たとえば、一般的な設定では198.18.0.1/16のアドレス範囲が使われます。mihomoはマッピングによって元のドメイン名と関連付けるため、この合成アドレスを実際のサーバーIPとして地理的に判定してはいけません。「GEOIPを直す」目的でfake-ipのアドレス範囲全体を直接接続に設定しないでください。

ブラウザーの暗号化DNS、独立したDNSクライアント、TUNを併用する場合は、ドメイン情報がmihomoに届いているか確認してください。スニッフィングで一部のプロトコルからドメインを補えることはありますが、すべての接続でドメイン名を復元できるとは限りません。また、DNS通信の取り込み経路を確認する代わりにはなりません。

6. 設定を検証し、3種類の接続をテストする

構文を確認してからクライアントに読み込む

mihomoの設定チェック機能を使って検証できます。以下のコマンドは、設定ファイルがカレントディレクトリにあることを前提としています。クライアントが専用の作業ディレクトリを使う場合は、正しいディレクトリも指定し、その中にデータベースとローカルルールセットを用意してください。

mihomo -t -f ./config.yaml

チェックに合格しても、設定を読み込めることが分かるだけで、ノードに接続できることや、すべてのドメインが想定どおりに振り分けられることは保証されません。読み込み後、クライアントがルールモードになっていることを確認してください。グローバルモードや直接接続モードでは、確認結果が変わります。

テスト条件をそろえ、実際に適用されたルールを確認する

クライアントのHTTPまたはmixedの待ち受けポートが7890の場合は、プロキシを明示してテストできます。ここでのポート番号は例なので、実際の設定を確認してください。HTTPプロキシだけをテストする場合、テストのためにTUNを有効にする必要はありません。

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com/
curl -I --proxy http://127.0.0.1:7890 https://www.wikipedia.org/

中国本土のドメイン：GEOSITEまたはカスタムのRULE-SETに一致しているか、通信先がDIRECTになっているかを確認します。
直接接続カテゴリに含まれない海外ドメイン：MATCHに振り分けられているか確認し、PROXYでDIRECTではなくプロキシノードが選択されていることも確認します。
ローカルネットワークのサービス：実際に存在するルーターやNASのアドレスを使ってテストし、プライベートネットワークのルールが機能しているか確認します。ローカルネットワークへの接続がプロキシ経由になるかどうかは、アプリのプロキシ除外リストやTUNの除外ルートにも左右されます。

ここに挙げたドメインは確認方法を説明するための例です。任意のバージョンのデータベースで一致することを保証するものではありません。HTTPステータスコードが200、301、403のいずれであっても、それだけでは正しく振り分けられた証拠になりません。接続の詳細に表示されるルールの種類、通信先までの経路、ログを合わせて確認してください。

7. よくある問題を層ごとに切り分ける

中国本土のウェブサイトがプロキシ経由になる

まず、先に評価されるプロキシルールがないか確認してください。サブスクリプションに含まれる用途別ルールセットは特に注意が必要です。
現在のGEOSITEデータに対象ドメインが含まれているか確認します。接続記録にIPアドレスしかない場合は、GEOIPとDNSによる識別経路を確認してください。
選択されていないサブスクリプションの設定ではなく、現在有効な設定を編集しているか確認します。再読み込み後、新しい接続を作成してテストしてください。

すべてのリクエストが同じ出口を通る

mode: ruleが設定されているか、MATCHの位置は適切か、PROXYグループ内で何が選択されているかを順に確認してください。プロキシグループの名前が「プロキシ」でも、プロキシノードが選択されているとは限りません。ルールを変更しても、既存の長時間接続では以前の通信先が維持されることがあります。該当する接続を閉じるか、テスト対象のアプリを再起動してください。

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

ルールをクライアントが対応する永続的な上書き設定やマージ設定に移し、設定のマージ順も確認してください。既存のMATCHの後ろにカスタムルールを追加しても、保存されるだけで適用されません。サブスクリプションの更新後は、少なくとも直接接続するドメインとプロキシ経由にするドメインを1つずつ再確認してください。

ウェブは見られるが、ゲームやUDP通信に問題がある

まず、アプリの通信がmihomoに取り込まれているか確認します。次に、ノードのプロトコル、サーバー、プロキシグループの選択が、必要なUDP転送に対応しているか確認してください。TUNで解決できるのは通信を取り込む入口に関する問題の一部です。UDP非対応の通信先が自動的にUDP転送に対応するわけではありません。IPv6も個別に確認し、IPv4のリクエストが成功しただけでデュアルスタックの検証が完了したと判断しないでください。

最終的には、個別の例外を先頭に置き、ドメイン分類を中段に、IP分類を補完として配置し、MATCHで締めくくると、意図を把握しやすいルール順になります。ルールを追加するたびに接続記録を確認し、どのルールに一致したかを把握してから一覧を拡張してください。