一、GeoIP と GeoSite はそれぞれ何を管理しているか
分流ルールを、通信を振り分ける仕分け作業だと考えてみましょう。接続が発生すると、内核（コア）は2つの問いに答える必要があります——この宛先 IP はどの国・地域に属するか？この宛先ドメインはどのカテゴリのサイトに属するか？前者を調べるのが GeoIP データベース、後者を調べるのが GeoSite データベースです。2つのファイルはそれぞれ役割が異なり、互換性はありません。どちらか一方が欠けていると、対応するルールは答えを見つけられなくなります。
GeoIP：IP から国・地域への対照表
GeoIP データベースには、IP アドレス範囲と国・地域コードの対応関係が格納されています。ルールに GEOIP,CN,DIRECT と書くと、内核は接続先の IP を取得したうえでデータベースを検索し、CN の範囲に該当すれば直接接続します。mihomo（Clash Meta）内核はデフォルトで country.mmdb を読み込み、初回起動時に専用キャッシュ geoip.metadb を生成します。geodata-mode を true に設定すると、GEOIP ルールは v2ray 形式の geoip.dat を読み込むように切り替わります。加えて、オプションの ASN データベース GeoLite2-ASN.mmdb もあり、IP-ASN ルールで自律システム番号（ASN）ベースの分流が可能です。これらの用語は用語解説ページにも記載があるので、迷ったときはそちらも参照してください。
GeoSite：ドメインからサイトカテゴリへの対照表
GeoSite データベースはコミュニティ主導の domain-list-community プロジェクトが元になっています。メンテナーが大量のドメインをサービス・提供元・地域別に整理してカテゴリ一覧にまとめ、それをコンパイルして geosite.dat として配布しています。ルールに GEOSITE,google と書くと、内核は宛先ドメインを google カテゴリ内の項目と1件ずつ照合します。カテゴリには属性による絞り込みも可能で、例えば google@cn は google カテゴリの中でも中国大陸向け属性が付いた項目だけにマッチし、カテゴリ全体より細かい粒度で制御できます。
| 比較項目 | GeoIP | GeoSite |
|---|---|---|
| デフォルトファイル | country.mmdb / geoip.metadb | geosite.dat |
| 解決する問い | この IP はどの国・地域に属するか | このドメインはどのカテゴリのサイトか |
| 対応するルール | GEOIP,CN,DIRECT | GEOSITE,cn,DIRECT |
| データ内容 | IP 範囲と国コードの対応 | ドメインとカテゴリタグの対応 |
| 主な配布元 | meta-rules-dat リポジトリ | meta-rules-dat リポジトリ |
二、なぜこの2つのデータベースを定期的に更新すべきか
どちらのデータベースも常に変化し続けるデータです。クラウド事業者は毎月のように増設を行い、IP 範囲は地域間で再割り当てされます。新しいサービスが登場したり既存ドメインの管理元が変わったりすれば、サイトのカテゴリ分類も変化します。データベースが半年前のまま更新されていないと、分流の判定も半年前の状況に基づいて動いてしまい、代表的なトラブルとして次の3つが起こります。
- 直接接続すべき通信がプロキシ経由になる：新しく CN に割り当てられた IP 範囲が古いデータベースに反映されておらず、フォールバックルールでプロキシに送られてしまい、本来なら直接アクセスできる中国国内サイトに余計な迂回が発生します。
- プロキシ経由にすべき通信が直接接続になる：新しく登場した海外サービスのドメインがまだ geosite のカテゴリに含まれておらず、GEOIP やフォールバックルールで直接接続扱いになった結果、アクセスできない、または不安定になる現象が起こります。
- ルールのマッチ率が下がる：カテゴリの項目が変更されると、これまで使っていたカテゴリ名が分割・改名されている場合があり、既存のルールが機能しなくなります。
一般的な利用頻度であれば1〜4週間に1回の更新で十分です。新しく登場したサービスをすぐに識別したいなど、即時性を重視する場合は自動更新の間隔を24時間まで短縮しても構いません。デメリットは、数MB程度のファイルを毎日追加でダウンロードすることになる点だけです。
三、データベースを更新する3つの方法
方法1：クライアントの画面上のボタンから更新（最も手軽）
GUI クライアントには更新用のボタンが用意されています。Clash Verge Rev を例にすると、設定画面に GeoIP・GeoSite などの外部リソース項目があり、更新ボタンをクリックするだけで最新ファイルを取得できます。FlClash など他のクライアントにも同様のリソース更新機能があります。更新が完了したら、設定を再読み込みするか内核を再起動して、新しいデータベースを実際に反映させましょう。この方法は誰にとっても手軽な選択肢です。仕組みを先に押さえておくと、このボタンが裏側で行っているのは、方法3で紹介する手動ダウンロード・置き換えとまったく同じ処理だと分かります。
方法2：設定ファイルで自動更新を有効化
mihomo 内核には自動更新のスイッチが標準で備わっています。config.yaml のトップレベルに以下を記述してください。
# Geo データベースの自動更新
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"
asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"注意点は3つ。geo-update-interval の単位は「時間」であり「秒」ではありません。geox-url の4つのキーはそれぞれ geoip.dat、geosite.dat、country.mmdb、ASN データベースに対応しており、使わないキーは省略しても構いません。GitHub への直接接続が不安定な環境では、アドレスをアクセス可能なミラーに変更すれば、ファイル内容自体は同じものが取得できます。
方法3：ファイルを手動でダウンロードして置き換え（最も確実にコントロールできる）
GUI からの更新が失敗する場合や、ファイルのバージョンを厳密に管理したい場合は、手動での置き換えが最も確実です。
- 配布元を開くブラウザで meta-rules-dat リポジトリの Release ページを開き、geoip.dat、geosite.dat、country.mmdb、GeoLite2-ASN.mmdb の4つのファイルを探します。
- ローカルにダウンロードそれぞれクリックしてダウンロードします。コマンドライン環境では curl で1ファイルずつ取得することも可能です。
- 設定ディレクトリを確認mihomo の設定ディレクトリは config.yaml と同じ階層にあります。Clash Verge Rev では設定画面から設定ディレクトリを直接開くこともできます。
- 置き換えて再起動新しいファイルで既存のファイルを上書きし、内核を再起動するか設定を再読み込みして、内核にデータベースを再読み込みさせます。
curl -L -o geosite.dat https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat置き換え前に内核を停止する
環境によってはファイルが使用中になっていると上書きに失敗することがあります。置き換える前に内核を終了または一時停止し、置き換え後は実行ログを確認して geo ファイルの読み込み行にエラーが出ていないことをチェックしてから作業を終えましょう。
四、分流ルールで geoip と geosite を参照する
データベースが準備できたら、いよいよルールから参照できるようになります。典型的な分流ルールの終盤部分は次のようになります。
rules:
- GEOSITE,category-ads-all,REJECT # 広告ドメインはブロック
- GEOSITE,google,ノード選択 # Google 系サービスはプロキシ経由
- GEOSITE,cn,DIRECT # 中国国内サイトは直接接続
- GEOIP,CN,DIRECT,no-resolve # 宛先 IP が中国国内なら直接接続
- MATCH,ノード選択 # その他はすべてプロキシ経由処理される順番を見てみましょう。接続が発生すると、まずドメインのカテゴリが照合され、GEOSITE の3行でドメインベースで判定できるものはすべて処理されます。次に GEOIP に到達すると、宛先が IP であればそのままデータベースを検索し、ドメインであれば no-resolve の指定次第で挙動が変わります。no-resolve を付けない場合、内核は先に DNS 解決を行ってからデータベースを検索するため判定の網羅性は高くなりますが、解決処理が1回余分に発生します。no-resolve を付けると IP 形式の接続にのみ適用され、解決処理を省ける代わりに、ドメイン形式の接続はこのルールをすり抜けてしまいます。上の例では GEOSITE,cn を先に置いて中国国内ドメインを先に処理しているため、GEOIP に no-resolve を付けても中国国内ドメインの通信を取り逃す心配はありません。
よく使う geosite カテゴリ一覧：
| カテゴリ名 | 内容 |
|---|---|
| category-ads-all | 広告・トラッキング系ドメイン集 |
| cn | 中国大陸のサイトドメイン |
| geolocation-!cn | 中国大陸以外のサイト |
| google / youtube | Google 系サービスと YouTube |
| telegram | Telegram 関連の全ドメイン |
| github | GitHub 本体と関連リソースのドメイン |
| apple / microsoft | Apple と Microsoft のサービスドメイン |
| gfw | アクセス制限されやすいサイト集 |
記述する際の注意点は2つ。カテゴリ名は必ず公式リストどおりの小文字表記で書くこと。誤って書いてもエラーにはならず、単にマッチしないだけなので気付きにくい点に注意してください。より細かい粒度で制御したい場合は @ 属性を使います。例えば GEOSITE,google@cn,DIRECT は Google のうち中国国内からアクセス可能なドメインだけを直接接続にでき、GEOSITE,geolocation-!cn,ノード選択 は「中国大陸以外のサイトはすべてプロキシ経由」とほぼ同義になります。
五、更新と参照に関するよくある質問
更新ボタンを押しても失敗する
9割はダウンロード元にアクセスできないことが原因です。ネットワーク環境によっては GitHub の Release に直接アクセスしづらい場合があるので、geox-url をミラーアドレスに変更するか、クライアント自体を一度プロキシ経由にしてから更新ボタンを押してみてください。方法3の手動置き換えで、クライアントのダウンロード処理自体を回避するのも有効です。
ルールを書いたのに反映されない
次の3点を順に確認してください。1つ目はルールの順序です。GEOSITE や GEOIP よりも前に、範囲の広いルール（先頭付近の MATCH や大きな IP-CIDR 指定など）が置かれていて先に処理されてしまっていないか確認します。2つ目は再読み込みの有無です。設定を変更した後は必ず再読み込みまたは内核の再起動を行わないと、新しいデータベースは反映されません。3つ目はカテゴリ名のスペルです。誤字があってもエラーは出ず、静かにマッチしなくなるだけなので見落としやすい点です。
低メモリのデバイスで読み込みが重い
ルーターなどの低スペック機器では、geodata-loader を memconservative に設定すると、読み込み速度を犠牲にしてメモリ使用量を抑えられます。通常の PC ではデフォルトの standard のままで問題ありません。
更新頻度は geo-auto-update に任せ、分流の判定は順序の整ったルールに任せておけば、この2つのデータベースは長期的に手をかけずとも安定して機能してくれます。分流ルール全体の骨組みがまだ整っていない場合は、まず使い方ガイドで基礎を固めてから、この上級者向け設定に戻ってくることをおすすめします。順序を逆にしないよう注意してください。