GeoIP・GeoSiteデータベースの更新方法｜手動差し替え・自動更新・ルール設定 | Clash チュートリアル

まず整理：IPアドレスの位置情報データ、ドメイン分類データ、サブスクリプションの違い

プロキシノードのサブスクリプション更新に成功しても、ルーティング用データベースまで更新されたとは限りません。サブスクリプションには通常、ノード、プロキシグループ、ルールが含まれます。一方、GeoIPとGeoSiteは、コアが読み込むローカルデータファイルです。「特定のドメインが突然デフォルトルールに回る」ときは、サブスクリプション更新を繰り返すのではなく、ルールの順序、分類の有無、データベースの読み込み状況を個別に確認しましょう。

この記事ではmihomoコアを対象に説明します。オリジナルのClash、一部の旧Premium版、現在のmihomoでは、対応する設定項目が異なります。Clashという名前のすべてのアプリに、以下の設定をそのまま適用できるわけではありません。まずクライアントのコア情報や起動ログで、実際に使われているコアを確認してください。コマンドラインではmihomo -vを実行するとバージョンを確認できます。

ファイル	格納データ	主な用途
`Country.mmdb`	IPアドレスと国・地域の対応情報	`geodata-mode: false`の場合のGeoIP検索
`geoip.dat`	タグ別に整理されたIPアドレス範囲	`geodata-mode: true`の場合のGeoIP検索
`GeoSite.dat`	タグ別に整理されたドメイン	`GEOSITE`ルールなどのドメインマッチング

データの入手先とコアの作業ディレクトリを確認する

分類タグとセットでデータソースを選ぶ

mihomoでよく使われるデータソースには、MetaCubeXのmeta-rules-datプロジェクトがあります。ドメイン分類にはdomain-list-communityやその派生ビルドが、IP分類には複数のGeoIPビルドプロジェクトが利用されています。大切なのはダウンロード速度だけで選ぶことではなく、ファイル形式、収録タグ、メンテナーのリリースノートを確認することです。

ルールにGEOSITE,cn,DIRECTと書く場合、ドメインデータにcn分類が含まれている必要があります。
サービス名をルールに指定しても、すべてのデータソースに同じ名前の分類があるとは限りません。データベースを切り替えたら、設定を再テストしてください。
プレーンテキストのドメイン一覧、ルールセットのYAML、ダウンロードに失敗して取得したHTMLページをGeoSite.datとして保存しないでください。
データソースをそろえると分類の差異を抑えられますが、更新内容の確認は必要です。データ更新によってマッチ結果が変わることがあります。

インストール先ではなく、コアのデータディレクトリを探す

GUIクライアントでは、アプリのインストール先、設定ディレクトリ、コアのデータディレクトリがそれぞれ異なる場合があります。Windowsではコアがサービスとして起動し、現在のユーザーが手動で実行したときとは別のディレクトリを参照することもあります。起動ログで設定ファイルやデータベースの読み込み先、ダウンロード先を確認してください。クライアントに「設定フォルダーを開く」機能があっても、その中のファイルを実際にコアが使用しているか、さらに確認しましょう。

コマンドラインで運用する場合は、-dで作業ディレクトリを明示できます。次のコマンドでは、現在のユーザーの.config/mihomoをデータディレクトリに指定し、その中の設定ファイルを読み込みます。ディレクトリはあらかじめ作成し、使用可能なconfig.yamlを配置してください。

mihomo -d "$HOME/.config/mihomo" \
  -f "$HOME/.config/mihomo/config.yaml"

この例はUnix系シェル向けで、すべてのクライアントで使われる既定のパスではありません。Linuxではファイル名の大文字・小文字が区別されます。配布ファイルがgeosite.datという名前でも、保存時はコアが想定するGeoSite.datにしてください。Country.mmdbも同様に確認しましょう。ディレクトリを間違えたまま何度ファイルを置き換えても、コアが読み込まないファイルを更新するだけです。

手動で差し替える：バックアップ、テスト、再起動の順に

手動更新は、オフライン端末、自動ダウンロードの失敗、データのバージョン固定、データソース切り替え直後などに適しています。クライアントがデータベースをダウンロードしている間に、ファイルを上書きしないでください。先にクライアントを終了するか対象サービスを停止し、コアのプロセスが終了したことを確認します。

