Clash GeoIP・GeoSiteデータ更新ガイド：ルール参照、更新間隔、トラブル対処

DATA MAP / データの境界

まず GeoIP、GeoSite、ルールセットを区別する

結論から言うと、GeoIP は宛先 IP アドレスで分類し、GeoSite はドメイン名で分類します。両者は置き換えて使えるものではありません。設定に GEOIP や GEOSITE と記述しても、それはルールエンジンが対応するデータベースを検索することを示すだけです。最終的に直接接続、プロキシ、拒否のどれを選ぶかは、ルール末尾で指定したポリシーが決めます。データベース自体がプロキシ接続を確立したり、現在のプロキシモードを自動変更したりすることはありません。

GeoIP データは、IP アドレスのネットワーク範囲を国、地域などの識別可能な分類に対応付けます。一般的な GEOIP,CN,DIRECT は、接続先 IP がデータベース上で CN に分類された場合に、DIRECT ポリシーで処理するという意味です。カーネルによって MMDB、専用の GeoIP データファイル、変換済みの内部形式などが使われ、ファイル名や読み込み方法は完全には一致しません。そのため、拡張子だけで現在のカーネルがデータベースを使用しているか判断することはできません。

GeoSite データには、地域別ドメイン、一般的なサービス、広告ドメインなど、ドメイン名の集合と分類ラベルが保存されています。GEOSITE,cn,DIRECT は、接続中のドメイン名を集合と照合します。DNS 解決前にドメイン単位で振り分けられるため、IP の所属地域だけに依存した場合に CDN、グローバル負荷分散、共有アドレスによって生じる誤判定も避けやすくなります。

ルールセットとは通常、rule-providers が提供する外部ルールファイルを指します。ドメイン、IP-CIDR、従来形式のルール項目を読み込み、RULE-SET から参照できます。ルールセットと GeoSite はどちらもドメイン分類を保持できますが、ダウンロード先、更新間隔、動作種別、設定上の入口が異なります。あるルールセットを更新しても GeoSite データまで同期されるわけではなく、その逆も同様です。

データ種別	主な入力	代表的なルール	適用範囲
GeoIP	宛先 IP	`GEOIP,CN,DIRECT`	アドレスの所属地域で振り分けるため、結果はデータベースの収録範囲に左右されます
GeoSite	宛先ドメイン	`GEOSITE,cn,DIRECT`	ドメイン集合で振り分けるため、対応する分類をカーネルがサポートしている必要があります
ルールセット	外部ルール項目	`RULE-SET,local-sites,DIRECT`	参照元、形式、更新間隔を設定側で個別に定義します

RULE PATH / 参照関係

GeoIP と GeoSite を設定から参照する方法

ルールは上から順に確認され、マッチすると以降の判定は停止します。データベースの更新に成功していても、該当ルールがより広範なルールの後ろにあると、通信は新しいルールまで到達しません。「データベースは更新されたのに振り分けが変わらない」場合は、ファイルを何度も再取得するより、まずルールの順序を確認する方が有効です。

以下は、GEOSITE に対応する Mihomo で使える設定例の考え方です。ポリシーグループ名は使用中の設定に合わせてください。例の ノード選択 はポリシー名であり、固定キーワードではありません。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,ノード選択

1 行目で広告ドメインを処理し、2 行目で CN ドメインを処理します。3 行目は宛先 IP が取得済みの場合に CN アドレスを照合し、最後の行がそれまでにマッチしなかった接続を受け持ちます。MATCH を先頭に置くと、後続のデータベースルールがマッチする機会はなくなります。また、GEOSITE,cn,DIRECT の前に、より広い範囲を対象とするドメインルールを置くと、本来直接接続すべきドメインを先に捕捉することがあります。

