上級テクニック · 読了目安 9分

GeoIPとGeoSiteデータベースの更新方法：分流ルールがずれたときの調査と修正

分流が急に中国国内サイトまでプロキシ経由になった、あるいは海外サービスが直接接続と判定されるようになった――多くの場合、ルールの記述が間違っているわけではなく、ローカルのGeoIP/GeoSiteデータベースが古くなっていることが原因です。本記事ではこの2種類の地理データベースの仕組み、手動・自動での更新方法、更新後もルールが反映されない場合の調査順序を整理します。

GeoIPとGeoSiteとは何か

Clash系の設定ファイルでは、次のようなルール記述がよく見られます。

rules:
  - GEOIP,CN,DIRECT
  - GEOSITE,google,Proxy
  - GEOSITE,cn,DIRECT
  - MATCH,Proxy

ここでの GEOIP,CN や GEOSITE,google は、コア自身が判断しているわけではなく、テーブル参照によって得られた結果です。参照先は事前にコンパイルされた2種類の地理データベースです。

  • GeoIPデータベース（一般的なファイル名は Country.mmdb や geoip.dat）：世界中のIPアドレス範囲を対応する国・地域コードに分類します。コアは接続先のIPを受け取るとまずこのテーブルを参照し、CN、US、HKといった帰属地を取得してから、ルールに照らして直接接続かプロキシ経由かを決定します。
  • GeoSiteデータベース（一般的なファイル名は geosite.dat や geosite.db）：よく使われるドメイン名やドメインサフィックスを事前定義されたグループに分類します。例えば cn、google、github、netflixなどで、該当グループに一致すると対応するポリシーが発動します。

これら2つのデータベースはコミュニティが管理する静的ファイルで、上流プロジェクト（Loyalsoldierのルールセットやv2flyのdomain-list-communityなど）に沿って定期的に再コンパイル・公開されており、コア自体のアップデートに合わせて自動更新されることも、サブスクリプションを切り替えたことで更新されることもありません。いわば「辞書」のようなもので、印刷された時点の情報でしか調べられないという性質があります。

データベースが古いとなぜ分流が「ずれる」のか

インターネット上のIPアドレス範囲の割り当てやドメインの帰属先は固定されたものではありません。クラウド事業者のIPプールは拡張や移転を繰り返し、CDNノードは地域間で切り替えられ、新規に立ち上がったドメインは短期間ではどのグループにも含まれていないことがあります。ローカルのデータベースが数ヶ月から1〜2年前のバージョンのままだと、次の2つの典型的な症状が現れます。

  • 直接接続すべきものがプロキシ経由になる：中国国内サイトが新しいIPアドレス範囲に切り替えたり新しいCDNを導入したりした場合、旧バージョンのGeoIPライブラリでは CNとして認識されず、ルール判定に失敗してデフォルトポリシー（通常はプロキシ）にフォールバックし、アクセスが明らかに遅くなったり、時々接続に失敗したりします。
  • プロキシ経由にすべきものが直接接続になる：海外サービスがドメインを変更したり新しいサブドメインを追加した場合、旧バージョンのGeoSiteグループに収録されていないため、対応するグループにマッチせず、最終的に MATCH,DIRECT のようなフォールバックルールに処理され、プロキシのないネットワーク環境に直接晒されてしまいます。

注意：ルールファイル自体には何の変更もなく、単に基盤となるクエリ用データベースが古くなっているだけなのに、「サブスクリプションに問題がある」や「ルールの記述ミス」と誤解されやすく、調査方向を誤ると大量の時間を浪費してしまいます。

まずは現在のデータベースのバージョンと更新日時を確認する

