GeoIP・GeoSiteデータベースが古くなったら:更新方法とルールマッチングの仕組み

GeoIP・GeoSiteデータベースとは何か

典型的なClashやmihomoの設定ファイルを開くと、ルール部分に GEOIP,CN,DIRECT や GEOSITE,netflix,Proxy といった記述がよく見られます。この2つのルールが依拠しているのが、GeoIPデータベースとGeoSiteデータベースです。これらは設定ファイルの一部ではなく、個別にダウンロード・更新が必要な独立したバイナリリソースファイルで、一般的に geoip.dat(または geoip.metadb)と geosite.dat という名前で配布されます。mihomoコアでは後者が Country.mmdb のようなMaxMindデータベース形式で扱われることも多いです。

GeoIPデータベースは「どのIPアドレス帯がどの国・地域に属するか」という対応関係を記録したもので、たとえば特定のIPv4/IPv6アドレス帯には CN(中国本土)、US(アメリカ)、JP(日本)といった分類が付与されます。GeoSiteデータベースは「ドメインやドメイン接尾辞がどのカテゴリに属するか」を記録するもので、たとえば geolocation-cn というカテゴリには中国本土でよく使われるサイトのドメインルールが多数登録されており、netflix、google、telegram といったカテゴリは特定サービスのドメイン群に対応しています。この2つが組み合わさることで、ルールベースのプロキシ設定における最も基本的な判定材料が構成されます。クライアントは接続要求を受け取ると、まず対象がドメインかIPかを判別し、対応するデータベースを参照してどのカテゴリに属するかを確認し、最後に設定ルールに従って直接接続・プロキシ経由・拒否のいずれかを決定します。

ルールマッチングはこの2つのデータベースをどう使っているのか

マッチングの流れを理解しておくと、データベースが古くなったときにどの段階で問題が起きているのか判断しやすくなります。よく使われるルールセットを例に見てみましょう。

rules:
  - GEOSITE,geolocation-cn,DIRECT
  - GEOSITE,netflix,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

クライアントが特定のドメインへアクセスしようとすると、内部コアはまずドメインルールでのマッチングを試みます。GeoSiteデータベースの geolocation-cn カテゴリに該当ドメイン(またはその親ドメイン、ワイルドカード接尾辞)が含まれているかを確認し、該当すれば直接接続。該当しなければ次に netflix カテゴリと照合し、該当すれば Proxy グループ経由になります。ドメインルールがどれもマッチしない場合、コアはまずDNS解決でIPアドレスを取得し、GeoIPデータベースでそのIPがどの国に属するかを調べます。CN に該当すれば直接接続、そうでなければ最終的な MATCH ルールでプロキシ経由になります。

この流れからわかるのは、GeoSiteはドメイン軸での分類を、GeoIPはIP軸での分類を担っており、両者は代替関係ではなく補完関係にあるということです。「設定にはプロキシ経由のルールを書いたはずなのに、実際にはあるサイトが直接接続になっている」あるいはその逆のケースに遭遇するユーザーは多いですが、原因はルールの書き方が間違っているというより、そのドメインやIP帯の最新情報がデータベースに反映されていないケースがほとんどです。つまり、サービス側のインフラ変更にデータベースの更新が追いついていないのです。

補足GeoIP/GeoSiteデータベースはコミュニティによって継続的にメンテナンスされているオープンソースのルールセットで、更新頻度は日次から週次まで、選択したルールセットの配信リポジトリによって異なります。クライアント本体のバージョン更新周期とは直接関係ありません。

データベースが古くなると起きる典型的な症状

インターネットサービス各社は使用するIP帯やドメイン(特にCDNノードやクラウドサービスの出口IP)を頻繁に変更・拡張しており、GeoIP/GeoSiteデータベースは人手または自動スクリプトによる定期的な収集・検証・パッケージングを経て公開されるため、両者の間には必然的にタイムラグが生じます。データベースが古くなりすぎると、次のような症状が現れやすくなります。

直接接続でよいサイトがプロキシ経由になる:中国本土でよく使われるあるサイトが新しいサーバーIP群に切り替えたのに、古いデータベースではそのIP帯が海外扱いまたは未分類のままになっており、本来 DIRECT になるべき通信が最終ルールでプロキシグループに送られてしまい、不要な遅延が生じます。
プロキシ経由が必要なサービスが直接接続になる:逆に、あるストリーミングサービスやSNSがドメイン構成を変更したり新しいサブドメインを追加した場合、古いGeoSite分類にはそれらの新しいドメインが登録されていないため、対応するルールにマッチせずデフォルトの直接接続に落ち、アクセス失敗や地域制限のエラーが表示されます。
振り分けルール全体の精度が低下する:時間が経つにつれ、正確なルールにマッチしない接続が増え、最終的な MATCH ルールに頼る割合が高まります。ルールセット自体が形骸化し、プロキシグループの負荷や遅延も悪化していきます。
LANや内部サービスで異常が出る:プライベートアドレス帯のカスタムルールを設定していても、古いバージョンのGeoIPデータとの照合に依存している場合、内部サービスの判定にズレが生じることがあります。特にTUNモードでグローバルにトラフィックを取り込んでいる構成では、この問題が表面化しやすくなります。

これらの症状は単独で見ると「サブスクリプションのノード品質が悪い」「クライアントの不具合」と誤解されやすいですが、「以前は正常だったのに最近になって遅くなった、または不正確になった」という時系列が伴う場合は、まずデータベースのバージョンを疑うべきです。

3つの更新方法を比較する

現在主流のClass / Clash Meta(mihomo)クライアントがサポートしている更新方法は大きく3種類に分けられ、それぞれ適した場面が異なります。

