GeoIP・GeoSiteデータベースの更新方法｜geodataの自動ダウンロードとルール設定

GeoIPとGeoSiteの違い：IPアドレスとドメインをそれぞれ判定

Clashのルール振り分けの精度は、ルールの順序だけでなく、参照するデータにも左右されます。GeoIPはIPアドレスの範囲を国・地域などのグループに分類し、GeoSiteはドメインをサイト・サービス・地域別に分類します。どちらも判定の基準となるデータであり、プロキシノードを提供したり、特定のカテゴリを直結にするかプロキシ経由にするかを自動で決めたりするものではありません。

たとえば、GEOIP,CN,DIRECTは宛先IPがデータベース内のCNグループに該当した場合に直結し、GEOSITE,cn,DIRECTはドメインがcnカテゴリに該当した場合に直結します。サイトが海外CDNを利用していたり、複数の地域にサーバーを配置していたり、共有IPを使っていたりすると、両者の判定結果が異なることがあります。必ずしもデータベースの破損を意味するわけではなく、分類対象の違いによるものです。

項目	GeoIP	GeoSite
主な判定対象	宛先のIPv4またはIPv6アドレス	接続に関連付けられたドメイン
主なファイル	geoip.dat、Country.mmdb	geosite.dat
ルール例	`GEOIP,CN,DIRECT`	`GEOSITE,cn,DIRECT`
よくある不一致	IPアドレスの所在地とサービスの用途は異なる	新しいドメインが未収録、または分類が異なる

データの出所が共通基準を保証するわけではない

GeoSiteはv2fly/domain-list-communityやその派生ビルドでよく使われます。GeoIPは、複数のIPアドレスデータプロジェクトの情報を変換して作られる場合があります。MetaCubeX/meta-rules-datでは、mihomo向けのビルド済みデータが公開されています。ファイル名が同じでも、データの出所によってカテゴリや収録範囲、更新頻度は異なることがあります。geolocation-!cnのようなカテゴリを使う前に、現在のデータソースにそのカテゴリが含まれていることを確認してください。別のルールデータベースにあるカテゴリ名をそのまま流用することはできません。

設定前にmihomoカーネルを使用しているか確認

以下で説明するgeodata-mode、geox-url、自動更新の設定はmihomoを対象としています。Clashはクライアント環境全般でよく使われる呼び方ですが、画面が似ていてもカーネルの機能まで同じとは限りません。旧バージョンのClashカーネルでは、これらの項目に対応していない場合があります。クライアントのバージョン番号だけではなく、カーネルのバージョンも確認してください。

クライアントの「バージョン情報」「カーネル情報」または起動ログで、実際のカーネル名と完全なバージョン番号を確認し、mihomoと表示されていることを確かめます。
現在有効なサブスクリプション設定を確認し、オーバーライド、マージ、スクリプト処理の有無を調べます。
現在有効な設定をバックアップします。サブスクリプションの更新で変更が上書きされないよう、グローバル設定はクライアントが提供する永続的なオーバーライド機能に追加してください。
動作モードをルールモードに設定します。グローバルモードや直結モードでは、以下のルールに基づく振り分けは行われません。

geox-urlと自動更新：そのまま追加できる設定例

以下の設定はYAMLのトップレベルに記述し、rulesやdnsと同じ階層に置きます。ポリシーグループの中には入れないでください。この例ではGeoIPにDAT形式を指定し、MetaCubeXのリリースファイルを利用します。データベースの設定のみを示したもので、プロキシノードを含む完全なサブスクリプションではありません。

geodata-mode: true
geodata-loader: memconservative

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形式のデータを使用します。falseにするとMMDB形式を使用します。この設定はGEOSITE全体の有効・無効を切り替えるものではありません。
geodata-loader: memconservative：メモリ使用量を抑えるgeodataローダーを選択します。更新間隔の設定や、ダウンロードしたファイルの形式変換は行いません。
geo-auto-update: true：カーネルのGEOデータ自動更新を有効にします。実際に動作するカーネルがこの設定に対応している必要があります。
geo-update-interval: 24：更新間隔を24時間に設定します。24分ごとの更新でも、毎日決まった時刻に実行する設定でもありません。
geox-url：ファイルの種類ごとにダウンロード先を指定します。MMDBとDATは、拡張子を書き換えるだけでは相互に変換できません。

