GeoIP・GeoSiteデータベース更新ガイド：ダウンロード元の設定、手動置換、ルール連携

まずGeoIPとGeoSiteの判定対象を整理する

GeoIPとGeoSiteはどちらも多数のルールを短い条件にまとめられますが、扱う対象は異なります。GeoIPは接続先のIPアドレスから国や地域を判定し、GeoSiteはドメインの分類に基づいてマッチします。別々のデータベースであり、相互に置き換えることはできません。

項目	GeoIP	GeoSite
主なファイル	GeoIP.dat または Country.mmdb	GeoSite.dat
入力対象	IPv4・IPv6アドレス	ドメインおよびドメイン分類タグ
代表的なルール	GEOIP,CN,DIRECT	GEOSITE,cn,DIRECT
主な用途	接続先IPの地域による最終的な振り分け	サイト、サービス、カテゴリ単位で先に振り分ける
主な制約	CDN、Anycast、クラウドサービスのアドレスは地域をまたぐ場合がある	接続時にドメイン情報を保持または復元する必要がある

GeoSiteはGeoIPより先に配置する

多くの設定ではルールを上から順に照合します。ドメインルールはIPの地理的な所属よりもサービスの意味に近いため、先に処理するのが基本です。たとえば複数の国に分散したCDNを使うサービスでは、GeoIPは現在解決されたノードのアドレスしか見られませんが、GeoSiteなら元のドメインに基づいて安定して分類できます。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

このルール群では、まず広告カテゴリを遮断し、次に中国本土でよく使われるドメインを処理します。その後、ドメインルールにマッチしなかった中国本土のIPアドレスをGeoIPで補完し、最後にデフォルトのポリシーグループへ渡します。実際に利用できるタグは選択したGeoSiteデータソースによって異なるため、変更前にタグ名が一致していることを確認してください。

Mihomoが実際に使用するデータ形式を確認する

Clash Metaの後継はMihomoとして開発が続けられています。クライアントによって内蔵コアのバージョンが異なったり、旧Clash形式の設定画面が残っていたりします。更新を始める前に、クライアントの「設定」→「コア」または「設定」→「バージョン情報」でコア名とバージョンを確認してください。コマンドライン環境では mihomo -v を実行します。

Mihomoの geodata-mode はGeoIPデータの読み込み方式に影響します。有効にすると通常は GeoIP.dat を読み込み、無効にすると通常はMMDB形式の Country.mmdb を使用します。GeoSiteの分類は引き続き GeoSite.dat から提供されます。同名ファイルを1つ置き換えただけで、必ずコアが読み込むとは限りません。設定モードと作業ディレクトリも確認してください。

geodata-mode: true
geodata-loader: memconservative

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

geodata-loader: memconservative はメモリ使用量を重視する環境に適しています。利用できる値や動作はコアのバージョンによって変わるため、変更後はクライアントの設定チェックまたはコマンドラインで確認してください。メモリに余裕のあるデスクトップでは、クライアントが生成したデフォルト値を維持するのが無難です。

`no-resolve` は常に必要なオプションではない

GEOIPルールが受け取った接続先がまだドメイン名の場合、地域判定のためにコアが先にIPを解決することがあります。ルール末尾に no-resolve を付けると、そのルールのために追加の名前解決を行わない指定になります。不要なDNSリクエストを減らせますが、接続先IPがまだ得られていない場合、そのGEOIPルールは自動で解決してマッチしません。

接続先IPがすでにある場合：GEOIPは直接判定でき、no-resolve がマッチを妨げることは通常ありません。
接続先がまだドメイン名の場合：DOMAIN、DOMAIN-SUFFIX、GEOSITEルールを優先して処理します。
ドメインの名前解決結果をGEOIPで判定する設定の場合：テストせずに no-resolve を追加しないでください。

自動更新のダウンロード元を設定する

Mihomoでは geox-url で地理データベースのURLを指定し、geo-auto-update で自動更新を制御できます。以下の例では同じリリースリポジトリにあるGeoIPとGeoSiteを使用し、2つのデータセットで公開時期や分類基準が大きくずれないようにしています。

geodata-mode: true
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"

geo-update-interval: 24 の単位は時間で、24時間ごとに確認する指定です。デスクトップクライアントなら1日1回で十分であり、1時間以下に設定する必要はありません。データベースの公開頻度は通常、プロキシノードの状態変化より低いため、更新頻度を上げすぎると起動時のネットワークリクエストが増えるだけです。

ダウンロード元に必要な4つの条件

ファイル形式が一致している。GeoIPのURLは、現在のモードが対応するデータファイルを返す必要があります。Web上のダウンロードページをバイナリファイルのURLとして指定してはいけません。
ファイル名と内容が対応している。geoip はIPデータを、geosite はドメイン分類データを指します。
タグの基準を確認できる。設定で使用する cn、private、category-ads-all などのタグが、そのデータソースに存在している必要があります。
コアの起動時にアクセスできる。初回ダウンロードがルールの有効化より前に行われる場合、ダウンロード経路がまだ読み込まれていない同じルールセットに依存する循環状態にならないようにします。

