Clash GeoIP・GeoSite データベース更新ガイド:配布元の選び方・手動置き換え・自動更新設定

GeoIP と GeoSite は分流ルールで何をしているのか

Clash の分流ルールでは GEOIP,CN,DIRECT や GEOSITE,google,PROXY といった記述をよく目にします。この2つのルールの背後にあるのは2種類のデータファイルです。GeoIP データベースは IP アドレス範囲を国・地域コードに対応させ、GeoSite データベースはドメイン名をあらかじめ定義されたグループ(google、github、netflix など)に分類します。ルールエンジンは通信をマッチングする際、ドメインや IP 範囲を1件ずつハードコードする必要がなく、データベース内のグループ名を参照するだけで数千・数万件のレコードを一括カバーできます。

この仕組みは「ルールのロジック」と「ルールのデータ」を分離しています。ロジックは rules フィールドに記述され、基本的に変更する必要はありません。データは独立したバイナリファイルに格納され、単独でダウンロード・更新できます。データベース自体には判定ロジックは含まれておらず、ドメインと IP をフォルダ分けして整理したインデックス表のようなものです。あるサイトが IP 範囲を変更したり、新しいドメインが追加されたりした場合でも、データベースが適切なタイミングで更新されていれば、ルールの判定結果も自動的に追随します。ユーザーが設定ファイル内のルール項目を手動で書き換える必要はありません。

逆に、データベースが長期間更新されないと、ルールの精度は徐々に低下していきます。新しく登録されたドメインが本来入るべきグループに分類されなかったり、ある CDN が新たに使い始めた IP 範囲が誤って海外グループと判定されたりすることもあります。これが、データベースのバージョンと更新頻度を単独で気にかける価値がある理由です。設定ファイルを書いたら終わり、というわけではありません。

主要なデータベース配布形式の比較

世の中に出回っているデータベースのファイル名や形式は統一されておらず混乱しやすいので、まずクライアントのコア別に整理して説明します。

Clash 無印版と Clash Meta(mihomo)の違い

初期の Clash 無印版コアが使用していたのは Country.mmdbで、これは MaxMind 形式の GeoIP データベースであり、IP から国コードへのマッピングのみを行い、GeoSite のドメイングループ機能は含まれていません。無印版コアの GEOSITE ルール対応も限定的です。一方、Clash Meta とその後継として開発が続く mihomo は、独自のデータ形式を採用しています。GeoIP 部分は geoip.dat または新しい geoip.metadb、GeoSite 部分は geosite.dat です。.metadb は mihomo チームが後に切り替えた独自形式で、サイズが小さくクエリも高速ですが、旧来の .dat 形式とは混用できません。

データの出典:V2Ray/Xray 系と MaxMind 系

geoip.dat と geosite.dat の命名や構造は元々 V2Ray/Xray エコシステムに由来し、後に Clash Meta がそのまま流用したため、両者のデータファイル形式は高い互換性を持ち、グループ名(cn、category-ads-all など)もほぼ揃っています。この種のデータベースは通常、コミュニティプロジェクトが定期的にビルドして公開しており、よく使われる配布リポジトリは IP 範囲やドメインリストの変化を継続的に追跡しています。MaxMind の GeoLite2-Country.mmdb はもう一つの系統で、データ構造はより従来型の IP 位置情報ライブラリに近く、主に .mmdb 形式のみに対応した旧コア向けです。

実際に選ぶ際に覚えておくべき原則は1つです。まず自分が使っているコアがどの系統(Clash 無印版、Clash Meta、mihomo)かを確認し、次にそのコアがどのデータファイル形式を認識するかを確認します。この2つが一致していないと、置き換えても機能せず、場合によってはルールエンジンがエラーを出して起動に失敗することもあります。

手動でファイルを置き換える完全な手順

手動更新は、設定ファイルを変更したくなく、とりあえず一回だけデータを更新したい場合に向いています。基本の流れは、新しいデータベースファイルをダウンロードし、クライアントが読み込めるディレクトリに置いて旧ファイルを上書きし、コアを再起動する、というものです。

1. クライアントのデータディレクトリを確認する

   GeoIP/GeoSite ファイルを保存するディレクトリはクライアントによって異なり、よくあるのは設定ファイルと同じ階層のディレクトリ、あるいはクライアントのインストールディレクトリ下の data、resources サブディレクトリです。まずクライアントの設定管理画面で現在有効な設定ファイルのパスを確認すれば、データベースファイルは通常同じディレクトリかその親ディレクトリにあります。

2. コアが対応するファイル形式を確認する

   クライアントのコアバージョン情報を開き、Clash 無印版、Clash Meta、mihomo のいずれかを確認します。比較的新しい mihomo はデフォルトで geoip.metadb に対応しており、古いバージョンや Clash Meta は geoip.dat と geosite.dat に対応しています。ダウンロード前にファイル名の拡張子を確認し、形式を間違えないようにしましょう。

