上級設定 読了目安 12分

GeoIP・GeoSiteデータベースの更新方法｜mihomo地理ルール徹底解説

GeoIP・GeoSiteデータベースの役割、mihomoのgeodataとMMDBの違い、自動更新・手動交換の設定、GEOIP/GEOSITEルールの書き方と適用順を解説します。

まずGeoIP、GeoSite、ルールの違いを理解する

GeoIPとGeoSiteはいずれもルールエンジンが検索するデータセットですが、対象が異なります。GeoIPは接続先のIPアドレスから国、地域、またはLANの範囲を判定し、GeoSiteはドメインから所属するサイト集合を判定します。設定にある GEOIP と GEOSITE は検索命令にすぎず、実際の分類内容はローカルのデータベースファイルに収録されています。

ドメインを接続先とするアクセスを例にすると、mihomoはまずドメインルールやGeoSite分類で照合できます。前段のルールに一致しなければ、後続のGEOIPルールがDNS解決を行い、解決結果を使ってIPデータベースを検索する場合があります。最終的に使われるプロキシグループは、ルール一覧で最初に一致したルールによって決まります。データベースが答えるのは「このドメインまたはIPがどの集合に属するか」だけで、DIRECT、プロキシ、拒否を自動的に決めるものではありません。

データ種別 照合対象 主なファイル 主な用途
GeoSite ドメイン geosite.dat サイトカテゴリ、サービス事業者、地域別のドメイン集合で通信を振り分ける
GeoIP Dat IPv4・IPv6アドレス geoip.dat geodataモードで国・地域別のIP照合を行う
MMDB IPv4・IPv6アドレス country.mmdb MMDBモードでGEOIPルールに位置情報を提供する
ASN MMDB IPが所属する自律システム GeoLite2-ASN.mmdb ASN系ルールや関連する検索機能で利用する

GeoSiteはトップレベルドメインの一覧ではありません。たとえば GEOSITE,cn が検索するのはデータソースの管理者が整理したドメイン集合であり、末尾が .cn のアドレスだけに一致するわけではありません。.com を使う中国本土のサービスがこの集合に含まれる場合もあり、分類結果は使用中のデータベースのバージョンによって変わります。

geodataモードとMMDBモードの違い

geodataモードを有効にするとどうなるか

geodata-mode: true を設定すると、mihomoはGEOIP分類に geoip.dat を、GEOSITE分類に geosite.dat を使用します。Datファイルには複数のタグ集合を格納でき、ルールでよく使う CN、LAN、特定のGeoSiteタグはファイル内部の項目に対応付けられます。

geodata-mode: true
geodata-loader: memconservative

geodata-loader はgeodataデータの読み込み方式を制御します。standard は先読み寄りで、連続した照合時の負荷が安定しやすい一方、より多くのメモリを使用します。memconservative は必要に応じた読み込みを重視し、メモリの少ないルーターやコンテナに適しています。使用可能メモリが約100 MBの端末では、まず memconservative を選び、ルールの読み込み時間と初回照合の所要時間を確認してから変更を判断してください。

geodataモードを無効にするとどうなるか

geodata-mode: false を設定すると、GEOIP検索には通常 country.mmdb が使われます。MMDBはIP検索向けのデータベース形式であり、GeoSiteのドメイン分類を置き換えるものではありません。そのため設定にGEOSITEルールがある場合、geosite.dat は引き続き利用可能にしておく必要があります。

geodata-mode: false

どの端末にも共通する速度面の結論はありません。データベースの容量、ルール数、ストレージ性能、ローダー設定によって結果は変わります。デスクトップではデータソースの網羅性と更新頻度を重視し、メモリの少ない端末ではmihomo起動後の常駐メモリも確認してください。モードを切り替えた後は、画面上で設定を再読み込みするだけでなく、コアを完全に再起動します。

  • GEOSITE とDatタグを多用するルールでは、geodataモードを優先するとよいでしょう。
  • 既存のルールが主に GEOIP,CN で、データソースがMMDBしか提供していない場合は、MMDBモードを使い続けられます。
  • geoip.dat を country.mmdb に名前変更しないでください。拡張子が異なるのは、内部形式が異なるためです。
  • モードを切り替える前に元のデータベースファイルを保管しておくと、分類異常や起動エラーが発生した際に復元できます。

データベースの自動更新を設定する

mihomoは指定したURLからGeoIP、GeoSite、MMDB、ASNのデータを取得できます。主な項目は geo-auto-update、geo-update-interval、geox-url です。更新間隔の単位は時間で、24 にすると24時間ごとに確認します。地理情報の分類を分単位で更新する必要は通常なく、デスクトップや家庭用ゲートウェイの多くでは1日1回で十分です。

geodata-mode: true
geodata-loader: memconservative
geo-auto-update: true
geo-update-interval: 24

geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"
  asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"