変更後は設定を確認してからコアを再読み込みする

コマンドライン環境では、コア自身でYAMLを検証できます。-d は実行ディレクトリを指定し、データベースもこのディレクトリから読み込まれます。-f はメイン設定ファイルを指定します。パスに空白が含まれる場合は引用符で囲んでください。

mihomo -d "/opt/mihomo" -f "/opt/mihomo/config.yaml" -t

クライアントでは「設定」ページで現在の設定を選び、「チェック」または「再読み込み」を実行します。メニュー名はクライアントのバージョンによって多少異なりますが、保存して戻せるコピーを作成、YAMLを検証、コアを再読み込み、ログを確認という順序は維持してください。ダウンロード失敗、ファイル形式エラー、タグ不在などがログに出た場合は、まず古いファイルへ戻し、複数の設定を続けて変更しないでください。

オフライン環境でデータベースを手動置換する

サーバーからダウンロード元へ直接アクセスできない場合、企業ネットワークで外部接続が制限されている場合、または特定のデータベースバージョンを固定したい場合は、オフラインで置き換えられます。重要なのはプログラムのインストール先へコピーすることではなく、Mihomoの作業ディレクトリを見つけることです。コマンドライン環境では -d パラメーターで作業ディレクトリが決まり、GUIクライアントでは通常「設定」→「設定ディレクトリ」または「設定」→「アプリケーションディレクトリ」から開けます。

標準的な置換手順

ネットワークに接続できる端末で、現在の設定に合った GeoIP.dat、GeoSite.dat、または Country.mmdb をダウンロードします。
公開バージョンとダウンロード日（例：2026-05-28）を記録しておくと、後で更新の要否を判断しやすくなります。
対象端末でMihomoコアを停止し、トレイメニューまたはサービスマネージャーでコアが終了していることを確認します。
作業ディレクトリを開き、古いファイルを GeoIP.dat.bak と GeoSite.dat.bak に変更します。
新しいファイルをコピーし、コアが想定する大文字・小文字とファイル名を維持します。
設定を検証してからコアを起動し、最初の30秒間のログを確認します。
プライベートアドレス、よく使う中国本土のドメイン、デフォルトプロキシのドメインの3種類をテストします。

Linuxのサービス運用では、まず一時ファイル名でコピーし、同じファイルシステム上で名前を変更して置き換えると、プロセスが不完全なファイルを読み込むリスクを減らせます。以下のパスは -d /etc/mihomo で決まる作業ディレクトリの例です。

sudo systemctl stop mihomo
sudo cp /mnt/offline/GeoIP.dat /etc/mihomo/GeoIP.dat.new
sudo cp /mnt/offline/GeoSite.dat /etc/mihomo/GeoSite.dat.new
sudo mv /etc/mihomo/GeoIP.dat /etc/mihomo/GeoIP.dat.bak
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo mv /etc/mihomo/GeoIP.dat.new /etc/mihomo/GeoIP.dat
sudo mv /etc/mihomo/GeoSite.dat.new /etc/mihomo/GeoSite.dat
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t
sudo systemctl start mihomo

WindowsのGUIクライアントでは、コアが動作中にファイルを直接上書きしないでください。トレイメニューからコアまたはクライアントを終了してから、設定ディレクトリを操作します。ファイルが使用中の場合、強制的な上書きで一時ファイルが残り、次回起動時も古いデータベースが読み込まれることがあります。

データベースが古いと起きる振り分けのずれ

地理データベースが古くても、通常クライアントがすぐクラッシュすることはありません。代わりに、局所的で断続的な振り分け異常が発生します。同じサイトでも一部のCDNアドレスや新しいドメインだけが誤ったポリシーにマッチするため、ノードの不安定さと誤認しやすい問題です。

GeoIPが古い場合の代表的な症状

新しく割り当てられたIP帯が MATCH に入り、想定した GEOIP,CN にマッチしない。
クラウドサービスやCDNのアドレス所属が変更された後、想定と異なるポリシーグループへ振り分けられる。
IPv4は正常にマッチするのに、新しく追加されたIPv6帯だけデフォルトポリシーへ進む。
同じドメインでも解決先が変わるたびに、DIRECTとデフォルトプロキシの間でポリシーが変化する。

GeoSiteが古い場合の代表的な症状

サービスが新しいドメインを使い始めても、既存のカテゴリに追加されていない。
広告カテゴリで、最近増えたトラッキングドメインをカバーできない。
新しいタグを設定で参照すると、対応するGeoSiteカテゴリが存在しないというログが出る。
データソースでタグ構成が変更された後も古いルールは読み込めるが、カバー範囲は変わっている。