現在のモードを確認する。最終的に適用されている設定のgeodata-modeを確認します。値がfalseならGeoIPにはMMDBを、trueならDATを使います。GeoSiteは引き続きドメインデータベースを個別に使用します。
戻せるファイルを残す。置き換える旧ファイルをバックアップし、入手先とダウンロード日を記録します。使用可能な唯一のファイルを直接削除しないでください。
一時ファイルにダウンロードする。HTTPリクエストが成功したことを確認してから、コアの作業ディレクトリに配置します。ダウンロード途中のファイルに正式なファイル名を付けないでください。
設定全体をテストする。本番環境と同じコア、設定ファイル、データディレクトリを使ってテストしてください。
コアを再起動する。画面の更新や接続ページの再表示だけでは、データベースが再読み込みされない場合があります。再起動後、起動ログと実際にマッチしたルールを確認してください。

以下では、データディレクトリを確認済みでコアを停止した状態を前提に、BashでGeoSite.datを更新する例を示します。ほかのデータベースは、実際のモードに応じて個別に扱ってください。拡張子だけを変えるのは避けましょう。

cd "$HOME/.config/mihomo" || exit 1

if [ -f GeoSite.dat ]; then
  cp -p GeoSite.dat GeoSite.dat.bak || exit 1
fi

curl --fail --location --retry 2 \
  --output GeoSite.dat.new \
  "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" \
  && mv GeoSite.dat.new GeoSite.dat

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

curl --failを使うと、一般的なHTTPエラーを失敗として扱えますが、ファイルの内容が正しいことまでは保証されません。形式や分類の検証は、最終的にコアで行います。テストに失敗したら、まずエラーを記録してバックアップを戻してください。旧ファイルが残っている場合は、cp -p GeoSite.dat.bak GeoSite.datを実行してから再テストします。テストに合格してからサービスを起動してください。

自動更新：geox-urlと更新間隔の設定

これらの項目に対応したmihomoでは、geox-urlでダウンロード元を指定し、geo-auto-updateで定期更新の有効・無効を切り替え、geo-update-intervalで更新間隔を時間単位で設定します。ダウンロード先を指定しただけでは、定期更新は有効になりません。以下はトップレベルの設定例です。ノードやプロキシグループを含む完全な設定ファイルではないため、既存の設定に統合してください。

# トップレベルの項目。dns、rulesと同じ階層
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"

geoipはgeoip.datに対応します。この例ではDATモードを有効にしており、GeoIPルールはこのファイルを使用します。
geositeはGeoSite.datに対応します。GEOSITEによるドメイン分類にはこのファイルが必要です。
mmdbはCountry.mmdbに対応し、MMDBモードに戻すときに使います。入手先を設定しても、毎回すべてのファイルをダウンロードする必要はありません。
24は24時間を表します。毎日0時でも24分でもありません。端末がスリープ中、またはコアが終了している間は、常時稼働のサービスと同じように更新されるとは限りません。

初回起動時にファイルがない場合、自動ダウンロードが始まることがあります。しかし、ダウンロードに必要な通信が、まだ読み込まれていないルールや利用できないプロキシに依存していると、起動時の依存関係で行き詰まります。その場合は、まず使えるデータベースを手動で配置してから更新経路を調べるほうが、失敗ログを見ながら再起動を繰り返すより確実です。

ルールの書き方：GEOSITEを先に、GEOIPを後に

ドメインルールはドメインの分類、IPルールは接続先IPアドレスの分類に使われ、判定する内容が異なります。「特定サービスのドメインだから、サーバーも特定の国・地域にある」とは限りません。サイトが海外CDNを利用していたり、同じドメインから複数地域のアドレスが返されたりするため、通常は明確なドメインルールを先に置き、より広いIPルールを後にします。最後にMATCHを残してください。

以下では、既存の設定にPROXYという名前のプロキシグループが定義されているものとします。この名前は大文字・小文字を区別するため、実際の設定と完全に一致させてください。ルールだけをコピーして、参照先のアウトバウンドを設定し忘れないようにしましょう。

mode: rule

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

各ルールのマッチ動作を確認する

DOMAIN-SUFFIXは特定ドメインに対する例外ルールです。広い分類ルールに先にマッチしないよう、分類ルールより前に置きます。ここでのexample.comは書式の例です。
GEOSITE,cn,DIRECTは、ドメインデータ内のcn分類にマッチします。ドメイン分類の判定に、実IPアドレスへの事前解決は必要ありません。
GEOIP,private,DIRECT,no-resolveはプライベートアドレスの分類を使います。このタグが選択したデータソースに含まれている必要があります。MMDBモードとDATモードで、同じタグがすべて使えるとは限りません。
GEOIP,CN,DIRECTは接続先IPアドレスから所属地域を判定します。ドメイン名だけの接続では、名前解決が発生することがあります。
MATCH,PROXYは、それ以前のルールにマッチしなかった接続を受け持ちます。「自動判定」ではなく、最後のフォールバックルールです。

