上級設定 読了目安 12分

GeoIP・GeoSiteデータベースの更新方法：mihomoのルールデータ管理とよくあるエラー

GeoIP/GeoSiteデータベースの役割、保存先、更新方法を解説。クライアント内蔵更新、手動置換、ダウンロード失敗への対処、ルールが適用されない場合の確認ポイントまで紹介します。

GeoIPとGeoSiteは何を解決するのか

mihomoがプロキシルールを読み込む際は、ドメイン名、IPアドレス、その他の接続情報をルールと順番に照合します。GeoIPとGeoSiteはいずれもルール判定に必要なデータですが、対象は異なります。データベースが更新されていないからといって、すべてのプロキシ接続が切れるわけではありません。多くの場合は、地域判定が古い、新しいドメインに一致しない、起動時にデータファイルが見つからないといった形で現れます。

GeoIPは宛先IPの地域で分類する

GeoIPデータには、IPアドレス範囲と国・地域などの情報との対応関係が記録されています。設定の GEOIP,CN,DIRECT は、接続先IPが確定した後、そのアドレスがCN分類に該当すればDIRECTポリシーを使用するという意味です。代表的なファイルには Country.mmdb と geoip.dat があり、どちらを読み込むかはmihomoの設定、クライアントのバージョン、データモードによって異なります。

GeoIPによる判定はIP層で行われます。ドメインが誤ったアドレスに解決された場合、DNSの応答が汚染されている場合、または前段のドメインルールにすでに一致している場合、後段のGEOIPルールで判定結果は変わりません。「中国国内のサイトがプロキシ経由になる」場合は、データベースの日付だけでなく、ルールの順序とDNSの結果も確認してください。

GeoSiteはドメインの集合で分類する

GeoSiteには整理済みのドメイン集合が保存されています。たとえば GEOSITE,cn,DIRECT はcn分類のドメインに一致させるために使い、GEOSITE,category-ads-all,REJECT は該当する分類の処理に利用できます。代表的なデータファイル名は geosite.dat です。GeoSiteはサーバーのIPがどの国に属するかを判定するものではなく、リクエスト中のドメインを直接処理します。

ドメインサービスに新しい入口が追加されたり、CDNドメインが変更されたり、APIが置き換えられたりすると、古いGeoSiteに対応する記録がない場合があります。このとき接続は通常、MATCH など後続のルールに進むだけで、「データベースが古い」という通知が表示されるとは限りません。GeoSiteの問題がノードやサブスクリプションの障害と誤認されやすいのはこのためです。

データの種類 主な入力 代表的なルール 一般的なファイル
GeoIP 宛先IPアドレス GEOIP,CN,DIRECT Country.mmdb、geoip.dat
GeoSite リクエストのドメイン GEOSITE,cn,DIRECT geosite.dat
Rule Provider 外部ルール項目 RULE-SET,private,DIRECT YAML、テキスト、またはバイナリ形式のルールセット

更新前にカーネル、モード、実際のデータディレクトリを確認する

同じデスクトップクライアントでも、過去にClash Premium、Clash Meta、mihomoの各カーネルを使っていた可能性があります。古い設定ディレクトリに同名ファイルが複数残っていることもあります。手動で置き換える前に、クライアントの「バージョン情報」「カーネル」「実行ログ」画面で現在のカーネルを確認してください。現在も保守されているmihomo安定版の使用を推奨し、更新前のカーネルバージョンとデータファイルの更新日時を記録しておきましょう。

起動パラメータからディレクトリを特定する

mihomoのデータディレクトリは通常、起動パラメータ -d で指定されます。たとえば起動コマンドに mihomo -d /home/user/.config/mihomo とある場合、データベースは実行ファイルのある場所ではなく、そのディレクトリに配置します。デスクトップクライアントは独自のデータディレクトリを渡すため、OSだけを基準にパスを推測しないでください。

  • まずクライアントの「設定」→「設定ディレクトリ」または「データディレクトリを開く」を利用してください。
  • 画面に入口がない場合は、実行ログの冒頭で configuration directory、home directory、または -d の後に続くパスを探します。
  • Windowsでは、タスクマネージャーのプロセス詳細で実行ファイルを確認し、クライアントのログから起動パラメータを確認できます。
  • macOSクライアントのデータは通常ユーザーのライブラリ内にありますが、アプリごとにコンテナの場所が異なるため、ログと画面の入口を基準にしてください。
  • Linuxでsystemdがサービスを起動している場合は、systemctl cat mihomo で ExecStart 内の -d パラメータを確認できます。