1つのドメインが誤ったポリシーへ進んだだけで、データベースが古いとは限りません。ルール順序、DNSキャッシュ、Fake-IPマッピング、スニッフィング設定、ユーザーによる上書きでも起こります。判断するときは、まず接続画面で実際にマッチしたルールを確認し、対象ドメイン、対象IP、ポリシーグループと照合してください。

ログと接続履歴でルール連携を検証する

更新後はファイルの日付だけを確認しないでください。実際の接続がどのルールにマッチしたかを確認する方が有効です。クライアントの「接続」ページを開いて古い記録を消去し、プライベートアドレス、中国本土のサイト、デフォルトポリシーを使うサイトへ順にアクセスします。記録には対象ドメイン、対象IP、ルール種別、最終的なポリシーが表示されるはずです。

推奨する4つのテスト

プライベートネットワーク：ルーターやLAN上のサービスへアクセスし、GEOSITE,private、GEOIP,private、または明示的なネットワーク範囲のルールが優先してマッチすることを確認します。
ドメイン分類：分類が明確なドメインへアクセスし、GEOIPやMATCHへ直接進まず、GEOSITEにマッチすることを確認します。
IPフォールバック：対象IPだけがある接続で、GEOIPが想定どおりに振り分けるか確認します。
デフォルトルール：前述の分類に属さないドメインを選び、最後に MATCH で指定したポリシーグループへ進むことを確認します。

TUNモードでは、アプリの通信が最初にIP形式でコアへ渡される場合があります。MihomoはDNSマッピングとドメインスニッフィングを組み合わせて一部のドメイン情報を復元できますが、結果はプロトコル、暗号化方式、クライアント設定に左右されます。GEOSITEに長期間マッチしない場合は、データベースを何度も変更するのではなく、「設定」→「ネットワーク」にあるTUN、DNS、スニッフィングの項目も確認してください。

log-level: info

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

info レベルで通常は接続とルール結果を確認できます。データベースの読み込み失敗、DNSマッピング、スニッフィングの問題を調べる場合だけ、一時的に debug へ切り替えてください。調査後は元のレベルに戻し、大量のログが長期間蓄積しないようにします。

よくある更新失敗と対処の順序

ダウンロードは成功したのに再起動後も古い結果を使う

まず、新しいファイルがコアの作業ディレクトリに入っているかを確認します。インストール先やダウンロード先ではありません。次に geodata-mode を確認してください。設定がMMDBを要求している場合、GeoIP.datだけを置き換えてもGeoIPの判定方式は変わりません。GUIクライアントが複数のコアディレクトリを管理していることもあるため、現在有効なコアのログに表示されるパスを基準にします。

ログにGeoSiteタグが存在しないと表示される

通常はルールのタグとデータソースの基準が一致していません。まず GEOSITE,category-ads-all,REJECT のようなエラー対象のルールを特定し、現在のデータソースがそのカテゴリを提供しているか確認します。名前が似ているタグを完全に同じものと見なさないでください。保守プロジェクトによってカテゴリが統合、分割、改名されている場合があります。

起動時に自動更新がタイムアウトする

まず更新間隔を24時間に戻し、ダウンロードURLがデータファイルを直接返すことを確認します。初回導入時は、ネットワークに接続できる環境でデータベースを手動配置してからコアを起動しても構いません。これならリモート更新に一時的な失敗があっても、既存のルールを読み込めます。サーバー運用では、systemdのサービスユーザーに作業ディレクトリへの書き込み権限があるかも確認してください。

更新後に大量の通信が別のポリシーへ振り分けられる

すぐに一式のバックアップへ戻し、新旧データソース、タグのカバー範囲、ルール順序を比較します。データベース更新で分類結果は変わりますが、記録がない状態でルール、DNS、TUN設定まで同時に変更すべきではありません。一度に1つの要素だけを変えることで、ずれの原因がデータか設定かを判断できます。

再現可能なメンテナンス周期を作る

個人用のデスクトップでは、毎日自動チェックし、毎月手動で確認する運用が適しています。長期間稼働するサーバーでは、コアのバージョン、データベースの入手元、公開日、使用モード、直近の検証結果を記録してください。振り分け異常が起きたとき、この5項目の方が単に「更新済み」と記録するより役立ちます。

毎日：geo-auto-update が24時間間隔で確認します。
毎月：GeoIPとGeoSiteの提供元が現在も保守されているか確認し、4種類のルールを抜き打ちテストします。
コアのアップグレード後：geodata-mode、ファイル名、作業ディレクトリを再確認します。
データソース変更時：先にタグ一覧を確認してからルールを調整し、本番ファイルを直接上書きしません。
ずれが発生したとき：接続履歴、マッチしたルール、対象IP、ログの時刻を保存します。

GeoIPとGeoSiteの保守で重要なのは、更新頻度を最大化することではありません。データ形式、タグの基準、ルール順序、コアの作業ディレクトリを一致させることです。自動更新はファイル取得を担い、手動バックアップは復旧手段を提供し、接続履歴は最終的な振り分けを検証します。この3つがそろって初めて、データベースの更新が完了したと言えます。