GeoIP・GeoSite・ルールセットの違い
mihomoのルール振り分けでは、ルールが照合順序を決め、データベースが照合に必要な分類情報を提供します。データベースを更新してもルールの順序は変わらず、サブスクリプションのプロキシノードも置き換わりません。特定のサイトが想定と異なるプロキシグループを通る場合は、現在の設定、データベースの内容、接続に実際に適用されたルールをそれぞれ確認してください。
| ファイル | データの内容 | 使用条件 |
|---|---|---|
geoip.dat | 国やカテゴリ別に整理されたIPアドレス範囲 | geodata-mode: trueの場合にGEOIPで使用 |
Country.mmdb | MMDB形式のIPアドレス位置情報 | geodata-mode: falseの場合にGEOIPで使用 |
geosite.dat | ドメインおよびサイトのカテゴリ一覧 | GEOSITEルールや関連するドメイン照合機能で使用 |
geodata-modeで選択するのはGEOIPのデータバックエンドです。無効にしてもGEOSITEが使えなくなるわけではありません。GeoSiteは接続に含まれるドメイン、またはコアが取得したドメインを照合し、GeoIPは接続先IPアドレスを照合します。ドメインの分類からサーバーの物理的な所在地は判断できず、IPアドレスの所在地情報だけで特定サービスを直接接続にすべきかどうかも決まりません。
rule-providersは別の仕組みです。通常はRULE-SETから参照し、YAML、テキスト、MRSなどのルールセットファイルを使います。更新設定も独立しています。geosite.datだけを更新しても、すべてのルールプロバイダーが更新されるわけではありません。
コア、データの入手先、作業ディレクトリを確認する
この記事の設定例はmihomoを対象としています。旧Clashクライアントでは異なるコアが使われている場合があるため、画面上の名称だけで互換性を判断しないでください。まずクライアントのコア情報または起動ログでmihomoが動作していることを確認します。コマンドラインで導入している場合は、以下のコマンドで実際のバージョンを確認してから設定を確認してください。
mihomo -v
mihomo -h
ルールのカテゴリ名に合ったデータソースを選ぶ
主な入手先には、MetaCubeXのmeta-rules-datリリース成果物や、Loyalsoldier関連のルールデータプロジェクトがあります。プロジェクトによって上流データ、収録範囲、カテゴリ名が異なる場合があります。同じファイル名でも、cn、github、広告カテゴリが同じように収録されているとは限りません。
- データプロジェクトのリリースページで成果物の形式を確認し、実際のダウンロードURLをコピーしてください。WebページのURLをデータベースファイルとして保存しないでください。
- GeoIPのDATファイルとMMDBファイルは、拡張子を変更しても相互に変換できません。
- 軽量版はストレージや読み込みの負荷を抑えられますが、既存のルールで使うカテゴリが含まれない場合があります。
- まず正常に動作している設定とデータをバックアップしてから、データソースを切り替えてください。複数の要因を同時に変更しないようにします。
コアが実際に読み込む場所を特定する
コアを直接起動する場合、-dで作業ディレクトリ、-fで設定ファイルを指定します。Clashクライアントから起動する場合は、コアの起動ログまたはクライアントのデータディレクトリへの案内を確認してください。クライアントのインストール先、サブスクリプションの保存先、コアの実行ディレクトリは、それぞれ異なる場合があります。
mihomo -d /srv/mihomo -f /srv/mihomo/config.yaml
以下はLinuxのパスの例です。この構成では通常、/srv/mihomoでデータベースを管理します。WindowsとmacOSでは、ログに表示された実際のパスを使用してください。Linuxではファイル名の大文字・小文字が区別されるため、MMDBを手動で差し替える際はCountry.mmdbの綴りを特に確認してください。
geodataの自動更新を設定する
以下の例ではMetaCubeXが公開するデータベースを使用し、GEOIPのバックエンドにDATを指定します。各項目を設定ファイルのトップレベルに追加してください。dns、tun、プロキシグループの内部には配置しないでください。すでにgeox-urlがある場合はキーを重複させず、既存の項目を編集します。
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"
geo-auto-update: true:コアによる地理データベースの自動更新を有効にします。geo-update-interval: 24:更新間隔は24時間です。24秒ではありません。geox-url.geoip:DAT形式のGEOIPデータソースです。geox-url.geosite:GeoSiteデータソースです。geox-url.mmdb:MMDBデータソースです。MMDBバックエンドに切り替える場合に使用します。
設定にダウンロード先を指定しても、起動のたびにすべてのファイルが強制的に再ダウンロードされるわけではありません。実際の読み込みと更新状況は、使用中のコアのログで確認してください。保存後はまず設定を検証し、クライアントから再読み込みします。クライアント独自の地理データベース管理機能がある場合は、それによってこれらの項目が上書きされないかも確認してください。
初回起動時にデータベースがない場合、ルールの読み込みを完了するため、コアが先にデータをダウンロードすることがあります。その際、ダウンロードに必要なネットワークが起動前のプロキシに依存していると、起動時に依存関係が発生します。利用可能なネットワークで先にローカルファイルを用意し、起動後に自動更新が機能することを確認してください。
GeoIP・GeoSiteファイルを手動で差し替える
ダウンロードに制限がある場合、端末のストレージが少ない場合、またはデータベースを以前の状態に戻したい場合は、手動更新のほうが管理しやすくなります。使用中のファイルに直接書き込み続けたり、ファイル名だけでダウンロードの成功を判断したりしないでください。
- 実行パラメーターを記録する。コアのバージョン、作業ディレクトリ、設定ファイルのパス、現在の
geodata-modeの値を確認します。 - 既存ファイルをバックアップする。現在使用できている
geoip.dat、geosite.dat、またはCountry.mmdbをバックアップ先にコピーします。 - 一時ディレクトリにダウンロードする。HTTPダウンロードが成功したことと、ファイルサイズが妥当であることを確認します。ログインページやエラーページが保存されていた場合は、正しい成果物を再取得してください。
- コアを停止してから差し替える。クライアントのコアを終了するか、該当するサービスを停止してから、新しいファイルを実際の作業ディレクトリに配置します。元のファイル名と適切な読み取り権限を維持してください。
- テストして再起動する。同じ作業ディレクトリを使って設定を検証し、起動後にデータベースの読み込みログと新しい接続のマッチ結果を確認します。
mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml
-tは設定のテストに使うオプションで、実際のWebサイトへのアクセス確認ではありません。テストに必要なデータがない場合、ダウンロードが実行されたりエラーになったりすることもあります。Linuxでサービスとして運用する場合は、テストを実行するユーザーとサービス実行ユーザーのディレクトリ権限が同じかどうかも確認してください。
ファイルを差し替えても、稼働中のコアがすぐに再読み込みするとは限りません。停止してから差し替え、再起動するのが確実な手順です。新しいデータでカテゴリが見つからない、または読み込みに失敗する場合は、バックアップしたファイルと元の設定に戻して起動を確認してください。原因を調べる前に、コア、サブスクリプション、データベースを同時に変更しないでください。
GEOIP・GEOSITEルールの書き方
以下の例では、設定にPROXYという名前のプロキシグループがすでにあるものとします。DIRECTは組み込みの直接接続ポリシーです。実際のプロキシグループ名が「ノード選択」の場合は、例のPROXYをその名前に置き換えてください。ポリシー名は設定と一致させる必要があります。
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- GEOSITE,github,PROXY
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,PROXY
上から順に評価し、最初に一致したルールを適用
DOMAIN-SUFFIXで特定のドメインを例外指定します。GEOSITE,github,PROXYはデータベース内のGitHubカテゴリに一致します。GEOSITE,cn,DIRECTはデータソースで定義されたcnドメイン群に一致します。GEOIP,CN,DIRECT,no-resolveで接続先IPを確認し、最後にMATCHで残りの接続を処理します。
MATCHを先頭に置くと、後続のルールは照合されません。対象範囲の広いカテゴリを個別の例外より前に置いた場合も、例外が適用されないことがあります。通常、ドメインルールはIPで判定するルールより前に置きますが、具体的な順序は用途に合わせてください。
no-resolveは名前解決の動作を制御する設定で、IP照合を省略するものではありません
no-resolveは、このIPルールの照合だけを目的として接続先ドメインを新たに名前解決しない設定です。接続に利用可能な接続先IPがすでに含まれていれば、GEOIPによる照合は引き続き行われます。グローバルDNSを無効にする設定でも、DNS漏えいを防ぐ単独のスイッチでもありません。
たとえば、まだ名前解決されていないドメインが前のGEOSITEルールに一致せず、no-resolve付きのGEOIPルールに到達した場合、そのまま後続のルールへ進むことがあります。そのドメインを常に直接接続にしたい場合は、no-resolveを単に外すよりも、正確なドメインルールを追加するほうが制御しやすくなります。
更新後も反映されない場合の確認手順
| 症状 | 優先して確認する項目 | 対処方法 |
|---|---|---|
| ダウンロードがタイムアウトする | DNS、TLS、ダウンロード先ドメインへの接続 | まずダウンロード経路を復旧し、必要に応じてファイルを手動で用意する |
| ファイルを解析できない | ファイル形式、ダウンロード内容、転送の完了状況 | 対応するDATまたはMMDBの成果物を再取得する |
| ルールで指定したカテゴリが見つからない | データソースと軽量版の収録範囲 | 該当カテゴリを含むデータを選ぶか、カテゴリルールを変更する |
| ファイルは更新されたが振り分けが変わらない | 作業ディレクトリ、バックエンドの選択、ルールの順序 | コアが実際に読み込んだファイルと、一致したルールを確認する |
| サブスクリプション更新後に設定が元に戻る | 最終的に適用される設定 | ローカル設定を永続的な上書き機能に移行する |
ページの再読み込みだけでなく、新しい接続で検証する
まずルールモードになっていることを確認し、クライアントの接続ログを開いて、接続先ドメイン、接続先IP、適用されたルール、ポリシーチェーンを確認します。グローバルモードでは、最終的なプロキシ出口だけを見てGEOIPやGEOSITEによる振り分けが想定どおり動作したか判断できません。
ブラウザーは既存のHTTP/2接続やQUIC接続を再利用することがあります。ルールやデータを変更した後は古い接続を閉じ、新しいリクエストを送信してください。同じタブを再読み込みしても、新しい接続が確立されるとは限りません。検証時は、直接接続するドメイン、プロキシ経由にするドメイン、既知のIPアドレス宛ての接続をそれぞれ少なくとも1件記録してください。
DNSの問題とデータベースの問題を切り分ける
CDN、DNSキャッシュ、利用するリゾルバーによって、同じドメインでも異なるIPアドレスが返されることがあります。そのため、GEOIPの結果が変わっても、データ更新の失敗とは限りません。TUNまたはfake-ipを使う場合は、コアが認識したドメインと実際の接続先情報も確認してください。アプリに表示される合成アドレスを、インターネット上のIPアドレスの所在地として扱わないでください。
安定したメンテナンスの手順は、まず使用中のファイルとコアを確認し、次にルールのカテゴリを検証し、最後に実際の接続を確認することです。データベースの更新で変わるのは分類の基準です。DNS、ルールの順序、プロキシグループの選択は、それぞれ別に設定する必要があります。基礎知識は用語集、導入手順は全プラットフォームガイドをご覧ください。