MMDBとDATのどちらを使っているか確認する

mihomoは複数の地理データ形式に対応しています。geodata-mode: true を有効にしている場合は、通常 geoip.dat と geosite.dat を組み合わせます。無効な設定では、GEOIP判定に Country.mmdb を使うことがあります。バージョンによって初期動作が変わる可能性があるため、設定と起動ログを両方確認し、ファイルの有無だけで判断しないでください。

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

geo-update-interval の単位は時間です。24 に設定すると、カーネルは1日間隔でデータの更新を確認します。クライアントが実行用設定を生成する場合、生成ファイルを直接編集しても次回起動時やサブスクリプション切り替え時に上書きされます。これらのキーはクライアントのオーバーライド、Mixin、グローバル拡張設定に追加してください。

まずクライアント内蔵の更新を使う

mihomoに対応するクライアントには、通常GeoDataや地理データの更新機能があります。画面名はバージョンによって異なりますが、「設定」→「Clash設定」→「GeoData」、または「設定」→「カーネル」→「地理データを更新」といった場所にあります。操作中は連続してクリックしないでください。1回のダウンロードで数十MBのデータを取得することがあり、通信が遅い場合はログに完了状態が表示されるまで待つ必要があります。

  1. まず更新を行い、現在の設定を有効にして、カーネルが正常に起動することを確認します。
  2. 「設定」にあるGeoData、地理データ、またはカーネルデータのページを開きます。
  3. GeoIP、GeoSite、またはすべてのデータを個別に更新します。
  4. 画面に完了と表示されるまで待ち、ログに download、unmarshal、permission denied などの情報がないか確認します。
  5. 設定を再読み込みします。再読み込みボタンがない場合は、アプリを完全に終了してから再起動してください。
  6. 接続履歴で、既知のドメインが実際にどのルールへ一致したか確認します。

内蔵更新の利点は、クライアントが自身のデータディレクトリを把握しており、ダウンロード後に正しいファイル名で保存できることです。サービスモードや管理者権限の補助プロセスを使うデスクトップクライアントでは、一般ユーザーのプロセスにディレクトリへの書き込み権限がない問題も避けられます。

mihomoの自動更新を有効にする

ルーター、サーバー、デスクトップ端末を長期間稼働させる場合は、mihomoに定期更新させることができます。geo-auto-update を有効にするほか、geox-url で各ファイルのURLを指定できます。URLは対応するバイナリファイルを直接返す必要があり、リリース紹介ページやブラウザーでの確認が必要なHTMLページは指定できません。

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"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

ダウンロード先へのアクセスにプロキシが必要な端末では、まずカーネル起動後に外向きの接続を確立できる状態にしてください。初回起動時はデータベースが存在せず、ルールがGeoSiteに依存していると、「データベースがないため起動できないが、カーネルが起動しないのでダウンロードもできない」という循環に陥ります。その場合は、先に読み込み可能なデータファイルを手動で配置してから自動更新を有効にするのが安全です。

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

クライアント内蔵の更新に失敗した場合、オフライン端末を保守する場合、または現在のネットワークからデータソースへアクセスできない場合は、手動で置き換えます。読み込み中のファイルを直接上書きするのではなく、一時ファイル名でダウンロードし、カーネルを停止してから置き換え、最後に再起動するのが正しい手順です。これにより、ダウンロード中断で不完全なファイルが残る可能性を抑えられます。

基本的な置き換え手順

  1. クライアントでシステムプロキシとTUNを停止してからアプリを終了します。サービスモードの場合は、対応するバックグラウンドサービスも停止してください。
  2. 前述の方法で確認したデータディレクトリを開き、元ファイルのサイズと更新日時を記録します。
  3. 旧ファイルを geoip.dat.bak、geosite.dat.bak、または Country.mmdb.bak にリネームします。
  4. 新しいファイルを同じディレクトリへコピーし、カーネルが要求する正確なファイル名を維持します。
  5. 現在のユーザーまたはサービスアカウントに読み取り権限があることを確認します。
  6. クライアントを起動し、最初のログを確認します。設定の読み込み完了を確認してから、システムプロキシまたはTUNを有効にしてください。
  7. 検証が終わるまでバックアップを残し、よく使うドメインのルールが正常に動作することを確認してから削除します。

