ClashのGeoIP・GeoSiteデータベースを更新する方法｜geox-urlの設定とGEOSITEルールの書き方

まず使用中のコアを確認し、GeoIPとGeoSiteの違いを把握する

まず、クライアントの「バージョン情報」またはコア情報画面で、実行中のコアを確認してください。Clashはプロキシコアとそのエコシステムの総称として使われることがあり、GUIクライアントは設定管理やシステムプロキシの切り替え、コアの起動を担います。この記事のgeox-url、GEOSITE、自動更新の例はmihomo向けです。mihomoは、旧Clash Metaから名称が変更されたプロジェクトであり、すべての旧バージョンのClashコアにそのまま適用できるわけではありません。

更新するファイルを決める前に、2種類のデータベースの違いを確認しましょう。GeoIPはIPアドレス範囲を国や地域などのグループに分類し、GeoSiteはドメインをウェブサービスや用途別のグループに分類します。どちらもルール判定に使うデータであり、プロキシノードを提供するものではなく、サブスクリプションURLの代わりにもなりません。データベースを更新しても、期限切れのノードが再び接続できるようになるわけではありません。

データソースに含まれるグループを確認してから、グループ名を指定してください。cnはよく使われる例ですが、簡易版のデータパッケージでは同じカテゴリが含まれていないこともあります。GeoSiteのカテゴリ名は通常、小文字で指定します。属性付きのカテゴリは、データソースの説明に従ってください。ウェブサイト名からタグを推測し、読み込み失敗をネットワークの問題と決めつけないようにしましょう。

実際のデータディレクトリを見つけ、別のファイルを更新しないようにする

まず、実行中のコアが使用している作業ディレクトリを確認します。コマンドラインでは-dオプションで設定ファイルとデータのディレクトリを指定します。GUIクライアントには通常、専用のアプリデータディレクトリがあり、サービスとして実行している場合は別のユーザーやディレクトリを使うこともあります。インストーラーの保存先、ダウンロード先、現在有効な設定ディレクトリは、それぞれ異なる場合があります。

1. クライアントのディレクトリを開くメニューから、「設定ディレクトリ」「データディレクトリ」「アプリケーションフォルダを開く」などの項目を探してください。メニュー名はクライアントやバージョンによって異なるため、実際の画面で確認しましょう。
2. コアの起動ログやプロセスの引数を確認し、-dで指定されている場所を特定します。同じ名前のファイルが見つかっただけで、すぐに上書きしないでください。
3. そのディレクトリ内にあるgeosite.dat、geoip.dat、またはCountry.mmdbを探し、ファイルサイズ、更新日時、現在の設定を記録します。
4. サブスクリプションの元データと、実際に適用される設定を区別してください。クライアントが設定を統合した後は、実際に有効な項目がサブスクリプション編集画面の内容と異なる場合があります。

コマンドラインのコアを専用ディレクトリで実行する場合は、パスを明示できます。以下はLinuxまたはmacOSのターミナルを使う例で、現在のディレクトリにmihomo-data/config.yamlが用意されている前提です。1つ目のコマンドでバージョンを確認し、2つ目で設定を検証します。検証コマンドを実行しても、コアがプロキシサービスを継続して提供することはありません。

mihomo -v
mihomo -t -d "$PWD/mihomo-data" -f "$PWD/mihomo-data/config.yaml"

geox-urlと定期更新を設定する

更新用の項目はYAMLのトップレベルに置き、rulesやdnsと同じ階層にします。YAMLはインデントで階層を表す設定形式です。ここに示す項目をdnsやプロキシノードの下にインデントしないでください。以下は既存の設定に追加する断片であり、ノードやプロキシグループを含む完全な設定ファイルではありません。

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

geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

• geodata-mode: true：GEOIPの判定にDAT形式のGeoIPデータを使います。falseにすると通常はMMDB形式を使います。この設定はGeoSite全体の有効・無効を切り替えるものではありません。
• geo-auto-update: true：コアの地理データ定期更新を有効にします。
• geo-update-interval: 24：更新間隔を24時間に設定します。毎日決まった時刻に更新する設定ではありません。
• geox-url：データの種類ごとにダウンロード元を指定します。ダウンロード元を設定しただけで、すぐにダウンロードが完了するわけではありません。

