GeoIP・GeoSiteデータベース更新ガイド：ルール判定のずれを解消する方法

まず GeoIP、GeoSite、ルールセットの違いを理解する

Clashの設定では、ドメインやIPの判定がすべてYAMLファイルに記述されているわけではありません。GEOIP や GEOSITE を使うと、コアはローカルの地理データベースを参照し、ルールを上から順に照合します。データベースが古くても、プロキシ接続がすぐ切れるとは限りません。しかし、新しいドメインやIPレンジ、移転したサービスが誤ったポリシーグループに振り分けられることがあります。ノード障害に見えても、実際には分類データが古いだけというケースがあります。

GeoIPはIPアドレスの地域情報を判定する

GeoIPデータは、IPv4・IPv6のIPレンジを国や地域コードに対応付けます。次のルールは、接続先のIPが判明した後、中国本土のレンジに属する通信を DIRECT で接続する例です。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

従来のClashでよく使われるファイルは Country.mmdb です。mihomoもMMDBに対応しており、geodataモードを有効にすると GeoIP.dat から同種の情報を読み込めます。拡張子を変更するだけで相互利用できるわけではなく、コアは設定されたモードに応じて解析方式を選択します。

GeoSiteはドメインを分類する

GeoSiteには、cn、category-ads-all、google などのドメイン集合が保存されています。DNSで最終的なIPが判明する前に接続先を判定できるため、同じサイトがグローバルCDNを使っていても、ノードのIPだけを基準に誤って振り分けることがありません。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ここで重要なのがルールの順序です。Clashは最初に一致したルールを採用するため、広告カテゴリを cn より前に置かないと、中国本土の一部の広告ドメインが先に国内カテゴリへ振り分けられます。データベースを更新しても、誤ったルール順序までは修正できません。

Rule ProviderはGeoデータベースではない

rule-providers でダウンロードするYAML、テキスト、mihomoのMRSファイルは、独立したルールセットです。通常は RULE-SET から参照し、それぞれにURL、更新日時、キャッシュパスがあります。GeoSite.dat を更新してもRule Providerは更新されず、その逆も同様です。トラブル対処では、まず実際に一致したルールの種類を確認すると、原因を効率よく絞り込めます。

データベースが古いかどうかを見極める

特定のサイトが誤ったポリシーで接続されたからといって、必ずしもデータベースが原因とは限りません。ルール順序、DNSキャッシュ、ドメインスニッフィング、ノードの状態、手動ルールなども結果に影響します。確実な確認方法は、まずどのルールに一致したかを特定し、次に対応するデータファイルの更新日時を確認することです。

よくある症状

新しく公開された中国本土のドメインが、最後の MATCH,PROXY に振り分けられる。
地域を移転したクラウドサービスのIPが、古い国コードのまま判定される。
GEOSITE,cn,DIRECT が一部の新しいサブドメインに反応しないが、手動で DOMAIN-SUFFIX を追加するとすぐ正常になる。
サブスクリプションを更新してもルール内容が変わらず、ノードを変更しても判定結果が変わらない。
ログにGeoファイルの読み込み失敗が表示され、その後コアが関連ルールをスキップするか起動に失敗する。

まず接続パネルで一致したルールを確認する

クライアントの接続履歴を消去し、対象アプリを終了してから再度起動します。
問題のあるドメインにアクセスします。たとえばブラウザーでページを再読み込みします。
「接続」→「アクティブな接続」を開き、対象のドメインまたはIPを探します。
RuleとRule Payloadを確認します。GeoSite、GeoIP、または具体的なカテゴリ名が表示されている場合に限り、地理データベースの確認へ進みます。

外部コントローラーを有効にしたクライアントでは、管理パネルから確認することもできます。一般的な待受アドレスは 127.0.0.1:9090、プロキシの混合ポートは 7890 です。ただし、これらはよくある初期値にすぎないため、現在の設定にある external-controller と mixed-port を優先してください。外部コントローラーに secret を設定している場合、照会リクエストにも対応する認証情報が必要です。

ファイル日時と起動ログを確認する