更新作業に着手する前に、問題が本当にデータベースにあるのかを確認しましょう。クライアントごとに確認方法は多少異なりますが、考え方は共通です。データベースファイルの最終更新日時を確認し、上流の公開履歴と比較します。

  1. クライアントの「コア/ルール」設定ページでは通常、GeoIP・GeoSiteファイルのローカルパスと最終更新タイムスタンプが確認できます。一部のクライアントではバージョン番号やコミットハッシュの先頭数文字が直接表示されます。
  2. クライアントのインターフェースにこの情報が表示されない場合は、設定ディレクトリに直接アクセスして Country.mmdb、geosite.dat ファイルの更新日を確認できます。Android版では一般的にアプリ専用ディレクトリの data または geo サブディレクトリにあります。
  3. 上流リポジトリの公開日（GeoIPライブラリとGeoSiteライブラリは通常週次または2週に1回更新されます）と照合し、ローカルファイルの日時が1ヶ月以上遅れていれば、手動更新が必要だとほぼ判断できます。

もう一つの直接的な確認方法として、疑わしい分流ミスの対象に対して、明確なドメインまたはIPルールを一時的に設定に追加し、意図したグループではなくフォールバックポリシーにヒットするかを観察する方法があります。個別ルールは機能するがGeoルールが機能しない場合、問題はデータベース自体にほぼ限定されます。

データベースを手動更新する手順

手動更新の基本的な考え方は、信頼できるルールセットのリポジトリから最新のコンパイル済みデータベースファイルをダウンロードし、クライアント設定ディレクトリ内の古いファイルを置き換え、コアを再起動または設定を再読み込みすることです。

  1. クライアントが使用しているコアのバージョンを確認する：Clash本家、Clash Meta、mihomoの3つはデータベースファイルの形式要件が完全に一致しているわけではありません。mihomoは一部バージョンでより細かい粒度のルールセット形式に対応しているため、置き換え前に現在のコアが読み込めるファイル形式（.mmdb / .dat / .db）を確認してください。
  2. 最新のデータベースファイルを取得する：対応する上流ルールセットプロジェクトの公開ページから最新バージョンをダウンロードします。ファイル名はクライアント設定内の geodata-url、geoip-url またはローカルパスと一致させ、ダウンロード後にファイル名が食い違ってクライアントが旧ファイルを読み込み続けることを防ぎます。
  3. ローカルファイルを置き換える：ダウンロードしたファイルをクライアント設定ディレクトリ内の元のファイルの位置に配置します。上書き前に旧ファイルをバックアップしておくと、新ファイル自体が破損していた場合にも復元できます。
  4. コアを再起動または設定を再読み込みする：多くのクライアントではファイル置き換え後にプロキシサービスを再起動しないとデータベースが再読み込みされません。サブスクリプションの更新やノードの切り替えだけではデータベースの再読み込みは通常発生しません。
  5. 反映を確認する：再起動後、以前誤判定されていたサイトにアクセスするか、クライアントの接続ログで該当リクエストがヒットしたルール名を確認し、想定するグループに落ちているかを確認します。
# mihomoコアのコマンドラインを例に、手動置き換え後に設定を再読み込みする典型的な操作
# 1. 実行中のサービスを停止する
systemctl stop mihomo
# 2. 新しいファイルで古いGeoIP / GeoSiteデータベースを上書きする
cp Country.mmdb /etc/mihomo/Country.mmdb
cp geosite.dat /etc/mihomo/geosite.dat
# 3. 再起動する
systemctl start mihomo

自動更新を設定して再度の期限切れを防ぐ

手動更新はその場の問題を解決しますが、時間が経てばデータベースは再び古くなります。より確実な方法は、設定ファイルにデータベースのリモートアドレスと更新周期を宣言し、クライアントの起動時や定期タスクで自動的に最新版を取得させることです。