no-resolve は IP 系ルールでよく使われ、該当ルールを実行するためにルールエンジンが追加のドメイン解決を行うのを防ぎます。すでに存在する宛先 IP を無視する機能でも、DNS モジュールを停止する機能でもありません。IP で直接開始された接続には GeoIP を適用できますが、その時点でドメインしかなく実際の宛先 IP がまだ得られていない接続では、マッチせず後続ルールの判定に進む場合があります。

ドメインルールと IP ルールは両方残すべきか

地域別振り分けの設定では、両方を残すケースが多いです。ドメインが確認できる間は GeoSite が先に判定し、GeoIP は IP への直接接続、ドメイン情報がない接続、ドメインルールでカバーされない接続を補完します。CDN ノードは地域ごとに異なる場合があるため、サービスのドメインが属する地域と宛先 IP の所在地は必ずしも一致しません。サービス単位で安定して振り分けるには、明確なドメインルールや GeoSite 分類を先に置き、残りを GeoIP に処理させてください。

TUN と Fake-IP モードでの判定位置

TUN モードはより多くのシステム通信を取り込むためのもので、ルールデータベースの精度を自動的に高めるものではありません。Fake-IP DNS を有効にすると、クライアントはアプリに内部マッピング用アドレスを返し、カーネルは元のドメインを復元してドメインルールを適用しようとします。実際の接続が確立される段階では、宛先 IP が取得されることもあります。アプリが固定 IP に直接接続する場合、独自の名前解決を使う場合、または復元可能なドメイン情報がない場合は、GeoSite が使われない可能性があります。その場合は IP ルールと最終フォールバックがより重要になります。

TUN を有効にしてルールの挙動が変わっても、すぐにデータベースの破損と判断しないでください。まず通常のシステムプロキシと TUN で、その接続にドメイン情報が残っているか比較します。次に DNS モード、スニッフィング設定、Fake-IP の除外項目、ルール順を確認してください。データベースが提供するのは照合データであり、接続コンテキストはカーネルの取り込み方式によって決まります。

MAINTENANCE / 更新方針

問題が起きても戻せる更新方法を選ぶ

更新方法は大きく、クライアント管理、カーネルの自動更新、手動置換の 3 種類に分けられます。通常はクライアントやカーネルに用意された更新入口を優先してください。データディレクトリ、ファイル名、再読み込みの手順を把握していることが多いためです。手動ダウンロードは、特定バージョンの固定、社内ネットワークでの配布、更新障害の切り分けに向いていますが、置き換える前にファイル形式が現在のカーネルと互換性を持つことを確認してください。

クライアント管理による更新

一部のデスクトップ・モバイルクライアントでは、設定画面から GeoIP、GeoSite、ルールデータを更新できます。実行するとクライアントがファイルを取得して自身の実行ディレクトリに配置します。実装によってはカーネルを自動再起動しますが、次回の設定読み込みまで反映されない場合もあります。操作後は更新結果、ファイルの日付、カーネルログを確認し、ボタンの状態だけで成功と判断しないでください。

Mihomo カーネルの自動更新

Geo データの自動更新に対応した Mihomo では、設定から更新の有効・無効と更新間隔を制御できます。バージョンによってフィールド、データ形式、既定の URL の扱いが変わることがあるため、現在のカーネルのドキュメントとクライアントが生成した設定を基準にしてください。一般的な設定構造は次のとおりです。

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

geo-update-interval は通常、時間単位で指定します。一般的な利用なら 24 時間で十分で、更新間隔を数分まで短くする必要はありません。Geo データはリアルタイムのルーティングテーブルではないため、頻繁な取得は起動失敗、ネットワークタイムアウト、ファイル書き込みの競合を招く可能性があります。安定性を重視する機器では、週 1 回、またはクライアントのメンテナンス時間に更新し、ログで結果を確認するとよいでしょう。

