Clash Meta で GEOIP／Country 分流が逆？MMDB の場所とルールを順に直す
「国内向けドメインは直結、海外はプロキシ」と書いたのに、実際は国内サイトが代理経由になり、逆に海外が直に出てしまう——よくある原因のひとつが、地理 IP 判定に使うオフライン DB（MMDB や geodata）が想定と違う場所を読んでいる・古い・あるいはルールより先に別行が当たっていることです。DNS や rule-providers とは別軸の国家庫まわりに絞り、Clash Meta（Mihomo） 前提で切り分け手順を整理します（利用規約・各サービスの利用条件を守ってください）。
GEOIP ルールは「今の接続先 IP」を DB で引く
GEOIP,CN,DIRECT のような行は、マッチ段階で見えている宛先 IP（多くの場合は最終的な接続先）を、ロード済みの国コードデータベースに照会します。ここで使われるのはドメインリスト（RULE-SET のドメイン系）ではなく、IP→国/地域の対応表です。MaxMind 形式の .mmdb、またはビルドと設定に応じた geoip.dat などが該当し、クライアントの作業ディレクトリ基準の相対パスとして解決されることが多いです。
- データが存在しない：古い内蔵デフォルト・空ファイル・展開失敗のまま、といった状態では判定が毎回ズレるか、想定外のフォールバックに寄ります。
- 国コードの記法：多くの場合 ISO 3166-1 alpha-2（例：
CN、JP、US）で、大文字で揃えます。スペルや小文字の違いで「当たらない」ことは起き得ます。
症状の見立て：まず「IP が本物か」から分ける
fake-ip モードでクライアントが仮想 IP（例：198.18.0.0/16 帯）を返している場合、GEOIP はその仮想アドレスを DB に引き、実在しない／予約帯として国が付かない・誤ることがあります。分流がおかしいと感じたら、DNS・fake-ip の記事で、いま扱っているのが本物のリモート IPか、あるいはスニッファで実ドメインに戻す必要があるかを先に確認してください。
rule-providers との違い
rule-providers は HTTP 等で落としてくるルール行の集まりです。一方 GEOIP はコア内の地理 DB ファイルに依存します。リモート規則の取得が成功していても、国判定用 DB だけが空・未更新、という二重構造に注意します。
手順 1：MMDB / geodata ファイルの実在とパス
設定 YAML または GUI の「国データのパス」に、Country.mmdb や geoip.dat などの相対・絶対パスが出てくる場合、それはしばしばプロファイル（ホーム）ディレクトリを基準に解決されます。次を確認します。
- コアのログ起動行付近に、geo ファイルの読み込み成功・失敗の記述がないか。
- エクスプローラー・Finder・コンテナ内シェルで、想定パスにファイルが存在し、サイズがゼロでないか（数 MB 以上あるのがざっくり目安。ビルドやソースにより異なります）。
- Docker では、ホストに置いた mmdb をボリュームでコンテナ内の設定パスにマウントしているか。Docker Compose 記事のマウント設計と併せて見てください。
相対 path の基準
./geo/Country.mmdb が「今開いている YAML の隣」ではなく、アプリのデータルートに展開されるケースは珍しくありません。二重起動・複数プロファイルでは、動いている方のディレクトリを必ず合わせます。
手順 2：geodata-mode と利用する形式
Clash Meta 系では、geodata-mode や geox-url、geo-auto-update など、ビルドとバージョンでキー名と既定値が変わります。要点は次の通りです。
- geodata / mmdb のどちらをメインにするか：設定でモードを切り替えると、期待しているファイル形式と実ファイルが食い違い、「読めているつもり」で別物を見ている、という状況が出ます。公式ドキュメントと自ビルドの Readmeを突き合わせます。
- geox-url からの自動取得：URL が 403・期限切れ・社内 TLS ブロックだと、更新が毎回失敗し極端に古い DB に留まることがあります。ブラウザや
curlで同 URL に届くか先に切り分けてください。
手順 3：GEOIP 行の書式と国コード
例として、中国本土向けに直結させたい場合は GEOIP,CN,DIRECT のように、国コードとポリシー名の対応を明確にします。日本在住者が「海外サイトだけプロキシ」にするなら、JP や LAN 相当の扱いを、購読テンプレや自作ルールの上の方に置く必要があることが多いです。逆に、GEOIP,CN,PROXY より前に、より広い DOMAIN-SUFFIX や IP-CIDR がマッチしていると、地理ルールに到達しません。
# Illustrative — policy group names and order must match your config
rules:
- IP-CIDR,192.168.0.0/16,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT
- DOMAIN-SUFFIX,service.example,DIRECT
- GEOIP,CN,DIRECT
- GEOIP,JP,DIRECT
- MATCH,PROXY
上図のように、先に来た行が勝つのが基本です。DOMAIN 系で既に PROXY に落としている国内 CDN のドレイン先があると、GEOIP,CN より上で消費され、結果として国内トラフィックがプロキシに乗る、という見え方になります。
手順 4：ルールの「縦の順序」と MATCH
国分流のおかしさの多くは、DB 以前にルール順で説明がつきます。チェックの順序は次が実務的です。
順序確認の手順
- ログで最終的にマッチした行（ルール名・出口）を確認する。
- その行より上に、同じ接続に効いているドメイン／IP ルールがないか見る。
GEOIPを、より具体的な国内／社内IP-CIDRの下に置きすぎていないか再配置するテストをする（一時的に上へ移す）。- 最下行の
MATCHが、意図せずPROXYやDIRECTへ一括流ししていないか確認する。
手順 5：DB の鮮度と手動差し替え
国境界の変更は頻繁ではありませんが、数年単位の放置は CDN の出口変更と組み合わさると症状が出ます。定期更新（クライアントの「地理データを更新」、または geox-url 経由の再取得、手動で mmdb を置き換え）のあと、必ず一行ログで再読み込みを確認してから、現象の再現を見ます。置き換え前にファイルの退避と、サイズゼロ・ダウンロード途中断片の削除に注意します。
手順 6：mixin や購読更新で上書きされないか
リモート購読を毎日マージする構成では、geodata 系の path が毎回テンプレに戻る、あるいは rules の順が購読側で固定化される、と Geo 関連だけ狂って見えます。mixin による上書きで path とルール末尾を一定に保つ、などの併用を検討してください。
Sniffer との接続
TLS ドメインを復元する Sniffer を有効にしている場合、override-destination の有無でマッチ材料が「IP 主体」か「ドメイン主体」に寄るため、GEOIP 以前に DOMAIN 系へ吸われる状況が変わります。HTTPS 手当ては Sniffer の記事を参照し、国分流だけ取り出して比較テストするのが早いです。
よくある質問
国内も海外も「なんとなく逆」
単一原因ではなく、DB 未読み込み＋上の行が PROXY 固定＋fake-ip 仮想アドレスの複合が多いです。ログでマッチ行と、DB ロード有無、DNS モードの三つに分解してください。
GEOIP,CN だけ入れたのに効かない
その前の RULE-SET や購読テンプレ付属の DOMAIN-KEYWORD が先に PROXY へ回している典型です。一時的に上をコメントアウトして挙動差を見ます。
ルータ（OpenWrt 等）でも同じ？
考え方は同じで、ルータ上の mmdb 配置・RAM 上の展開と、LuCI からの再読み込みがポイントです。全屋プロキシの記事群と併せて、ディスク実体のパスを必ず合わせます。
チェックリスト
- Geo 用 DB ファイルの存在・サイズ・更新時刻を実パスで確認する。
geodata-mode等の設定と、実ファイルの拡張子（mmdb/dat）の食い違いを潰す。- ルール先頭から、
GEOIP以前に奪っていく行をログで突き止める。 - fake-ip 下では仮想 IP を geo に載せすぎない；必要なら DNS ／ Sniffer 側を先に直す。
- 購読・mixin 更新で path や
rules順が毎回戻るかを確認する。
まずクライアントを揃える
地理 DB の扱いはコア任せですが、「データを再取得」が明示され、パスをエディタで直せるクライアントの方が再現性が高いです。