no-resolveはDNS漏えい防止の設定ではない

no-resolveは、このIPルールにマッチさせるための積極的なドメイン名前解決を行わない指定です。接続に利用可能な接続先IPアドレスがあれば、ルールにマッチする場合があります。ドメイン名しかなく、利用できるIPアドレスもない場合は、後続ルールの判定に進みます。すべてのGEOIPルールに指定すると、名前解決結果に依存する直結ルールが機能せず、より多くの接続がMATCHに回ることがあります。

fake-ipモードでもGeoSiteは使えます。コアはfake-ipの対応関係からドメインを特定できますが、GEOIPで198.18.0.0/16の合成アドレスをサーバーの実際の所在地として扱ってよいわけではありません。原因を調べる際は、ドメイン、実際の名前解決結果、マッチしたルールをあわせて確認しましょう。接続一覧のIPアドレスだけを見ても判断できません。

更新後もルールにマッチしない場合：ログから原因を切り分ける

症状	まず確認する項目	対処方法
起動時に分類が見つからないと表示される	ルールのタグとデータベースの入手元が一致しているか	データソースの分類一覧を確認し、ルールを修正するか元のデータベースに戻す
データベースの解析に失敗する	ファイル形式の誤り、ダウンロードの未完了、HTMLページの保存	バックアップを戻し、一時ファイルとして再ダウンロードしてから設定をテストする
ログにファイルのダウンロードが必要と表示され続ける	ディレクトリ、大文字・小文字、実行ユーザーが正しいか	コアの起動引数とサービスの作業ディレクトリを確認する
定期更新のダウンロードがタイムアウトする	ダウンロード先ドメインの名前解決、ネットワーク経路、プロキシの利用可否	まず手動更新で起動できる状態に戻し、その後ダウンロード経路を個別にテストする
データベースの読み込みには成功するが、フォールバックルールに回る	ルールの順序、分類データの内容、接続にドメイン名が含まれているか	接続のルールマッチ情報を確認する。出口IPだけを見ない

変更する項目は一度に1つに絞りましょう。まずルールは変えずにファイルを更新し、起動できることを確認します。次にルールの順序を調整し、最後にgeodata-modeまたはデータソースを切り替えます。3項目を同時に変更するとログはにぎやかになりますが、原因の特定は速くなりません。

検証前にクライアントがルールモードになっていることを確認し、対象アプリの既存接続を閉じてから、新しいリクエストを送ります。既存のTCP接続は、ルールやデータベースを変更しても通常は自動で別の出口に切り替わりません。ブラウザーの接続再利用も確認を妨げます。調査対象のドメインでテストし、接続履歴からマッチしたルールの種類と内容、最終的に選ばれたプロキシグループを確認してください。

一時的にログレベルを上げた場合は、調査後に元の設定へ戻してください。ログを共有する前に、サブスクリプションURL、アクセストークン、ノードの認証情報、コントロールインターフェースのキーを隠します。データベースの調査に必要なのは読み込みパスとエラー行であり、アカウント情報一式ではありません。

運用記録：復元できる組み合わせを残す

コア情報を記録する：mihomo -vの出力を保存し、クライアント更新後に古いコアを前提として対応項目を判断しないようにします。
データソースを記録する：リポジトリ、ダウンロード日、使用したタグ、geodata-modeを記録しておくと、マッチ結果が変わった理由を確認できます。
動作する設定を保管する：データベースのバックアップと一緒に対応する設定も保存します。復元時に、新しいルールが旧データベースにない分類を参照する事態を防げます。
2つの更新経路を分けて確認する：サブスクリプションはノードと設定を更新し、地理データの更新は分類ファイルを更新します。一方の成功表示を、もう一方の成功確認として扱わないでください。

最終確認では、コアが正しいディレクトリのファイルを読み込めること、ルールが参照する分類が実際に存在すること、新しい接続が想定したプロキシグループにマッチすることの3点を確認します。満たした後で、更新頻度やダウンロード元を最適化しましょう。データベースが新しいほど、必ずしも自分のルーティング要件に合うとは限りません。明示的なルールは、広い分類ルールより前に置いてください。