設定に geox-url もある場合、カーネルは指定された URL から GeoIP、GeoSite、MMDB データを取得します。データソースは、現在のカーネルが認識できる内容を提供していなければなりません。ウェブページの URL、圧縮ファイルの配布ページ、別形式のファイルを指定すると、リクエストが成功しても読み込み段階で失敗することがあります。サブスクリプション変換サービスが設定を生成する場合は、リモート更新によってローカルの自動更新フィールドが上書きされないかも確認してください。

データベースを手動で置き換える

データベースの読み込み中に上書きされないよう、クライアントでカーネルを停止します。
インストールパッケージの展開先やブラウザーのダウンロード先ではなく、クライアントが実際に使用しているデータディレクトリを探します。
現在使用できるファイルをバックアップし、カーネルのバージョンと元ファイルの更新日時を記録します。
形式が一致する新しいファイルを配置し、クライアントが要求するファイル名とアクセス権を維持します。
カーネルを再起動して設定を読み込み、ログに解析、ファイルオープン、権限に関するエラーがないか確認します。
具体的なドメインと IP でルールのマッチをテストし、「ファイルサイズが増えた」ことだけを更新成功の根拠にしません。

DIAGNOSTIC BUS / 切り分け手順

更新失敗・ルール未適用時の段階的な確認

切り分けでは、「ダウンロード失敗」「ファイル読み込み失敗」「ルールが参照されていない」「ルールはマッチしたがポリシー結果が想定外」を分けて考えます。画面上はいずれもウェブサイトが誤った経路を通るように見えますが、対処方法はまったく異なります。データ取得、カーネル読み込み、設定解析、ルールマッチ、ポリシー実行の 5 層に分けて確認するのがおすすめです。

第 1 層：データのダウンロードが完了しているか

ログでリクエストの状態、タイムアウト、DNS 解決、接続エラーを確認します。
更新通信自体がデータソースにアクセスできることを確認します。起動時点でプロキシがまだ確立されていない場合、ダウンロードは直接接続しか使えないことがあります。
システム時刻を確認します。時刻が大きくずれていると TLS 接続を確立できない場合があります。
ストレージ容量とディレクトリへの書き込み権限を確認します。モバイル端末では、OS がアプリデータを回収していないか、バックグラウンド通信を制限していないかにも注意してください。
クライアントがダウンロード結果を、別の設定インスタンスのデータディレクトリに書き込んでいないか確認します。

第 2 層：カーネルがファイルを正常に読み込んでいるか

ダウンロードの完了は、読み込み可能であることを意味しません。ログにデータベース形式の無効、存在しないラベル、ファイルオープン失敗、解析エラーなどが出ている場合は、まず以前使用できたデータファイルへ戻してください。よくある原因は、実体がエラーページだった、データ形式がカーネルと互換性がない、途中で切れた不完全なファイルが残った、ファイル名やディレクトリがクライアントの規定と一致しない、といったものです。

カーネルを変更してからエラーが出始めた場合は、クライアントが古いカーネル向けのデータ設定を残していないかも確認します。たとえば、MMDB と別の Geo データ読み込み方式を切り替えられるクライアントでは、カーネルだけ変更してモードを合わせないと、ファイルが存在するのに読み込まれないことがあります。

第 3 層：現在の設定が本当にデータベースを参照しているか

実際に動作している設定で GEOIP、GEOSITE、関連する RULE-SET を検索します。サブスクリプション画面に表示される元の YAML が、カーネルの最終読み込み設定と一致するとは限りません。クライアントがルール、スクリプト、ローカルパッチを統合・上書きすることがあるためです。まずクライアントが出力した実行設定を確認し、ルール名、ポリシーグループ名、インデントが正しいことを確認してください。

GeoSite の分類名は、現在のデータに存在していなければなりません。データソースを更新すると、分類が追加、分割、変更されることがあります。設定が存在しないラベルを参照すると、読み込み時にカーネルが直接エラーを出したり、ルールが期待どおりに機能しなかったりします。分類名はデータソースの説明に合わせ、表示文言から推測しないでください。

第 4 層：ルールがマッチする機会があるか