この例では、後からモードを切り替えられるようにmmdbのURLも残しています。ただし、実行時にすべてのファイルが同時に使われるという意味ではありません。どのデータをダウンロードして読み込むかは、有効な設定、ルールの参照先、カーネルの実装によって異なります。キャッシュがある場合、URLを変更しただけで更新済みとは判断できません。実際に更新を実行し、ログを確認してください。

ダウンロード先には実際のファイルを指定

カスタムURLの応答は、指定した形式のバイナリファイルである必要があります。リポジトリのトップページ、ログインページ、ダウンロード案内ページを指定してはいけません。GitHubのリリースURLは別のURLにリダイレクトされることがあるため、ネットワーク側で最初のURLだけでなく、最終ファイルのホストにも接続できるようにしてください。タイムアウトした場合は、まずログで接続先とエラー内容を確認し、そのうえで信頼できるデータソースへの変更を検討します。

データベースのダウンロードには、起動時の依存関係もあります。振り分けに必要なデータをカーネルがまだ取得していないと、そのデータを参照するルールが正常に読み込まれないことがあります。初回導入時は、まずダウンロード先に接続できることを確認してください。必要に応じてクライアントの手動更新機能を使うか、データベースをオフラインで配置してからGEOルールを含む設定を読み込みます。ダウンロードリクエストが現在選択中のプロキシノードを経由するとは限りません。

GEOIP・GEOSITEルール：カテゴリとポリシーグループの両方を確認

ルールは上から順に評価され、最初に一致したルールが適用されます。以下の例では、プライベートネットワークのアドレスを先に処理し、国内ドメインと分類済みの海外ドメイン、国内IPアドレスの順に判定して、最後に残りの通信を処理します。既存の設定に代理出口という名前のポリシーグループがある前提です。利用前に、設定内の実際のグループ名に置き換えてください。

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,代理出口
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,代理出口

DIRECTは組み込みの直結ポリシーです。一方、代理出口はユーザーが定義した名前なので、ポリシーグループ名と完全に一致させる必要があります。既存のグループ名がPROXYの場合は、2か所の「代理出口」を置き換えてください。トップレベルにrulesを新たに追加せず、既存のルール一覧に統合するか置き換え、サブスクリプションで必要な個別ルールは残してください。

海外ドメインのルールをGEOIPより先に置く理由

海外サービスのドメインが分類されていても、名前解決の結果が国内CDNのIPアドレスになる場合があります。GEOIP,CN,DIRECTが先に一致すると、接続が直結される可能性があります。IPアドレスの所在地を判定するルールより前に、ドメインを指定したルールを置くと、サービス単位の意図を優先できます。ただし、geolocation-!cnはデータベース上のカテゴリ名であり、すべての海外サイトを網羅するものではありません。未収録の接続は後続のルールで処理する必要があります。

no-resolveはDNSを無効にする設定ではない

no-resolveは、このIP系ルールのためだけにドメインを積極的に名前解決しないことを示します。接続に実際の宛先IPアドレスがすでにある場合は、GEOIPで判定できます。一方、その時点でドメインしかなく、利用可能な実IPアドレスがない場合は、このルールがスキップされて次のルールに進むことがあります。DNSの漏えいを防ぐ設定でも、GeoIPを自動更新する設定でもありません。未分類のドメインをこのルールで判定するために名前解決させる場合は、このパラメーターを外せますが、名前解決の遅延やDNSの経路を考慮してください。

更新手順：設定の読み込み、データの更新、ルールの判定確認

データベースの更新とサブスクリプションの更新は別の処理です。サブスクリプションの更新では通常、ノードや設定を取得します。GEOデータの更新では、分類データのファイルを置き換えます。クライアントにサブスクリプションの更新成功と表示されても、geosite.datが更新されたとは限りません。

有効な設定を確認します。最終的に読み込まれるYAMLで、自動更新の設定やURLがサブスクリプションまたはオーバーライドによって上書きされていないことを確認してください。
設定を再読み込みします。ログに未知の設定項目、YAMLのインデントエラー、存在しないカテゴリ、見つからないポリシーグループが表示されていないか確認してください。
GEOデータを手動で一度更新します。クライアント上でGEOデータ更新用と明記された機能を使います。機能が見当たらない場合は、そのクライアントのドキュメントに従ってください。サブスクリプション更新ボタンで代用できるとは限りません。
更新結果を確認します。ダウンロードの成否がわかるログと、実際のデータディレクトリにあるファイルの更新日時を記録します。更新日時からわかるのはファイルに変更があったことまでです。データが正常に読み込まれたかも確認してください。
新しい接続を作成します。国内ドメイン、分類済みの海外ドメイン、プライベートネットワークのアドレスにそれぞれ再接続し、接続詳細でルールの種類、マッチした内容、最終的なポリシーを確認します。