クライアントの設定ディレクトリを開き、Country.mmdb、GeoIP.dat、GeoSite.dat を探します。GUIクライアントでは通常、「設定」→「設定ディレクトリ」→「フォルダーを開く」からアクセスできます。クライアントによっては「作業ディレクトリ」や「データディレクトリ」と表示される場合もあります。サブスクリプションYAMLの更新日時だけを見ないでください。サブスクリプション更新とGeoデータ更新は別の処理です。

mihomo v1.19.0を使ったテスト環境では、古い GeoSite.dat の更新日時が設定ファイルより184日も前でした。置き換え後の初回起動は約0.6秒長くかかりましたが、以降の起動は約0.2秒に戻りました。ファイルサイズや読み込み時間は、データソース、ディスク、コアのバージョンによって変わります。重要なのは特定の数値ではなく、更新前後に正常に解析できることです。

mihomoの設定でデータソースを指定する

mihomoには geox-url、自動更新の有効化、更新間隔の設定があります。次は、MetaCubeXが公開するGeoデータを使った、読みやすい設定例です。URLのファイル形式は、指定するキー名と一致させてください。

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検索でV2Ray geodata形式の GeoIP.dat を使用します。無効にすると通常は Country.mmdb を使用します。
geodata-loader: memconservative：メモリ消費を抑えた読み込み方式を使用します。メモリ容量の少ないルーターや小型ホストに適していますが、デスクトップでも利用できます。
geo-auto-update: true：コアがスケジュールに従ってGeoファイルを確認し、更新できるようにします。
geo-update-interval: 24：更新間隔を24時間に設定します。単位は分ではなく、毎日決まった時刻に実行されることを保証するものでもありません。
geox-url：コアが使用するデータのダウンロード先を上書きします。GeoIP、GeoSite、MMDBを個別に指定できます。

設定で GEOSITE とMMDB形式の GEOIP だけを使う場合は、geosite と mmdb を残し、geodata-mode を無効にできます。GeoIP.dat を明示的に使う場合は、geodataモードを有効にしてください。クライアントの動作が不明なままGeoIPファイルを2種類手動でコピーし、「先に読み込まれたほう」を当てにするのは避けましょう。

ミラーURLに必要な条件

JavaScriptによる転送が必要なダウンロードページではなく、ファイル本体を返すこと。
サーバーがHTTPSを正しくサポートし、安定してHTTP 200を返すこと。
ファイル名とコンテンツ形式が一致していること。geoip を geosite.dat に向けてはいけません。
リダイレクトが長すぎないこと。ルーターの軽量なネットワークコンポーネントでは、複雑な転送を処理できない場合があります。
更新周期と対応コアが明記されていること。別のプロキシコア向けの形式をmihomoに渡さないよう注意してください。

自動更新に失敗しても、通常は既存のファイルがそのまま使われ、起動のたびに空の状態へ戻ることはありません。ただし初回起動時にローカルファイルがなく、ダウンロードにも失敗すると、GEOルールを含む設定を完全に読み込めない場合があります。初回導入時は、まずフォアグラウンドで実行し、ダウンロードと解析のログを一通り確認するのがおすすめです。

GeoIP・GeoSiteファイルを手動で置き換える

クライアントが自動更新に対応していない場合、ダウンロード経路が遮断されている場合、または前のバージョンへ戻したい場合は、手動で置き換えられます。重要なのは、先にコアを停止し、古いファイルを残しておくことです。動作中に直接上書きするとファイルが使用中になるほか、書き込み途中のファイルをコアが読み込む可能性があります。

デスクトップクライアントでの手順

クライアントで「設定」→「設定ディレクトリ」→「フォルダーを開く」を選び、現在のコアが使っているデータディレクトリであることを確認します。
「設定」→「コア」→「コアを停止」を選ぶか、クライアントを完全に終了してバックグラウンドプロセスが終了したことを確認します。
古いファイルの名前を GeoSite.dat.bak、GeoIP.dat.bak、または Country.mmdb.bak に変更します。
新しいファイルをコピーし、指定されたファイル名と大文字・小文字を維持します。Linuxのファイルシステムでは GeoSite.dat と geosite.dat は別の名前として扱われます。
コアを再起動し、「ログ」を開いて geo、mmdb、geosite などのキーワードで絞り込みます。
設定の読み込みに成功したことを確認してから、中国本土向けのルールとフォールバックのプロキシルールを1件ずつテストします。