接続ログまたはクライアントの接続詳細を開き、対象ホスト、ルール種別、ルールの内容、最終ポリシーを確認します。MATCH にマッチしている場合、通常は前段の Geo ルールがマッチしなかったか、そもそも実行されていません。別の DOMAIN-SUFFIX、IP-CIDR、RULE-SET にマッチしているなら、データベースを交換し続けるのではなくルール順を調整します。

GeoIP のテストでは、宛先アドレスも確認してください。1 つのドメインが複数の IPv4・IPv6 アドレスを返し、地域、ネットワーク、時間によって変わることがあります。ブラウザーの既存接続、DNS キャッシュ、QUIC セッションによって、古いアドレスが使われ続ける場合もあります。設定を変更したら、対象アプリを再起動するか接続を切り直して、新しいアクセスをテストしてください。

第 5 層：マッチ後のポリシーが利用可能か

ルールのマッチが決めるのは、接続をどのポリシーへ渡すかだけです。ポリシーグループで利用できないノードを選択している、遅延テストが完了していない、直接接続のネットワーク自体が宛先へ到達できない、といった場合は、ルールが正しくマッチしていても接続に失敗します。ポリシーグループの選択状況、ノードの状態、DNS 結果、システムプロキシの取り込み範囲を確認し、障害を Geo データのせいにしないでください。

TEST POINT / 検証サイクル

ルールのマッチ記録で更新結果を検証する

確実な検証には、少なくとも設定の読み込み、代表的なドメイン、宛先 IP、フォールバック通信の 4 項目を含めます。まずカーネルの起動ログに Geo データのエラーがないことを確認し、次に対象分類に明確に属するドメインで GEOSITE にマッチするか確認します。その後、既知の IP で GEOIP の分類結果を確認し、最後に前述の分類に属さない接続をテストして、想定した MATCH または別のフォールバックルールに入ることを確かめます。

クライアントがルールテストや接続詳細に対応している場合は、「対象、マッチしたルール、ポリシーグループ、実際の出口」の 4 項目を記録してください。ウェブページが開けるだけでは、振り分けが正しいとは証明できません。直接接続でもプロキシでもアクセスできる場合があるためです。逆に、ページが開けないからといってルールの誤りとは限りません。ポリシーノード、DNS、IPv6、アプリのキャッシュも結果に影響します。

推奨される更新間隔

一般的な個人端末：週 1 回または月 1 回の確認で十分です。所属地域の明らかな変化があったときだけ手動更新します。
設定を頻繁に切り替える端末：クライアント管理の自動更新を使い、カーネルをアップグレードするたびにデータ読み込みログを確認します。
長期間稼働するルーター：安定した自動更新時間帯を設定し、直前まで使えたファイルを残します。更新と端末の再起動が同時にならないようにしてください。
ルールを固定した環境：検証済みのデータバージョンを固定し、計画メンテナンス時にまとめて更新します。分類変更による振り分けの揺らぎを抑えられます。

更新後の最小チェックリスト

現在のカーネルが、設定で使用している Geo ルール種別に対応している。
データファイルが、実際に動作しているインスタンスの読み込み対象ディレクトリにある。
起動ログに、ダウンロード、解析、権限、分類名に関するエラーがない。
実行設定に想定した GEOIP と GEOSITE のルールが含まれている。
ルール順に、すべての通信を先に処理してしまう広範な項目がない。
接続詳細に、想定したルールとポリシーがマッチしたと表示される。
変更後は接続を再確立し、古い DNS やセッションキャッシュによる判定への影響を避ける。

GeoIP と GeoSite の保守で重要なのは、更新頻度を最大化することではありません。データ形式、カーネルの機能、設定での参照、ルール順が一致していることが重要です。更新後に「ファイルを取得済み、カーネルが読み込み済み、ルールが参照済み、接続がマッチ済み、ポリシーが実行可能」という流れを順に確認すれば、多くの問題を明確な層まで切り分けられます。