#GeoIP と GeoSite データベースの更新方法:保存先パス、自動更新設定、よくあるエラー対処

##GeoIP と GeoSite はそれぞれ何を解決するのか

分流ルールを書いたことがある人ならこの2行を見たことがあるはずです。

GEOIP,CN,DIRECT
RULE-SET,geosite-cn,DIRECT

1行目はIPアドレスから所属地域を判定し、2行目はドメインリストからサイトの帰属を判定します。この2つのルールの背後にはそれぞれ異なるデータファイルが存在し、その違いを理解することがルール不発の原因を突き止める前提になります。

geoip.metadbはIPアドレス範囲と国コードの対応表で、MMDBというバイナリ形式で保存されています。GEOIP,CN,DIRECTのように書かれたルールでは、mihomoコアが接続先のIPをこの表に照会し、国コードがCNであれば直結にマッチします。この表がカバーするのはIPv4・IPv6のアドレス範囲区分であり、ドメイン自体とは直接関係がありません——同じドメインが解決するIPが今日は中国国内、翌日には海外のノードに切り替わることもあり、これがIP判定だけだと結果が「ぶれる」ことがある理由の一つです。

geosite.datはカテゴリ別に整理されたドメインリストで、Protobuf形式で圧縮保存されています。よく使われるカテゴリにはcn、google、netflix、category-ads-allなどがあります。ルールセットの書き方は通常、まずrule-providersでgeositeベースのルールセットを宣言し、それをrulesで参照するか、一部のコアではGEOSITE,cn,DIRECTのような簡略記法も使えます。ドメイン照合はDNS解決やリクエスト送信の前に行われ、判定基準はドメイン文字列そのものであって解決結果ではないため、IPが頻繁に切り替わるCDN系サイトに対してはgeositeの方がgeoipより安定した判定になることが多いです。

両方を併用するのが一般的な方法です。ドメインで判定できるものはgeosite、判定できない残りのトラフィックはgeoipで宛先IPの地域を見て振り分けます。どちらのファイルが欠けていたり古くなっていたりしても、対応するルール群がまるごと効かなくなるだけで、エラー表示が出るわけではありません——この点がこの種の問題を早期に見つけにくくしている要因です。

##データベースファイルの保存先とディレクトリ構成

mihomoコアは起動時にこの2つのファイルを決まった順序で探しに行きます。1つのパスを覚えるより、この探索ロジックを理解しておく方が実用的です。

1. コアの作業ディレクトリ(Home Dir)が最優先。多くのGUIクライアントはコアに専用の作業ディレクトリを指定しており、geoip.metadb、geosite.dat、country.mmdb(一部バージョンではgeoip.metadbの代わりにこのファイル名を使う)はこのディレクトリのルート直下、config.yamlと同階層にダウンロードされ、サブフォルダに散らばることはありません。
2. 次に設定ファイルのあるディレクトリ。作業ディレクトリが個別指定されていない場合、コアは現在使用中の設定ファイルがあるフォルダに戻ってこれらのファイルを探し、見つからなければ初回ダウンロードが発生します。
3. システムレベルの既定ディレクトリが最後の手段。Linuxでは~/.config/clash/や~/.config/mihomo/、Windowsではクライアントのインストールディレクトリ内のdataサブディレクトリ、macOSではクライアントのApplication Supportディレクトリでよく見られます。クライアントによってこのフォールバック先の名称は統一されていないため、ファイルが見つからない場合はクライアントの「設定」または「バージョン情報」画面で実際の作業ディレクトリを確認する方が、ファイルシステムを手当たり次第に探すより早道です。

パスを確認したら、ファイルのプロパティで更新日時を直接確認するのが「長らく更新されていないかどうか」を判断する最も直接的な方法です——クライアントを何度も再起動して推測するよりずっと確実です。

##geodata-mode と geo-auto-update の書き方

地理データベースを使うかどうか、どのくらいの間隔で自動的に更新確認をするかは、config.yaml内のいくつかのフィールドで制御します。典型的な書き方は次のとおりです。

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/geoip.metadb"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/country.mmdb"

各フィールドの意味:

• geodata-mode:地理データベースに基づく照合を有効にするかどうか。falseの場合、GEOIPやgeosite関連のルールは読み込まれず、ルールファイルに書いてあっても空ルールと同じになります。明確に不要な場合を除き、trueのままにしておくのが無難です。
• geodata-loader:データベースの読み込み方式。standardは全量をメモリに読み込むため検索は速いですがメモリ消費がやや多く、一部バージョンではmemconservativeのような低メモリモードも提供されており、リソースの限られたルーター機器に向いています。
• geo-auto-update:コア稼働中に自動でデータベース更新をチェックするかどうか。デフォルトが有効か無効かはクライアントのバージョンによって異なるため、一度手動で現在の値を確認しておくとよいでしょう。
• geo-update-interval:自動更新チェックの間隔(単位:時間)。短すぎると不要な通信が増えるため、一般的には24〜72時間程度が妥当な範囲です。
• geox-url:3つのファイルそれぞれのダウンロード元。既定のソースがネットワーク環境によって遅い場合は、同じプロジェクトのミラーアドレスに置き換えられますが、ファイルの内容とフォーマットバージョンが対応していることが前提です。異なるプロジェクトのルールデータベースを混用すると解析エラーが起きやすくなります。