実際に使用するモードに合わせてデータソースを設定してください。上の例では対応関係を示すためDATとMMDBのURLを併記していますが、DATモードで使う場合に毎回3種類すべてのファイルが必要という意味ではありません。mmdbは設定キーです。例のダウンロードURL末尾は小文字のcountry.mmdbですが、コアのローカルファイル名は一般にCountry.mmdbです。手動で置き換える際に取り違えないよう注意してください。

保存後、設定を再読み込みして読み込みログを確認します。クライアントに「Geoデータを更新」などの操作があれば、手動で更新を開始できます。そのような項目がない場合、再起動すれば既存のデータベースが必ず置き換わるとは限りません。自動更新はコアの仕組みに従って実行されます。すぐに置き換える必要がある場合は、次のセクションで説明するオフライン更新を利用できます。

まず、現在のネットワークからダウンロード先にアクセスできることを確認してください。GitHubのリリース添付ファイルではリダイレクトが発生する場合があるため、コマンドラインでダウンロードするときはリダイレクトを追跡します。クライアントでシステムプロキシを有効にしても、コア自身のダウンロードが同じ経路を通るとは限りません。タイムアウトした場合は、ログに記録されたドメイン、接続エラー、プロキシの選択状況を確認してから、信頼できるデータソースへの切り替えを検討してください。

geosite.datとgeoip.datを手動で置き換える

まず一時ファイルとしてダウンロードし、コアを停止してから置き換えます。コアの実行中にファイルを書き換えたり、読み込み中のファイルを更新したりしないでください。また、ウェブページの「名前を付けて保存」で取得したファイルを、データベースの名前に変えるだけでは使えません。ダウンロードしたものがログインページやエラーページの場合、拡張子が.datでもデータとしては使用できません。

前のセクションと同じ専用ディレクトリを使い、ここではDATモードの例を紹介します。まずファイルをダウンロードします。-fはHTTPエラーを失敗として扱い、-Lはリダイレクトを追跡するオプションです。2つのコマンドがどちらも成功したことを確認してから、次に進んでください。ターミナルのエラーを無視しないでください。

curl -fL --retry 2 \
  "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" \
  -o "./mihomo-data/geoip.dat.new"

curl -fL --retry 2 \
  "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" \
  -o "./mihomo-data/geosite.dat.new"

続いてGUIクライアントを終了するか、対象のコアサービスを停止し、自動で再起動しないことを確認してください。以下のコマンドは、既存のデータファイルが2つともあり、バックアップファイル名も未使用である前提です。初回インストール時など、元ファイルがない場合は該当するバックアップコマンドを省略してください。更新のたびに別のバックアップを残し、最後に使えるコピーを上書きしないようにしましょう。

cp "./mihomo-data/geoip.dat" "./mihomo-data/geoip.dat.before-update"
cp "./mihomo-data/geosite.dat" "./mihomo-data/geosite.dat.before-update"

mv "./mihomo-data/geoip.dat.new" "./mihomo-data/geoip.dat"
mv "./mihomo-data/geosite.dat.new" "./mihomo-data/geosite.dat"

mihomo -t -d "$PWD/mihomo-data" -f "$PWD/mihomo-data/config.yaml"

検証に問題がなければコアを起動し、初回読み込み時と実際のリクエスト時のログを確認します。設定検証で見つけられるエラーには限りがあり、実行時の確認の代わりにはなりません。カテゴリが存在しない、ファイルを読み込めない、解析に失敗するといったエラーが表示されたら、まずコアを停止してバックアップを復元し、データソースとファイル形式を確認してください。

MMDBモードでは、対応する形式のファイルをダウンロードし、実際のデータディレクトリにあるCountry.mmdbを置き換えます。geoip.datの名前をCountry.mmdbに変えてはいけません。ファイル内部の形式が異なります。Linuxではファイル名の大文字・小文字が区別されます。置き換え後は、実行ユーザーに読み取り権限があることも確認してください。

GEOSITEルールとGEOIPルールを書く

まず、クライアントがルールモードになっていることを確認してから、ルールの順序を調整します。ルールモードでは上から順に照合し、通常は一致した時点で後続のルールを確認しません。グローバルモードでは、このリストに従ってリクエストごとに接続先を選ぶことはありません。TUNモードは通信を取り込む機能であり、ルールモードの代わりにはなりません。