現在geodataモードを有効にしていても、将来の切り替えに備えてMMDBのURLを残しておけます。ただし、現在のルール経路で実際に使われるファイルは、モードとルール種別によって決まります。クライアントのオーバーライド機能で設定を統合する場合は、これらの項目をトップレベルに置き、dns、rules、proxy-groups の下にインデントしないでください。

更新リクエストを直接接続とプロキシのどちらで行うか

データベースをダウンロードできるかどうかは、コアの実行時にデータURLへアクセスできるかで決まります。コア起動の早い段階でファイルを取得するクライアントでは、その時点でプロキシポリシーがまだ利用できない場合があります。一方、現在のルールを通して更新リクエストを送るクライアントもあります。タイムアウトが続く場合は、まずブラウザーでURLにアクセスできることを確認し、DNS、システム時刻、送信ルール、クライアントがコアプロセスをバイパスしていないかを確認してください。

調査時は「ログ」→「ログレベル」→「情報」または「デバッグ」を開き、コアを再起動します。正常な処理では、地理データのダウンロード、書き込み、読み込みに関する記録が表示されます。30秒経っても接続タイムアウトが続く場合、更新ボタンを何度も押さないでください。まずデータドメインがどのプロキシグループに一致したかを確認し、そのグループの現在のノードが利用可能かを調べます。

GeoIP・GeoSiteファイルを手動で置き換える

自動更新に失敗した場合、端末からデータソースへ直接アクセスできない場合、または特定のデータバージョンを固定したい場合は、ファイルを手動で置き換えられます。重要なのは、mihomoが実際に使用している作業ディレクトリを見つけることです。コマンドラインの既定ディレクトリはLinuxとmacOSでは ~/.config/mihomo/、Windowsでは %USERPROFILE%\.config\mihomo\ が一般的です。起動コマンドで -d を指定している場合は、-d の後にあるディレクトリが基準になります。

グラフィカルクライアントは独自のアプリデータディレクトリを使うことが多く、上記の既定パスを読み込むとは限りません。クライアントの「設定」→「設定ディレクトリ」または「設定」→「アプリケーションディレクトリ」から実際の場所を開き、ログに表示されるデータベースパスでも確認してください。ファイルマネージャーで同名ファイルを検索するだけでは不十分です。旧バージョンのディレクトリと現在の実行ディレクトリが同時に存在する場合があります。

  1. 現在のコアバージョン、geodata-mode の設定、作業ディレクトリを記録する。
  2. 置き換え中にファイルハンドルが使用され続けないよう、mihomoコアを停止する。
  3. 元のファイルを名前変更して保存する。たとえば geosite.dat を geosite.dat.bak に変更する。
  4. 新しいファイルをコピーし、コアが想定する名前を維持する：geoip.dat、geosite.dat、country.mmdb、GeoLite2-ASN.mmdb。
  5. コアを再起動し、ログに未対応形式、タグ不足、ファイル読み込み失敗がないか確認する。
  6. クライアントに「実行中」と表示されるかだけでなく、明確なテストルールを1つ使って一致結果を検証する。

置き換え後に load GeoSite failed、invalid database、指定タグが存在しないなどのエラーが出た場合は、まずバックアップファイルを戻し、データ形式と設定モードを確認します。ファイルをダウンロードできても、現在のコアに適しているとは限りません。データソースによってタグ名が異なる場合があり、GEOSITE,cn は使えても、より細かな分類タグは使えないことがあります。

GEOIP・GEOSITEルールの書き方

読みやすい基本的な順序

mihomoのルールは上から順に照合され、一致すると後続の確認を停止します。そのため、より具体的なルールを広範な地理ルールより前に置き、最後は MATCH で受けます。以下の ノード選択 と 中国本土は直接接続 は、設定内に実在するプロキシグループ名に置き換えてください。

rules:
  - DOMAIN,api.example.org,ノード選択
  - DOMAIN-SUFFIX,example.org,ノード選択
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,中国本土は直接接続
  - GEOIP,LAN,DIRECT,no-resolve
  - GEOIP,CN,中国本土は直接接続
  - MATCH,ノード選択

最初の完全一致ドメインルールが最も高い優先度を持ちます。次のルールはそのドメインとサブドメインを対象にします。その後にGeoSite分類とGeoIP判定が続きます。GEOSITE,cn,中国本土は直接接続 を特別な処理が必要な中国本土サイトのルールより前に置くと、特別ルールが一致する機会を失う場合があります。

ルール 入力 名前解決が発生する可能性 適した位置
DOMAIN 完全なドメイン名 なし 最も具体的なルールの範囲
DOMAIN-SUFFIX ドメインサフィックス なし 具体的なサービス分類の前
GEOSITE ドメイン分類 なし 通常のドメインルールの後
GEOIP 接続先IP 接続先がドメインの場合に発生する可能性あり ドメインルールの後、フォールバックの前
MATCH 残りすべての接続 なし 最後のルール

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