方法1:クライアント内蔵の更新ボタン

多くのGUIクライアント(Clash Verge Rev、FlClashなど)は、設定画面に「GeoIP/GeoSiteデータベースを更新」または「コアリソースを更新」といったボタンを用意しており、クリックすると内蔵のデフォルト更新元から最新のパッケージを取得してローカルキャッシュを上書きします。これが最も手軽な方法で、ファイル構成を理解する必要がなく、ほとんどの一般ユーザーに適しています。欠点は、更新元が通常ソフト開発者が選定したリポジトリのミラーに固定されている点で、そのミラーへのアクセスが特定のネットワーク環境で不安定な場合、更新が失敗したり遅くなったりすることがあり、その際は手動での対応が必要になります。

方法2:手動でファイルをダウンロードして置き換える

コマンドラインでの運用やGUIボタンを持たない構成では、ルールセットの配信リポジトリから対応する geoip.dat、geosite.dat(あるいはmihomo向けの .metadb/.mmdb ファイル)を直接ダウンロードし、クライアントの設定ディレクトリにある同名の古いファイルを置き換えれば、コアを再起動するか設定を再読み込みすることで反映されます。この方法は制御性が高く、特定バージョンのルールセットを厳密に選べる点がメリットです。注意点として、ファイル名と配置先パスはクライアントが期待するものと完全に一致させる必要があり、ディレクトリを誤ると更新後も古いキャッシュを読み込んでしまいます。

方法3:設定ファイルの項目で更新元を指定する

mihomoコアは、設定ファイル内の専用フィールドで地理データベースのダウンロード元と自動更新ポリシーを指定できます。よく使われる項目は以下の通りです。

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://your-trusted-mirror-address/geoip.dat"
  geosite: "https://your-trusted-mirror-address/geosite.dat"

geo-auto-update を有効にすると、コアは geo-update-interval(単位:時間)で設定した周期で自動的に新バージョンを確認・ダウンロードします。geox-url を使えばデフォルトの更新元を任意のミラーアドレスに置き換えられるため、自前のミラーを使いたい場合やアクセス速度に特別な要件がある場合に適しています。この方法が最も柔軟ですが、設定項目の意味を正確に理解している必要もあり、フィールド名や書式を誤るとコア起動時にエラーになるため、変更前に元の設定をバックアップすることをおすすめします。

更新方法	操作難易度	向いているユーザー	制御の柔軟性
クライアント内蔵ボタン	低い	一般ユーザー	低い
手動でファイルを置き換える	中程度	ディレクトリ構成に慣れたユーザー	中程度
設定項目で更新元を指定する	高い	独自設定を組む長期運用者	高い

更新後に反映されているか確認する方法

更新操作が完了しても、必ずしもルールが即座に反映されているとは限りません。次の順序で簡単に確認することをおすすめします。

クライアントのログパネルまたは実行ログを確認し、「geoip database loaded」「geosite updated」のような表示があるか(サイレントに失敗していないか)を確認する。
最近IPやドメインが変わったことがわかっているサイトをテスト対象に選び、ブラウザのDNSキャッシュをクリアしてから再アクセスし、実際にどのプロキシグループ経由になっているかを確認する(多くのクライアントの接続パネルでは、各接続がヒットしたルール名がリアルタイムで表示されます)。
クライアントにルールテストや「ルール検索」機能があれば、ドメイン/IPを直接入力してマッチ結果を確認するほうが、Webページへのアクセスを繰り返して試すより手っ取り早いです。
OSやアプリ側のDNSキャッシュ・接続キャッシュもクリアされているか確認し、古い解決結果がデータベース更新の効果を隠してしまわないようにしてください。

確認してもルールが依然として不正確な場合、多くはデータベース自体の更新失敗ではなく、設定ファイル内のルールセットのバージョン番号やURLが古いアドレスを指していることが原因です。この場合、更新ボタンを何度も押すより、geox-url やクライアント設定のミラーアドレスが正しいかをまず確認するほうが効果的です。

よくある質問とトラブルシューティング

更新後にルールが「余計におかしくなった」場合はどうすればよいかルールセットの配信元によって、カテゴリ名の付け方や収録範囲に差異があります。設定内で出自の異なる2つのルールセットファイルを混在させると、同じカテゴリ名でも意味が一致しないケースが起こり得ます。まず rule-providers や geox-url で参照しているリポジトリの出自が統一されているかを確認し、新旧バージョンの混在を避けてください。

もう一つ見落としやすいポイントは、一部のクライアントがデータベースファイルに対してローカルキャッシュの検証を行っている点です。ファイルを置き換えてもキャッシュディレクトリ内の古いインデックスをクリアしていない場合、再起動後も古いデータを読み込んでしまうことがあります。「ファイルは確かに置き換えたのに動作が変わらない」という場合は、設定を再読み込みするだけでなくクライアントのプロセスを完全に終了させてから再起動し、コアにデータベースインデックスを再構築させてみてください。

長期的な運用のコツは、「地理データベースの更新」を「サブスクリプションリンクの更新」と同じくらい重要な日常メンテナンスとして扱うことです。サブスクリプションはどのノードが使えるかを決め、データベースはトラフィックがそのノード経由になるべきかを決めます。どちらか一方でも更新が滞れば、振り分け全体の精度が落ちてしまいます。ほとんどのユーザーにとっては、クライアント設定の自動更新をオンにし、時々更新ログを確認する程度で十分に対応できます。独自設定を組んでいる場合や更新元に特別な要件がある場合にのみ、設定項目レベルでの手動管理が必要になります。