3. 対応する配布元から最新ファイルをダウンロードする

   メンテナンスが活発なコミュニティ配布元を選び、自分のコアに合ったバージョンのファイルをダウンロードします。ダウンロード完了後はすぐに上書きせず、まず元のファイルがあるディレクトリでバックアップを取っておくと、置き換え後に問題が発生した際すぐに戻せます。

4. コアを停止してからファイルを置き換える

   データベースファイルは通常コア起動時にメモリへ読み込まれるため、動作中に直接ファイルを上書きしても即座に反映されない場合があり、一部のシステではファイルが使用中で置き換えに失敗することもあります。クライアント内でプロキシサービスを停止するか、クライアントを終了してからファイルを置き換えることをお勧めします。

5. コアを再起動してログを確認する

   置き換えが完了したらクライアントまたはプロキシサービスを再起動し、コアのログにデータベースの読み込み失敗や形式不一致などのエラーが出ていないか確認します。ログが正常でエラーがなければ新しいデータベースが有効になったことを意味し、帰属先が明確なドメインや IP を使って分流結果をテストし、再確認するとよいでしょう。

設定ファイルで定期自動更新を有効にする

手動置き換えは人手が必要なため、長期的には更新を忘れがちです。Clash Meta と mihomo は、設定ファイルにデータベースの取得元と更新周期を宣言できるようになっており、コアが自動的に定期取得を行うため人手の介入は不要です。中心となるフィールドは設定ファイル最上位の geox-url と更新周期関連の設定に集約されており、典型的な記述は次の通りです。

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

geox-url:
  geoip: "https://example.com/geoip.metadb"
  geosite: "https://example.com/geosite.dat"
  mmdb: "https://example.com/Country.mmdb"

各フィールドの役割は次の通りです。geodata-mode を有効にすると、GEOSITE ルールが実際にドメインのグループでマッチングされるようになり、コアに無視されなくなります。geo-auto-update は自動更新を有効にするかどうかを決めます。geo-update-interval は時間単位で更新間隔を設定し、例の 24 は1日1回チェックすることを意味します。geox-url 配下の3つのキーはそれぞれ GeoIP、GeoSite、MaxMind 形式データベースのダウンロード URL を指定し、コアはこのアドレスに対して周期的に取得を行います。コアのバージョンによってフィールド名への対応状況が微妙に異なるため、クライアントをアップグレードした際は現行バージョンの更新ログを確認し、フィールド名の変更がないかチェックすることをお勧めします。古いフィールドを使い続けると自動更新が黙って機能しなくなることがあります。

サブスクリプション自体が VPN プロバイダーから提供されている場合、その変換サービスが独自の geox-url をあらかじめ含んでいることがあり、この場合は自分で書いたフィールドがサブスクリプション内容によって上書きされる可能性があります。自動更新が機能しない場合は、まず最終的に有効になっている設定ファイル内でこれらのフィールドがサブスクリプション内容によって書き換えられていないか確認してください。

更新後によくある問題のトラブルシューティング

データベース更新後にルールの挙動が異常になる原因は、おおむね次のいくつかに集中しています。

• 形式の不一致:.dat 形式をダウンロードしたのに .metadb しか認識しない新しいコアに読み込ませてしまうと、コアは通常ログに解析失敗を出力し、ルールエンジンは「未マッチ」状態にフォールバックして、大量の通信がデフォルトのポリシーグループに落ちてしまいます。
• グループ名の不一致:異なる配布元は同じ種類のサイトに対してグループ名の付け方が異なる場合があり、たとえば netflix という名前のものもあれば、より細かいサブグループに分割されているものもあります。ルールに記述するグループ名は、データベースに実際収録されているグループ名と完全に一致させる必要があり、大文字小文字やスペルも確認しましょう。
• 自動更新先へアクセスできない:geox-url が指すアドレスへのアクセスが不安定であったり、プロキシ経由でしかアクセスできなかったりする一方で、更新処理はプロキシ経路が確立される前に発生するため、更新が常に失敗するという状況が起こります。この種のアドレスには、アクセス経路が単純で安定した配布元を選ぶことをお勧めします。
• キャッシュが更新されていない:一部のクライアントは GUI 上でルールに追加のキャッシュをかけている場合があり、データベースファイル自体は更新済みでも画面上のマッチング結果が変わらないことがあります。クライアントを一度再起動すれば通常は解決します。

トラブルシューティングは「ファイルは正しいディレクトリに置かれているか → 形式はコアと一致しているか → 設定フィールドは上書きされていないか → ネットワークが更新先にアクセスできるか」の順に一つずつ確認するのがおすすめです。データベース関連の分流異常の大半は、この手順の中で原因を特定できます。