LinuxまたはmacOSでは、一度一時ファイルへ書き込んでから、同じファイルシステム内でリネームして置き換える方法が使えます。以下のコマンドはmihomoの実際のデータディレクトリで実行してください。

curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" -o geoip.dat.new
curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" -o geosite.dat.new

mv geoip.dat geoip.dat.bak
mv geosite.dat geosite.dat.bak
mv geoip.dat.new geoip.dat
mv geosite.dat.new geosite.dat

Windowsで手動置換中にエクスプローラーがファイルの使用中を通知する場合、クライアントのウィンドウを閉じてもカーネルプロセスまたはサービスが動作しています。クライアントでサービスを停止するか、「タスクマネージャー」→「詳細」でmihomoプロセスが終了していることを確認してください。使用中の通知を無視するために、何度も上書きしないでください。

コンテナとルーターで追加確認する項目

Docker環境では、データベースのディレクトリが、コンテナで使用する -d のパスへ本当にvolumeマウントされているか確認してください。ホスト側の未マウントディレクトリだけを置き換えても、コンテナ内部は変わりません。更新後はコンテナを再起動し、ログで読み込みパスを確認できます。OpenWrtのように容量が限られる端末では、空き容量も確認してください。一時ファイルのダウンロードとバックアップの保持により、一時的な使用量がデータファイルの2〜3倍近くになることがあります。

ダウンロード失敗と起動エラーへの対処

context deadline exceeded またはTLSタイムアウト

この種のメッセージは、ダウンロード先との接続または転送が制限時間内に完了しなかったことを示します。まずブラウザーまたは curl -I -L で同じURLにアクセスし、リダイレクトを追跡できるか確認します。続いてDNS、システム時刻、外向き通信のポリシーを確認してください。システム時刻が数分ずれているだけでも、TLS検証に失敗することがあります。接続にプロキシが必要な場合は、更新リクエストが実際に利用可能なポリシーを使っているか確認し、GEOIPやMATCHルールによって無効なノードへ送られていないことを確かめます。

403、404が返る、またはHTMLをダウンロードしてしまう

404は通常、ファイル名、公開パス、またはデータソースの構成が変更されたことを意味します。403は、アクセス頻度の制限、ネットワーク出口の制限、追加認証が必要なURLなどで発生します。また、URLがリリース紹介ページを指しており、実際にはHTMLをダウンロードしている場合もあります。その後mihomoは解析失敗、無効な形式、データベースを読み込めないといったエラーを出します。直接ファイルを返すURLへ変更し、リダイレクト後のレスポンスタイプとファイルサイズが妥当か確認してください。

permission denied またはファイルを書き込めない

まず、エラーに表示されたパスが現在のデータディレクトリと一致しているか確認します。Windowsのサービスモードでは、画面のプロセスとバックグラウンドサービスが異なるアカウントで動作する場合があります。Linuxのsystemdサービスでも、User= によって権限を制限したアカウントが指定されることがあります。そのサービスアカウントには、一時ファイルの作成、ファイルのリネーム、更新結果の読み取りを許可する必要があります。古いファイルだけに書き込み権限を付与しても、ディレクトリに書き込めなければ失敗します。

no such file、MMDBを開けない、またはGeoSiteの読み込みに失敗する

この種のエラーでは、まずファイル名の大文字・小文字、設定モード、ディレクトリを確認します。Linuxでは GeoSite.dat と geosite.dat は別のファイルです。設定でgeodataモードを有効にしているのに Country.mmdb しか配置していなければ、GeoSiteルールは動作しません。逆に、MMDBを必要とする設定では geoip.dat だけでは不十分です。バックアップを戻すと起動できる場合は、新しいファイルが不完全、形式が不適合、または現在のカーネルと互換性のない提供元のものである可能性が高いです。

データベースを更新したのに、ルールが適用されない理由

ルールエンジンは設定の順序に従って上から下へ照合し、一致すると通常は「より適切な」ルールを探し続けません。データベースの更新で変わるのは、GEOIPやGEOSITEが検索できるデータだけで、ルールの順序が自動的に調整されるわけではありません。確認時は接続履歴から対象リクエストを探し、ドメイン、宛先IP、一致したルール、最終ポリシーを確認してください。