以下の例では、既存の設定に「プロキシ選択」という名前のプロキシグループが定義されているものとします。DIRECTは組み込みの直接接続先なので、追加で作成する必要はありません。「プロキシ選択」は実際のグループ名と完全に一致させてください。例のドメインは構文を示すためのものです。実際の設定では用途に応じて追加・削除してください。

mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,プロキシ選択
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,プロキシ選択

例外ルールを先に、広い範囲を対象にするルールを後に置く

個別に処理するドメインを、グループ判定の前に記述します。1つ目のDOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。2つ目はGeoSiteのcnカテゴリに基づいてドメインを処理し、3つ目は中国本土のIPアドレス範囲を対象にします。最後のMATCHで、いずれにも一致しなかったリクエストを処理します。MATCHを先頭に置くと、後続の地理データルールが機能しなくなるため注意してください。

no-resolveを使う場合の考え方

no-resolveは、「このIPルールのためにドメインを積極的に名前解決しない」という意味です。接続先がもともとIPアドレスなら、GEOIPで判定できます。一方、リクエストにドメイン名しかなく、利用可能な接続先IPがない場合、このルールは判定のために追加の名前解決を行わず、MATCHまで進むことがあります。不要なDNS問い合わせを減らす効果はありますが、中国本土のドメインすべてがGEOIPに一致するとは限りません。

ドメインの分類を、サーバーの所在地を示す情報として扱わないでください。1つのドメインが世界各地のコンテンツ配信ネットワークを使うこともあれば、同じサービスに複数のドメインカテゴリが割り当てられることもあります。GeoSiteの分類とGeoIPによる地域判定は、別のことを調べる仕組みです。サービス単位で分類する場合はドメインルール、接続先のアドレス範囲で処理する場合はIPルールを優先してください。

更新後はファイルの日時だけでなく、ルールが適用されるか確認する

まず、クライアントの接続画面で新しいリクエストのルールと接続先を確認します。ファイルの更新日時が新しくなっていても、書き込みがあったことしか分かりません。実行中のコアが再読み込みしたことや、テストリクエストがそのコアを経由したことまでは保証されません。ブラウザーが古い接続を再利用している場合は、対象のタブや接続を閉じてから、新しいリクエストを送ってください。

1. 現在有効な設定が、変更した設定であることを確認し、実行中の設定でgeodata-modeとルールの順序をチェックします。
2. データ読み込みエラーがログに出ていないか確認します。特に、ファイルが見つからない、権限がない、カテゴリが存在しないといったメッセージに注意してください。
3. 対象のカテゴリに含まれることが分かっているドメインを選び、接続の詳細にGEOSITE、GEOIP、またはそれより前にあるドメインルールのどれが表示されるか確認します。
4. 接続先が想定したDIRECTまたはプロキシグループになっていることを確認し、次にグループで現在選択されているノードを確認します。
5. 接続先IPだけを使った通信をテストする場合は、GEOIPを個別に検証してください。ドメインへのアクセス1回だけで、2種類のデータベースがどちらも有効だと判断しないでください。

ターミナルでテストする場合は、ローカルのプロキシポートを明示してください。以下は、現在の設定でmixed-portが7890である例です。実際のポートが異なる場合は、クライアントに表示されている値に置き換えてください。このコマンドで確認できるのはリクエストがプロキシ経路に入ったことまでです。どの地理カテゴリに一致したかは、接続画面もあわせて確認してください。

curl -I --proxy http://127.0.0.1:7890 https://example.com

エラーの種類に応じて更新失敗の原因を調べる

Geoデータとrule-providersを区別する

まず、ルールにGEOSITEとRULE-SETのどちらが書かれているか確認してください。rule-providersは独立したルールセットを読み込むためのルールプロバイダーです。専用のダウンロードURL、形式、更新間隔があります。geox-urlを設定しても、すべてのルールプロバイダーが同時に更新されるわけではありません。反対に、特定のルールプロバイダーを更新しても、geosite.datが置き換わるわけではありません。

問題が起きたときに戻せるよう、変更を最小限にする

一度に変更する内容は1種類に絞りましょう。まずデータベースを更新して既存のルールを検証し、その後で新しいカテゴリを追加するか、ルールの順序を調整します。問題が起きた場合、データファイルと設定を戻す方が、クライアントの再インストールやDNSの変更、TUNの有効化を同時に行うより原因を特定しやすくなります。設定のマージや通信の取り込みについて詳しく確認する場合は使い方ガイドを、接続の問題はトラブルシューティングを参照してください。