GeoIP・GeoSiteデータベースの更新方法とルール設定
GeoIP・GeoSiteデータの用途と保存場所、手動・自動更新の設定、config.yamlでのGEOIP・GEOSITEルールの書き方を解説します。
GeoIPとGeoSiteの違い：IPの地域判定とドメイン分類
GeoIPは接続先IPの地域情報による判定に使い、GeoSiteはドメインのリストによる判定に使います。どちらもルール判定に使うデータであり、プロキシノードを提供したり、サブスクリプションの代わりになったりするものではありません。データベースを更新すると、ルールが参照するデータが変わりますが、ノードが追加されたり接続設定が変更されたりするわけではありません。
この記事の設定例は、mihomoコアを使うクライアントを対象としています。Clash Metaは同コアの旧称です。旧Clashコアや各種フォーク、GUIクライアントの実装には違いがあるため、クライアント名だけで全項目に対応しているとは判断できません。操作前に、クライアントの「バージョン情報」または起動ログの冒頭で、実際に使われているコア名を確認してください。
| データの用途 | 主なファイル | 対応するルール・設定 |
|---|---|---|
| IPの地域判定（MMDB形式） | Country.mmdb | GEOIP；geodata-mode: false |
| IPの地域判定（DAT形式） | geoip.dat | GEOIP；geodata-mode: true |
| ドメインリストによる判定 | geosite.dat | GEOSITE |
geodata-modeはGeoIPデータの形式を指定する項目で、GeoSite全体の有効・無効を切り替えるものではありません。MMDB形式を使っていても、コアが対応し、設定でGEOSITEを参照している場合は、geosite.datが必要になることがあります。「Country.mmdbを更新したから、ドメイン分類データも更新済み」とは限りません。
データの保存先は、実行中のコアのデータディレクトリで確認
クライアントのインストール先、サブスクリプションファイルの保存先、コアのデータディレクトリは、それぞれ異なる場合があります。まずクライアントの設定画面やメニュー、またはトレイメニューから「設定ディレクトリを開く」「データディレクトリを開く」などの項目を探してください。名称はクライアントによって異なります。開いた場所にあるCountry.mmdb、geoip.dat、geosite.datを確認し、ダウンロードフォルダにそのまま保存しないでください。
mihomoを単独で実行している場合は起動引数を確認
コマンドラインから起動する場合は、-dで作業ディレクトリを指定できます。以下はLinuxでの例です。データディレクトリは/var/lib/mihomo、設定ファイルは別の/etc/mihomo/config.yamlに置いています。両者を同じフォルダに置く必要はありません。
mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml- 手動起動：実際に使用しているコマンドを確認します。ターミナルの現在のディレクトリだけを見ても判断できません。
- systemdサービス：
systemctl cat mihomoでサービス定義のExecStartと実行ユーザーを確認します。サービス名は、実際の環境に合わせてください。 - コンテナで実行：コンテナ内のデータディレクトリに対応するホスト側のマウント先を確認し、その場所にファイルを配置します。
- GUIクライアント：ファイルが現在有効なコアのインスタンス用であることを確認します。停止中の別クライアントのものと間違えないでください。
ファイル名の大文字・小文字も区別されます。LinuxではCountry.mmdbとcountry.mmdbは別のファイルです。コアによってはファイル名や保存場所を変更できるため、実際に有効な設定とログに記録されたパスを確認してください。
手動更新：バックアップして置き換え、再読み込み
手動更新は、データベースを初めて用意するとき、自動ダウンロードに失敗したとき、または以前のデータに戻したいときに便利です。まずMMDB形式とDAT形式のどちらを使っているか確認し、対応する形式をダウンロードしてください。データの配布元が、mihomo対応のファイルを提供し、収録範囲と分類名を明示していることも確認します。メンテナンス元によって分類の種類や内容が異なる場合があります。
- 現在の状態を記録。有効な設定を保存し、ファイルのパス、更新日時、現在のデータ配布元を記録します。古いファイルはすぐに削除せず、バックアップ用のフォルダにコピーしてください。
- コアを停止。クライアントからコアのサービスを停止するか、クライアントを終了してバックグラウンドのコアも停止したことを確認します。サービスとして実行している場合は、該当するサービスを停止してください。
- ダウンロードしたファイルを確認。データベース本体であることを確認します。圧縮ファイル、プロジェクトの説明ページ、ダウンロード失敗時に保存されたHTMLページではありません。圧縮ファイルの場合は、先に展開して正しいファイルを使ってください。
- 元のパスに配置。MMDB形式なら
Country.mmdb、DAT形式ならgeoip.datを置き換えます。ドメイン分類を更新する場合はgeosite.datを置き換えてください。 - 読み取り権限を確認。コアの実行ユーザーに、ディレクトリへのアクセス権とファイルの読み取り権が必要です。自動更新を使う場合は、データディレクトリへの書き込み権も必要です。
- 再起動して確認。コアを起動し、データベースの読み込み失敗、分類名の未登録、権限不足などのエラーがないかログを確認します。そのうえで、新しい接続が想定したルールに一致するかテストしてください。
ディスク上のファイルを置き換えても、メモリ上のデータがすぐに更新されるとは限りません。クライアントによってホットリロードの動作が異なるため、手動で置き換えた後にコアを再起動すると、新しいファイルが読み込まれたか確認しやすくなります。置き換え後に起動できない場合は、まずコアを停止してバックアップを戻し、ファイル形式が合っているか確認してください。ファイルの問題を隠すためにルールを次々と変更しないでください。
自動更新：更新間隔とダウンロード元の設定
これらの項目に対応するmihomoコアでは、設定ファイルのトップレベルでデータベースの自動更新を有効にできます。以下の例ではDAT形式を選び、更新間隔を24時間に設定しています。サブスクリプションの更新間隔ではなく、接続のたびにデータベースをダウンロードする設定でもありません。
geodata-mode: true
geodata-loader: memconservative
geo-auto-update: true
geo-update-interval: 24geodata-loaderはDATデータの読み込み方法を指定します。memconservativeはメモリ消費を抑えるローダーです。ダウンロード先を決めたり、ルールの優先順位を変えたりする項目ではありません。MMDB形式を使い続ける場合は、geodata-modeをfalseに設定してください。自動更新を有効にするためだけに、形式を無理に切り替える必要はありません。
geox-urlのキーとファイル形式を対応させる
配布元を指定する場合は、トップレベルのgeox-urlマップにダウンロード先を設定します。geoipはGeoIP DAT、geositeはGeoSite DAT、mmdbはMMDBに対応します。プロジェクトのトップページやログイン操作が必要なページではなく、データのメンテナンス元が案内する完全なHTTPSファイルURLを指定してください。
この記事では、固定のデータ配布URLは案内していません。分類ルールが利用できるかどうかは、選んだデータプロジェクトによって異なります。クライアントに設定済みの信頼できる配布元を使う場合、geox-urlを追加する必要はありません。クライアント側で配布元が上書きされている場合は、最終的に適用される設定を確認してください。サブスクリプションの元データだけでは判断できません。
- サブスクリプション管理の設定：クライアントの上書き・マージ・拡張機能を使ってトップレベルの項目を追加し、次回のサブスクリプション更新で消えないようにします。
- 個別の設定ファイル：実際の起動時に使われる設定ファイルを直接編集します。同じ名前のトップレベルキーを重複して記述しないでください。
- ダウンロードに失敗：まずログでリクエスト先のURLとエラーの種類を確認し、ネットワーク、システム時刻、ディスク容量、ディレクトリの権限を調べてください。
GEOIP・GEOSITEルールの書き方：ルールの順序で判定結果が変わる
ルールモードでは上から順に照合され、通常は最初に一致したルールで通信先が決まります。以下の例では、特定のドメインを先に処理し、続いてGeoSiteの分類、GeoIPによるIP判定を行い、最後にデフォルトのポリシーグループへ振り分けます。例では、現在のサブスクリプションに「ノード選択」というポリシーグループが定義されているものとします。そのグループがない場合は、設定に実在する名前に変更してください。
mode: rule
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,ノード選択GEOSITE：分類名はデータベースで確認
GEOSITE,cn,DIRECTは、現在のGeoSiteデータベースにあるcnのドメインリストに一致した通信をDIRECTに振り分ける設定です。ドメイン末尾の.cnを単純に判定するものではありません。cnやほかの分類を使えるかどうかは、データのメンテナンス元が公開している分類一覧で確認してください。データ配布元を変更した場合は、既存ルールで参照している分類が引き続き存在するか再確認しましょう。
GEOIP：no-resolveはDNS問い合わせをすべて止めるものではない
GEOIP,CN,DIRECT,no-resolveは、接続先IPの地域情報で判定し、このIPルールの確認だけを目的とした未解決ドメインの新たな名前解決を避ける設定です。リクエストに接続先IPがすでに含まれていれば、判定対象になります。このオプションはDNSを全体的に無効にするものではなく、アプリ自身が行う名前解決も止めません。
ドメインルールに一致しないリクエストも、名前解決後のIPで地域判定したい場合は、用途に応じてno-resolveを外してください。その場合、ルールの判定に追加のDNS問い合わせが必要になることがあります。Fake-IPを使っている場合は、接続先ドメインの復元、すでに得られている名前解決結果、リクエストの経路によっても動作が変わります。接続ログを確認し、ルールの記述だけから判断しないでください。
MATCH：デフォルトルールは必ず最後に置く
MATCHは、それ以前のルールに一致しなかったリクエストを受け取ります。GEOSITEやGEOIPより前に置くと、後続のルールは適用されません。特定ドメイン向けの例外ルールは、通常、大まかな分類ルールより前に置きます。後ろに置くと、データベースにそのドメインが含まれていても、想定と異なる経路になることがあります。
GeoIPの地域情報は、サーバーの所有者やサービスの所属地域を証明するものではありません。CDNや複数地域への分散配置、Anycastを利用するサイトでは、ドメイン分類とIPの地域情報が一致しないことがあります。特定のサービスを決まったポリシーに振り分けたい場合は、国・地域の判定だけに頼らず、ドメインを指定したルールを追加してください。
更新後も振り分けられないときは、有効な設定・ログ・新しい接続を確認
確認時は、「ファイルの更新に成功したか」と「通信がルールに一致したか」を分けて考えてください。データベースの読み込み成功は、データを読み取れたことを示すだけです。ルールを適用するには、通信がそのコアに届き、ルールモードで動作している必要があります。
| 症状 | まず確認すること | 確認・修正する場所 |
|---|---|---|
| 分類が存在しないというエラー | データベースにルールで指定した分類名が含まれているか | データ配布元の分類一覧とGEOSITEルール |
| ファイルが見つからないというエラー | 作業ディレクトリ、ファイル名の大文字・小文字、データ形式 | 起動引数とコアのデータディレクトリ |
| データを解析できないというエラー | Webページ、圧縮ファイル、または別形式のファイルをダウンロードしていないか | ダウンロードしたファイルと対応するデータベースファイル |
| ファイルは更新済みだが、ルールに一致しない | 前にあるルール、動作モード、接続先のドメインまたはIP | 有効な設定と接続の詳細 |
| サブスクリプションを更新するたびに設定が消える | 一時的に生成されたファイルだけを編集していないか | クライアントの上書き設定・マージ設定 |
- 最終的な設定を確認。稼働中の設定に
rules、geodata-mode、更新関連の項目が含まれていることを確認してください。無効な設定ファイルを編集しただけでは反映されません。 - ルールモードを確認。全体モードや直結モードでは、このルール一覧を使った場合と同じ結果にはなりません。
- 新しい接続でテスト。テスト対象のサイトで既存の接続を閉じてから、再度アクセスしてください。確立済みの長時間接続は、データベースを更新してもすぐには経路が変わらないことがあります。
- 接続の詳細を確認。接続先ドメイン、接続先IP、一致したルール、最終的なポリシー経路を記録します。変更は一度に一項目ずつ行い、前後を比較してください。
- 通信の入口を確認。システムプロキシが適用されるのは、その設定に従うアプリだけです。TUNが処理できる通信の範囲も、ルーティングや除外設定によって変わります。コアに届かないリクエストはGeoルールに一致しません。
一時的な調査ではログレベルを上げ、調査後は通常のレベルに戻してログの肥大化を防いでください。ログを共有する際は、サブスクリプションURL、トークン、ノードの認証情報、機密性の高いアクセス記録を伏せます。配布元を何度も変えるより、復元可能な設定とデータベースのバックアップを残しておくほうが、問題の切り分けに役立ちます。