GeoIP・GeoSite データベース更新ガイド:振り分けルールが狂う原因と対処
GeoIP・GeoSiteデータベースがルール判定で果たす役割を解説。手動置き換えと設定内自動更新の2手法、および古いデータベースが引き起こす振り分けミスの検証方法を紹介。
Clash や mihomo コアの振り分けルールは、手書きのドメインやIPレンジだけに依存しているわけではありません。よく使われるルールの多くは、実際には2種類のオフラインデータベースを参照しています。GeoIP と GeoSite です。これらは大量のIPレンジやドメインを分類してまとめており、ルールファイルには GEOIP,CN という一行を書くか、ルールセットを参照するだけで、何千何万という実際のアドレスをカバーできます。これは設定をシンプルにする一方、見落としやすい落とし穴も生みます――データベース自体には有効期限があり、古くなると本来正しいはずのルールが静かに狂っていくのです。
GeoIP と GeoSite が実際に保持している情報
これら2種類のデータベースは同じ問題を異なる次元から解決しています。一方はIP単位、もう一方はドメイン単位で分類します。この違いを理解することが、振り分け異常を調査する前提になります。
| 項目 | GeoIP | GeoSite |
|---|---|---|
| 格納内容 | IPアドレス帯と国・地域コードの対応表 | ドメインと用途分類タグの対応表 |
| 代表的なファイル | Country.mmdb / geoip.metadb | geosite.dat / GeoSite.dat |
| 典型的なルール例 | GEOIP,CN,DIRECT | RULE-SET,geosite-google,PROXY |
| 更新が必要になる要因 | IPレンジの再割り当て、クラウド事業者のデータセンター移転 | 新規ドメインの開設、CDNドメインの変更 |
mihomo コアは起動時にこれら2種類のデータベースをメモリ上に読み込み、以後は接続ごとにルールを判定する際、必ずこのデータベースを参照します――あるIPがどの国に属するか、あるドメインがどのカテゴリに分類されるかを調べるのです。データベースに記載がない内容は当然対応するルールに一致せず、そのまま次のルールへ進んでいき、多くの場合はルールリスト末尾の MATCH によるフォールバック戦略に落ち着きます。これは期待していた出口とは一致しないことがよくあります。
データベースが古いと現れる具体的な症状
データベースの老朽化はエラーを出しませんし、画面に「更新してください」と表示されることもありません。これは静かなズレであり、振り分け結果の異常から逆算して初めて気づくものです。よく見られる症状をいくつか挙げます。
- 新規サービスが誤って国内アドレスと判定される:クラウド事業者は新たに取得したIPレンジを特定の地域に割り当てることがあります。GeoIP データベースがこの割り当てを反映していない場合、新しいサービスへの接続が
GEOIP,CNルールによって誤って国内IPと判定され、直接接続に回されてしまい、接続タイムアウトやアクセス失敗につながります。 - ルールセットの記述は正しいのに一致しない:あるカテゴリ(例:動画配信やSNSアプリ分類)のGeoSiteルールセットを参照している場合、そのカテゴリに新規ドメインが最近追加されたのにデータベースが未更新だと、その新規ドメインはルールセットをすり抜けてデフォルトの戦略に落ちます。結果として「同じアプリなのに一部機能はプロキシ経由、一部は直接接続」という現象が起きます。
- 国内サイトが不定期にプロキシ経由になる:逆に、あるIPレンジがクラウド事業者に返却または海外の事業者へ譲渡された場合、古いデータベースは依然国内扱いのままなので、本来直接接続すべきサイトが誤ってプロキシ出口に送られ、速度が明らかに低下します。
- レイテンシテストは正常だが実際のアクセスは異常:ノードの遅延測定は固定の測定用アドレスを使うため、完全なドメイン/IP振り分け判定を経由しません。そのためデータベースの老朽化による問題は測定段階では全く見えず、実際に業務ドメインへアクセスした時にだけ表面化します。
最近ルールやサブスクリプションを変更していないのに、一部のサイトで急に振り分けが異常になった場合、まずGeoIP/GeoSiteデータベースのバージョンを疑ってください。慌ててルールを書き直す前に――多くの場合ルール自体に問題はありません。
データベースファイルを手動で置き換える
手動置き換えは最も直接的で制御しやすい方法で、問題調査中の確認や、自動更新機構を信用しきれない場合に向いています。手順は3つだけです:コアのデータディレクトリを見つける、最新のデータベースファイルをダウンロードする、コアを再起動して再読み込みさせる。
- データディレクトリの位置を確認する:mihomo コアはデフォルトで作業ディレクトリ内の
Country.mmdbとgeosite.dat(または対応する.metadb形式)を探します。デスクトップ版では通常設定ディレクトリと同階層にあり、iOS クライアントでは通常アプリ内のルール/データ管理画面に個別に一覧表示されるため、ファイルシステムのパスを手動で特定する必要はありません。 - 最新データベースを取得する:データベースは mihomo 関連のオープンソースプロジェクトのルールセットリポジトリで継続的にメンテナンスされ配信されています。配信サイクルは通常数週間に一度で、IPレンジの大規模な調整や人気ドメインの移転があった場合には、それに対応するパッチ版が出ることもあります。
- 置き換えて再起動する:新しいファイルで古いファイルを上書きした後は、必ずコアを完全に再起動してください(設定のリロードだけではデータベースファイルは再読み込みされないことが多いです)。そうしないとメモリ上には旧バージョンの対応表が残り、置き換え自体が反映されません。
クライアントに「GeoIP/GeoSite を更新」というGUIボタンが用意されている場合は、そちらを優先的に使ってください。ファイルの検証と再起動処理を自動で行ってくれるため、ファイルシステムを手動で操作するより間違いが起きにくくなります。
設定内で自動更新を行う2つの方法
手動置き換えはあくまで後手の対応です。より推奨されるのは、設定内で自動更新を有効にし、コアに定期的な自己チェックをさせることです。mihomo にはそれぞれ独立して設定できる2層の更新機構が用意されています。
第1層:コアレベルの GeoIP/GeoSite 自動更新
この層が制御するのはコアに内蔵された地理データベース自体で、設定ファイルのトップレベルで設定します。
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://example-mirror.invalid/country.mmdb"
geosite: "https://example-mirror.invalid/geosite.dat"geo-update-interval の単位は時間で、コアがどのくらいの頻度でリモートに新しいバージョンがないか確認するかを決めます。geox-url は自前でホストしたミラーやサードパーティのミラーアドレスを指定できるため、ダウンロードの高速化やアクセス不安定の回避に使えます。有効にすれば人手を介さず、コアがバックグラウンドで静かに更新を完了します。
第2層:ルールセット(rule-providers)の個別更新
振り分けルールがコア内蔵のGeoSite分類ではなく外部のルールセットを利用している場合、更新周期は各 rule-provider ごとに個別に宣言する必要があります。
rule-providers:
reject-list:
type: http
behavior: domain
url: "https://example-mirror.invalid/reject.txt"
path: ./rules/reject.yaml
interval: 86400interval の単位は秒で、86400 は1日1回に相当します。ルールセットとコア内蔵のGeoIP/GeoSiteは独立した2つの更新経路であり、一方だけを有効にしても他方はカバーされません。これは「データベースを更新したのにルールがまだ不正確」というよくある原因の一つです。
自動更新はクライアントがバックグラウンドで動作し続けるか、計画的に起動されることに依存します。長期間クライアントを起動しないデバイスでは、手動更新の入口を使って定期的に確認することをおすすめします。
更新後の反映確認方法
ファイルを置き換えたり設定を変更したりした後は、感覚で「これで大丈夫だろう」と判断せず、再現可能な検証手順を実行してください。
- 起動ログを確認する:コアの再起動時にはデータベースの読み込み情報(ファイルパスやレコード件数を含む)が出力されます。ログにダウンロード失敗やファイル検証異常の表示がある場合、更新は実際には反映されておらず、ルールは依然旧データを使っています。
- 既知の境界事例で確認する:最近所属変更があったことが確認できているドメインまたはIPを選び、更新前後でそれぞれ振り分け結果をテストしてください。出口戦略が期待通り変化していれば、新しいデータベースが実際に読み込まれ判定に使われたことを意味します。
- ルールセットの項目数を確認する:一部のクライアントのルール管理画面では、各ルールセットが現在保持しているドメインまたはIPの件数が表示されます。更新前後で件数が明らかに変化していれば、データベースが実際に更新された直接的な証拠になります。
- 接続キャッシュをクリアして再テストする:一部のコアは既に確立した接続の判定結果を短時間キャッシュします。検証前に一度切断・再接続するかクライアントを再起動し、古いキャッシュ結果に判断を惑わされないようにしてください。
検証工程は手間に見えますが、「更新したら終わり」とするより、同じ問題を何度も調査し直す手間を避けられます。データベース関連の振り分け異常はしばしば見えにくく、しかも遅れて発生するため、あらかじめ検証の習慣を作っておくことで、後々のログ調査にかかる時間を大幅に節約できます。
持続可能な更新サイクルを設計する
ほとんどの利用シーンでは、コアレベルの自動更新を有効にし、12~24時間のチェック間隔を設定するだけで十分です。分単位のリアルタイム同期を追求する必要はなく、GeoIP・GeoSite データベースの上流の配信サイクル自体もそのような頻度をサポートしていません。同じ種類のサービスで振り分け問題が繰り返し発生している場合は、更新間隔を無限に短縮するよりも、そのカテゴリに対応するルールセットの提供元が今もメンテナンスされているかを個別に確認する方が有益です。データベースの更新は振り分け精度を保つための一要素に過ぎず、定期的な運用ログの確認とルール判定結果への注意を組み合わせてこそ、偶発的な振り分けのズレを最小限に抑えられます。