この項目に対応するコアの例として、設定ファイルには次のような構造がよく見られます。

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://example.com/Country.mmdb"
  geosite: "https://example.com/geosite.dat"
  • geo-auto-update：コアがバックグラウンドで新バージョンのデータベースを自動チェック・ダウンロードすることを許可するかどうか。
  • geo-update-interval：自動チェックの間隔（単位は時間）。短すぎると不要なネットワークリクエストが増えます。通常24時間ごとであれば上流の公開ペースに十分追従できます。
  • geox-url：データベースのダウンロード元アドレスを指定します。デフォルトのソースがお使いのネットワーク環境でアクセスが遅い場合はミラーアドレスに置き換えられますが、ミラーの同期の即時性を確認しないと、場所を変えただけで結局古いデータを使い続けることになります。

すべてのクライアントのGUIがこれらの項目の設定画面を用意しているわけではありません。対応する切り替えスイッチが見当たらない場合は、「設定ファイルの編集」や「詳細設定」でテキスト形式として上記フィールドを直接追加し、保存後にサービスを再起動すれば反映されます。

更新後もルールが反映されない場合の調査方法

最新のデータベースをダウンロードしたことを確認済みで、置き換え後も問題が解決しない場合は、以下の順序で一つずつ調査すると、通常は具体的な原因を特定できます。

  1. ファイルが確実に置き換わっているかを確認する：ファイルの更新日時とサイズが変化しているかを確認します。一部のクライアントはデータベースを複数の場所（インストールディレクトリとユーザー設定ディレクトリの両方）にキャッシュしており、間違った場所を置き換えても意味がありません。
  2. コアが実際にファイルを再読み込みしたかを確認する：一部のクライアントの「再起動」ボタンはインターフェースのプロセスのみ再起動し、基盤となるコアサービスは再起動しないことがあります。システムレベルで対象のプロセスまたはサービスを完全に停止してから起動する必要があります。
  3. ルールの順序がより前段のルールに遮られていないかを確認する：Clashのルールは上から下へ順に照合されます。GEOSITE,cn,DIRECT より前に対象範囲が広すぎるルール（例えば範囲の広い DOMAIN-SUFFIX や IP-CIDR）が存在すると、対象リクエストが先にそちらにヒットしてしまい、Geoルールの段階まで到達しません。
  4. サブスクリプションがローカルのルールセット設定を上書きしていないかを確認する：「サブスクリプション変換」サービスで生成された設定を使用している場合、一部の変換ルールが生成時点で独自のGeoデータソースアドレスを書き込んでいることがあり、ローカルで手動置き換えしたファイルがそもそも参照されていない可能性があります。
  5. 接続ログで実際にマッチしたルール名を確認する：多くのクライアントはリアルタイムログや接続パネルを提供しており、各リクエストが具体的にどのルールにヒットしたかを確認できます。問題がデータベースにあるのかルールの順序にあるのかを判断する最も直接的な方法です。

おすすめ：調査の際はまず接続ログを開いて一件ずつ照合するほうが、ルールの書き方をいろいろ推測するよりも効率的です。「分流が正確でない」という問題の多くはログを見れば、どのルールにヒットしているか一目で分かります。

長期的なメンテナンス習慣を作る

Geoデータベースの期限切れは継続的な問題であり、一度修正すれば永久に解決するわけではありません。今後同じ問題に再び陥る確率を減らすために、次の習慣をつけることをおすすめします。

  • 自動更新フィールドを有効にした後も、しばらくおきに人力でデータベースの実際の更新日時を確認し、ネットワークの問題で自動更新タスクが静かに失敗していないかをチェックする。
  • サブスクリプションやルールセットのソースを切り替える際は、それに独自のGeoデータソースアドレスが内蔵されていないかを確認し、ローカルで手動管理している設定と衝突しないようにする。
  • ルールファイルに大きな変更を加える場合は、まずテスト環境や独立した設定グループで検証してから、日常使用のメイン設定に統合し、本番の分流が広範囲で異常になることを避ける。
  • 上流のルールセットプロジェクトの更新履歴に注目し、特に中国国内で頻繁に使われるサービスがIPアドレス範囲を大規模移転したり、ドメイン構造を調整した時期には、自動更新の周期を待つより手動でデータベースを一度更新するほうが確実である。
クライアントをダウンロード