テストには新しい接続を使用してください。ブラウザーの接続再利用、アプリの長時間接続、既存のセッションでは、以前のポリシーが引き続き使われることがあります。ページを一度再読み込みしただけでは、新しい接続にならない場合があります。調査時は対象アプリを終了して再起動するか、該当する接続だけを切断してください。すべての通信を一度に中断する必要はありません。

よくあるトラブル：ダウンロード失敗、カテゴリ不足、更新後の誤振り分け

症状	まず確認する項目	対処方法
ダウンロードがタイムアウトする、または接続に失敗する	ドメインの名前解決、接続経路、リリースファイルのリダイレクト	まずデータ取得先に接続できる状態にしてから、更新を再試行する
データベースの解析に失敗する	ダウンロードした内容がWebページではないか、指定形式と一致しているか	正しいDATまたはMMDBファイルを取得する
カテゴリが存在しないと表示される	現在のデータソースに、ルールで参照しているカテゴリが含まれているか	カテゴリを変更するか、そのカテゴリを含むデータビルドに切り替える
ルールで指定したポリシーが見つからない	ポリシーグループ名と大文字・小文字の違い	ルールの振り分け先を、既存のポリシーグループ名と完全に一致させる
更新に成功しても振り分け先が変わらない	動作モード、先行するルール、既存の接続	ルールモードに切り替え、新しい接続で最初に一致したルールを確認する

オフラインでファイルを置き換える前にデータディレクトリを確認

データディレクトリはクライアントごとに異なり、サービスとして実行する場合と通常のユーザーとして実行する場合でも保存先が異なることがあります。クライアントが提供するディレクトリ表示機能やカーネルの起動パラメーターで場所を確認し、インストール先にあると決めつけないでください。手動で置き換える場合は、そのディレクトリを使うカーネルを停止し、既存ファイルをバックアップしてから、正しい形式のデータベースを所定のファイル名で配置します。その後、カーネルを起動して読み込みログを確認してください。

特定のドメインだけ誤って振り分けられる場合は、すぐにデータベース全体を入れ替える必要はありません。該当するGEOルールより前に、対象範囲を絞ったDOMAINまたはDOMAIN-SUFFIXルールを追加し、想定どおりのポリシーになるか確認したうえで、分類の問題をデータ提供元に報告できます。例外を具体的に設定しておくと、データベース側で後日修正された際に整理しやすくなります。

確認範囲を分ける：ルールセット、DNS、TUN

rule-providersは個別に更新されます。リモートルールセットのintervalは通常、秒単位です。たとえば86400は1日を表します。一方、この記事のgeo-update-interval: 24は時間単位です。2つの設定を混同しないでください。
DNSが利用可能な名前解決情報を左右します。GeoSiteによる判定には、接続に関連付けられたドメインが必要です。fake-ip環境では、関連付けの情報を使うことでドメイン名を保持しやすくなります。ただし、IPアドレスしかない接続がすべて自動的にドメイン名を持つわけではありません。
TUNは通信を取り込む範囲を決めます。TUNを有効にすると、より多くのシステム通信を取り込めますが、データベースの分類を修正したり、ルールの優先順位を変更したりする機能ではありません。
GEOデータからプロキシノードは取得できません。データベースのダウンロードに成功しても、プロキシを利用できるかどうかは、サブスクリプション、ノードの状態、ポリシーグループの選択によって決まります。

安定して運用するには、まずカーネルと有効な設定を確認し、次にデータベースの出所と更新結果を確認してから、新しい接続でルールの判定経路を調べます。ドメイン例外を明確にし、必要に応じてIPアドレスのフォールバックを設定してください。サブスクリプション更新とローカルオーバーライドの役割を分けておくことで、次回の更新後に以前の動作へ戻るのを防げます。設定項目の意味はmihomoの一般設定ドキュメント、カテゴリやファイルの収録範囲はMetaCubeXのデータリポジトリで確認できます。