no-resolve は、このIP系ルールが照合のためにドメインを積極的に名前解決しないことを示します。既知の接続先IPを主に処理する GEOIP,LAN,DIRECT,no-resolve のようなルールに適しており、余分なDNS問い合わせを減らせます。ただし接続先がまだドメイン名で、前段のルールに一致していない場合、このGEOIPルールは接続先IPを取得できずスキップされることがあります。

そのため、すべてのGEOIPルールに機械的に no-resolve を追加すべきではありません。GEOIP,CN を中国本土向けトラフィックの重要なフォールバックとして使う場合は、DNSモード、スニッフィング結果、実際の接続種別を組み合わせてテストしてください。TUNモードを有効にするとmihomoが受け取るトラフィック範囲は広がりますが、ルールの順序とデータベース検索の仕組みは変わりません。

データベースとルールが実際に有効か確認する

検証では「ファイルが読み込まれたこと」と「リクエストが正しいルールに一致したこと」を同時に確認します。データベースの更新時刻が変わっただけでは、ルール順が正しいとはいえません。接続に成功しただけでも、想定したプロキシグループを経由した証明にはなりません。

GeoSiteルールをテストする

  1. 一時的に対象カテゴリを、たとえば 中国本土は直接接続 のような判別しやすいプロキシグループに割り当てます。
  2. 「ログ」→「ログレベル」で「情報」または「デバッグ」を選択します。
  3. ブラウザーの既存の接続を閉じ、テスト対象のドメインへ再度アクセスします。
  4. ログでルール種別、一致したタグ、最終的なプロキシグループを確認します。
  5. テスト後は正式な設定に戻し、一時ルールを残したままにしないでください。

GEOIPのテストではキャッシュの影響を避ける

ブラウザーはHTTP/2またはHTTP/3接続を再利用することがあり、DNS結果もOS、ブラウザー、mihomoのキャッシュから取得される場合があります。ルールを変更したら、まずクライアントで「設定」→「再読み込み」を実行し、関連するタブを閉じて古い接続が終了するまで待ちます。必要に応じてブラウザーまたはコアを再起動し、新しい接続でログを確認してください。

同じドメインが複数のIPを返す場合、GeoIPの分類結果は名前解決の結果によって変わる可能性があります。CDNサービスでは特に一般的で、ネットワーク、DNSサーバー、時間帯によって異なる地域のアドレスが返されることがあります。このようなサービスでは、GEOIPだけに依存せず、DOMAIN、DOMAIN-SUFFIX、GEOSITEルールを優先する方が適しています。

よくあるトラブルと対処の順序

GeoSiteタグが見つからないと表示される

まず現在の作業ディレクトリにある geosite.dat がコアに読み込まれていることを確認し、次にタグの綴りを確認します。タグはデータソースが定義するもので、サービス名から自由に推測することはできません。ログで特定のタグだけがエラーになる場合は、現在のデータセットにその分類がない可能性が高いです。すべてのGEOSITEルールが失敗する場合は、ファイルパス、ファイル形式、読み込み処理に問題がある可能性が高くなります。

更新は成功したのにルール結果が変わらない

クライアントによっては新しいファイルをダウンロードした後、コアを再起動しないと再読み込みされません。まず「設定」→「コア」→「コアを再起動」を実行し、起動ログに表示されるデータファイルのパスを確認します。ログが別のディレクトリを示している場合は、起動引数の -d と、クライアントがサブスクリプション設定を独立したディレクトリで実行していないかを確認してください。

設定の解析時にフィールドエラーが発生する

これは通常、コアのバージョンが古いか、クライアントが想定したmihomoファイルを実際には起動していないことを示します。mihomo -v を実行し、クライアントの「設定」→「コア」に表示されるバージョンと照合してください。コアを更新する前に、クライアントが対応するコアのインターフェースを確認します。すぐに更新できない場合は、旧バージョンが認識しない項目を他のYAML階層へ移動するのではなく削除してください。

TUNモードで一部のアプリが地理ルールどおりに振り分けられない

まず接続がmihomoに到達しているかを確認し、次にドメインが見えているかを確認します。接続先IPしかなくドメインがない場合、GEOSITEは直接照合できません。その場合はスニッフィングによるドメイン復元や、GEOIPルールに依存することがあります。プロセスルールやIP-CIDRルールが地理ルールより前に置かれていないかも確認してください。先に一致したルールが照合を終了させるためです。

トラブルシューティングの順序は、コアのバージョン確認、作業ディレクトリの確認、データベース読み込みログの確認、ルール順の確認、DNSまたはスニッフィング結果の確認、最後にプロキシグループの出口確認で固定できます。この順に進めれば、「データベースが更新されていない」問題と「ルールが一致していない」問題を切り分けられます。

Clashダウンロード