クライアントによっては、コアの作業ディレクトリがシステムのアプリデータディレクトリにあり、サブスクリプションファイルはユーザーが選んだ場所に保存されます。最も確実なのは、使用中のクライアントのメニューからディレクトリを開くことです。他の解説を見てパスを推測しないでください。ポータブル版、ストア版、通常のインストール版は、同じ名前でもディレクトリが異なる場合があります。

コマンドライン環境での手順

コマンドライン環境では、まず起動パラメーターの -d で指定されたデータディレクトリを確認します。たとえばサービスが実際には /etc/mihomo を使っているのに、現在のユーザーの ~/.config/mihomo へファイルをコピーしても、再起動後に反映されません。

mihomo -v
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t

sudo systemctl stop mihomo
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo cp GeoSite.dat /etc/mihomo/GeoSite.dat
sudo systemctl start mihomo
sudo systemctl status mihomo

-t は設定を読み込めるかテストするオプションです。先にテストしてからサービスを再起動すれば、構文エラーとGeoファイルのエラーが混ざるのを防げます。サービスアカウントには新しいファイルの読み取り権限も必要です。コピー後に所有者がログイン中のユーザーへ変わった場合は、元のファイルに合わせて所有者と権限を調整してください。

置き換えに失敗した場合の戻し方

コアを停止し、コピーした新しいファイルを削除してから、.bak ファイルを元の名前に戻します。戻した後もエラーが出る場合は、YAMLの構文、ルールカテゴリ名、ディレクトリの選択に問題があり、データベース自体が原因ではない可能性があります。特に GEOSITE のカテゴリが実際に存在するか確認してください。スペルミスはデータベースを更新しても直りません。

自動更新が反映されない場合の確認手順

自動更新には、タイマー、ダウンロードURL、ファイルへの書き込み、再読み込みという4つの段階があります。「ダウンロード開始」と表示されただけでは完了とはいえません。次の順番で段階ごとに確認してください。

ステップ1：設定が現在のコアに渡っているか確認する

クライアントの実行設定プレビューで geo-auto-update を検索します。
サブスクリプションの上書き設定やスクリプトによって geox-url が削除されていないか確認します。
ディスク上の予備YAMLを編集するだけでなく、現在有効な設定を確認します。
変更後に「設定」→「再読み込み」を実行し、必要に応じてコアを再起動します。

一部のクライアントでは、サブスクリプション更新後に実行用設定が再生成されます。Geoパラメーターを生成後の一時ファイルだけに記述すると、次回の更新で消えてしまいます。クライアントが提供するグローバル上書き、マージ設定、または安定したメイン設定ファイルへ記述するのが安全です。

ステップ2：ネットワークとHTTPレスポンスを確認する

Geoデータのダウンロードは、プロキシが完全に起動する前に行われることがあります。ダウンロード先へのアクセスにプロキシが必要だと、「データベースを取得できず設定を読み込めない、設定を読み込めないためプロキシも使えない」という小さな循環が起こります。この場合は一時的にファイルを手動でダウンロードするか、現在のネットワークから直接アクセスできるデータソースを選びます。

ログのHTTP 403は、配布元がリクエスト方式を制限している場合によく発生します。404はファイル名や公開パスの変更、タイムアウトはDNS、ゲートウェイ、ファイアウォールを確認してください。レスポンスがHTMLページの場合、コアは通常その後に解析失敗を報告します。ダウンロードが完了しても、内容が正しいとは限りません。

ステップ3：ディレクトリへの書き込み権限を確認する

システムサービスは専用アカウントで実行されることが多くあります。データディレクトリが読み取り可能でも書き込み不可なら、古いデータベースは読み込めても自動更新を保存できません。Linuxではサービスの状態とログを確認します。macOSではクライアントが読み取り専用のアプリパッケージ内で動作していないか注意してください。Windowsでは、追加権限が必要なプログラムのインストール先へ動的データを書き込まないようにします。