前段のルールがリクエストを先に捕捉している

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

この設定では、example.com がGeoSiteのcn分類に収録されていても、最初の DOMAIN-SUFFIX が先にProxyへ一致します。GeoSiteを更新しても、前段のルールは上書きされません。特定のルールを一時的に適切な位置へ移動し、再読み込み後にもう一度テストすれば、順序が原因か確認できます。

no-resolve がGEOIPの適用条件を変えている

GEOIP,CN,DIRECT,no-resolve の役割の1つは、ルール照合のために追加のDNS解決を自動実行しないことです。現在の接続がドメイン名だけで、判定に使える宛先IPがまだない場合、このルールは期待どおりに動作しない可能性があります。設定にGEOSITEのドメインルールがある場合は、まずドメインで分類し、残りのIP接続をGEOIPで処理すると、ロジックが分かりやすくなります。

DNSモードとスニッフィング結果が見えるドメインに影響する

TUNモードでは、アプリがIPへ直接接続する場合もあれば、QUIC、暗号化DNS、内蔵リゾルバー経由でリクエストを開始する場合もあります。mihomoがドメイン名を取得できなければ、GeoSiteには照合対象がありません。ドメインスニッフィングで一部のケースを補えることはありますが、すべての接続でドメイン名を復元できるとは限りません。システムプロキシモードとTUNモードの接続詳細を比較し、履歴に完全なドメイン名が表示されているか確認してください。

編集しているのがサブスクリプションの元ファイルではなく、実行用設定になっている

デスクトップクライアントでは、サブスクリプション、オーバーライド、グローバル設定を一時的な実行用設定に統合することがよくあります。キャッシュされたサブスクリプションのYAMLを直接編集しても、次回のサブスクリプション更新で元に戻ります。実行用設定を直接編集すると、次回の設定切り替えで消えます。クライアントの「設定」→「オーバーライド」または「設定」→「グローバル拡張」にカスタム項目を保存し、ログや設定検証機能で最終結果を確認してください。

Rule ProviderがGeoDataと一緒に更新されていない

RULE-SET が参照する外部ルールセットは rule-providers で管理され、固有のURL、キャッシュパス、更新間隔を持ちます。geoip.dat や geosite.dat を更新しても、これらのProviderは更新されません。実際に一致しているのが RULE-SET なら、クライアントのルールセット画面で更新を実行するか、該当Providerの interval とダウンロードログを確認してください。

繰り返し実行できるメンテナンスチェックリスト

一般的なデスクトップ端末では、データベースを毎日手動で置き換える必要はありません。クライアントまたはmihomoに24時間ごとの確認を行わせ、分類に異常が出たときだけ決まった手順で調査する方が実用的です。サーバーやルーターでは、データディレクトリ、バックアップ、サービスアカウントの権限をまとめて管理対象にしてください。

  • 現在mihomoカーネルを使用していることを確認し、バージョン番号を記録する。
  • 起動パラメータまたはログから、実際のデータディレクトリを確認する。
  • 設定がDATモードとMMDBモードのどちらを使用しているか確認する。
  • まずクライアント内蔵の入口から1回更新する。
  • ログを確認し、ダウンロード、書き込み、再読み込みがすべて完了したことを確認する。
  • 手動で置き換える場合は、先にカーネルを停止し、復元可能な旧ファイルを1つ残す。
  • 接続履歴で、ドメイン、宛先IP、一致したルール、最終ポリシーを検証する。
  • GeoData、サブスクリプションのルール、Rule Providerを個別に確認し、3つを同じ更新項目として扱わない。
  • 結果がまだ異常な場合は、ルールの順序、DNS、TUN、スニッフィング、実行用設定の順に確認する。

メンテナンスが成功したかどうかを、ボタンに「更新完了」と表示されただけで判断してはいけません。少なくともGeoSiteのドメインルール、GEOIPのIPアドレスルール、Rule Providerのルールを1つずつ選んでテストしてください。接続履歴に期待したルール名とポリシーが表示され、クライアント再起動後も結果が維持されて初めて、ファイルパス、設定モード、更新機能が正しく連携したと判断できます。

Clash最新版をダウンロード