注意点として、geo-auto-updateはコアが継続稼働している場合にのみ意味を持ちます——クライアントを終了するたびにコアプロセスも終了する仕組みの場合、次回起動時に更新を再チェックするかどうかはクライアント自身の起動フローに依存し、このフィールドの動作と完全に一致するわけではありません。

##手動更新の具体的な手順

ほとんどのGUIクライアントでは設定ファイルを直接触る必要はなく、更新用の入口は通常設定画面にあり、「GeoIPデータベースを更新」や「地理データを更新」といったボタンがよく見られる形です。クリックするとクライアントがコアのAPIを呼び出してダウンロードをトリガーし、ネットワーク状況によって数秒から数十秒で完了します。

クライアントにGUIの入口がない場合や、更新が本当に反映されたか確認したい場合は、次の手順が使えます。

1. コアのRESTful APIのポートとキー(通常はconfig.yamlのexternal-controllerとsecretフィールド)を確認します。これらはコアのインターフェースを呼び出すための前提条件です。
2. インターフェース経由で更新をトリガーします。典型的なリクエストはコアの/configs/geo(バージョンによってパスが異なる場合があります)に更新命令を送るもので、正確なパスは使用しているコアバージョンのAPIドキュメントに従ってください。
3. 更新完了後にクライアントログまたはコアログを確認し、「GeoIP database update completed」のような表示や、明確なダウンロード成功メッセージが出ているかを確認します。画面上でエラーが出ていないだけで成功と判断しないようにしましょう。
4. コアまたはクライアントを一度手動で再起動し、更新済みのデータベースファイルをルールに再読み込みさせます。更新は完了していてもルールマッチャーがホットリロードされないケースもあるため、再起動が最も確実な方法です。

自動化された入口がどうしても見つからない場合は、ファイルを手動でダウンロードして置き換える方法も有効です。データベースの配布元リポジトリのReleasesページから最新のgeoip.metadbとgeosite.datをダウンロードし、作業ディレクトリ内の古いファイルを置き換えてコアを再起動します。置き換え前に旧ファイルをバックアップしておけば、新しいファイルが破損していたりフォーマットが合わなかったりした場合にすぐ戻せます。

##よくあるエラーとルール不発の確認手順

この種の問題の多くは明確なエラー表示が出るわけではなく、「ルールが効いていないようだ」という形で現れます。以下の順序で1つずつ確認していく方が、手当たり次第に試すよりも効率的です。

ダウンロード失敗またはタイムアウト

ログに接続タイムアウトやTLSハンドシェイク失敗のような文字列が出ている場合、たいていはネットワーク経路の問題です——プロキシがまだ確立されていない状態では、コアがダウンロード元に直接アクセスすること自体がネットワーク環境によって制限される可能性があります。まずはgeox-url内のアドレスを一時的にミラーソースに切り替えるか、プロキシが確立された後に改めて手動で更新をトリガーしてみてください。

ファイルはダウンロード済みなのにルールがマッチしない

まずgeodata-modeがtrueになっているかを確認してください。これは見落とされがちなポイントです。次に、ルールに書かれた地域コードやカテゴリ名が現在のバージョンのデータベースに存在するかを確認してください。例えばgeosite-cnのようなカテゴリ名は、ルールセットプロジェクトのバージョンによって名称変更や分割が行われている場合があり、古い設定をそのまま流用するとこの落とし穴にはまりやすいです。

ルールセット読み込み時に「rule provider not found」やフォーマットエラーが出る

この種のエラーは、rule-providers内のbehaviorフィールドが実際のファイル形式と一致していないことが原因でよく発生します。geosite系のルールセットにはbehavior: domainを、IPセグメントベースのルールセットにはbehavior: ipcidrを指定する必要があり、逆に書くとコアがファイル内容を正しく解析できずフォーマットエラーになります。

rule-providers:
  geosite-cn:
    type: http
    behavior: domain
    url: "https://example.com/geosite-cn.txt"
    path: ./rule-providers/geosite-cn.yaml
    interval: 86400

更新後も動作が変わらない

更新によって本当に正しいパスのファイルが置き換えられたかを確認してください——クライアントの設定ファイルがあるディレクトリと、コアが実際に使用する作業ディレクトリが同じでない場合、更新スクリプトが書き込む場所とコアが読み込む場所が食い違い、「更新したのに変わらない」という状況になります。第2章のパス優先順位の説明に戻って確認すれば、たいてい問題箇所を特定できます。

これらの項目を順に確認していけば、原因がネットワーク・設定フィールド・ファイルパス・ルールセットフォーマットの4つのうちどれに当たるかをほぼ特定でき、あとはそれに応じて対処するだけで済みます。クライアントの再インストールや設定ファイル全体の書き直しは不要です。