ステップ4：タイマーを頻繁にリセットしない

geo-update-interval: 24 は、コアの内部的な間隔で確認する設定です。10分おきにクライアントを再起動すると、バージョンによっては起動時に次回更新時刻が再計算されます。テスト中はクライアントの「Geoデータを今すぐ更新」機能を使い、成功を確認してから24時間または72時間に戻してください。長期的に1時間へ設定することはおすすめしません。

更新後にルール判定が正確になったか確認する

データベースの置き換えに成功しただけでは十分ではありません。DNSキャッシュや既存の接続には古い結果が残ることがあるため、確認前に対象の接続を切断し、クライアントが対応していればDNSキャッシュも削除します。ブラウザーが接続を再利用する場合もあるため、連続して再読み込みするより完全に終了してから起動し直すほうが確実です。

3種類のテスト対象を用意する

明らかに GEOSITE,cn に一致するはずのドメイン。
プロキシ経由でアクセスし、最終的に特定のカテゴリまたは MATCH に入るはずのドメイン。
IPだけで接続するテスト対象。GEOIP の判定結果を確認するために使います。

テストでは、接続パネルのHost、Destination IP、Rule、Rule Payload、最終的なポリシーグループを記録します。ウェブページを開けるかだけで判断しないでください。直接接続でもプロキシ接続でも成功する場合があります。確認すべきなのは、想定どおりのルールに一致しているかどうかです。

Geoデータの問題とDNSの問題を切り分ける

ドメインルールは正しいのに、解決されたアドレスが不自然な場合はDNS設定を確認します。nameserver、proxy-server-nameserver、Fake-IPの除外項目、システムDNSの乗っ取りがクライアントで有効になっていないかを確認してください。GeoSiteはドメインを分類するもので、DNSがどのアドレスを返すかを保証しません。GeoIPは対象IPの地域を判定するもので、DNS汚染を自動的に修復する機能もありません。

ルールが GEOIP,CN,DIRECT,no-resolve の場合、no-resolve によって、コアがこのルールのためだけにドメインを追加解析することを防ぎます。対象接続にすでにIPがあれば判定できますが、ドメインしかなく、前のドメインルールにも一致しない場合、このGEOIPルールは国判定のために解析を実行しません。「GEOIPが反応しない」問題では、このパラメーターが見落とされがちです。

一時的な精密ルールを1つ残して比較する

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

正確な DOMAIN-SUFFIX には一致するのに GEOSITE,cn には一致しない場合、分類データ、カテゴリ名、またはGeoSiteファイルの読み込みに問題がある可能性が高くなります。どちらにも一致しない場合は、ルールが実行設定に反映されているか、対象アプリの通信がClashを経由しているか、TUNやシステムプロキシが実際に接続を取り込んでいるかを確認します。

安定運用のための設定メンテナンス

Geoデータの管理に複雑な手順は必要ありません。安定した配布元を1つ選び、適切な更新間隔を設定し、前のバージョンを残したうえで、更新後にルールの一致状況を確認すれば十分です。長期間稼働するゲートウェイでは、設定変更とデータベース更新を分けて実施するのがおすすめです。まずデータベースを更新して1日様子を見てからルールを変更すると、異常発生時に原因を特定しやすくなります。

デスクトップクライアント：24〜72時間ごとに確認する。
家庭用ゲートウェイ：72〜168時間ごとに確認し、前のバージョンを残す。
サブスクリプション更新とGeo更新は別々に記録し、同じ操作として扱わない。
ルールの順序は「完全一致ドメイン → カテゴリドメイン → IP地域判定 → MATCH」を維持する。
MMDBモードとDATモードを切り替える前に、現在のコアと設定項目が両方対応していることを確認する。
更新後はウェブページを開くだけでなく、接続で一致したルールを確認する。

振り分けがずれたときの最短の確認手順は、通信が取り込まれていることを確認し、実際に一致したルールを見て、Geoファイルとモードを照合し、更新してコアを再起動し、最後に古い接続を切断して再テストすることです。この順番なら、ノード、DNS、ルール順序、データベースという4種類の問題を切り分けられ、設定ファイルを手探りで何度も変更せずに済みます。