1 症状と地理データの関係
Mihomo（Clash Meta）のルールエンジンは、接続の宛先 IP やドメインを材料にしてマッチングします。GEOIP 系のルールは「この IP はどの国・地域に属するか」をローカルに同梱された IP 地理情報データベースで引きます。GEOSITE や GEOSITE,category-xxx のような書き方は、ドメイン集合をGeosite 形式のリストから引きます。どちらもファイルが古いと、CDN の再配置や新しいサブネットの割り当てに追いつかず、見かけ上「ルールは書いたのに別のプロキシグループへ流れる」「国内向け直行のはずが海外判定になる」といった誤判定が起きます。
ストリーミングでリージョン表示だけがおかしい場合も、まずは地理データと、実際にマッチしたルール行（接続ログのヒット順）をセットで見るのが近道です。ルールセット全体の設計はACL4SSR／Rule Provider の記事で扱うレイヤーであり、本稿はデータファイルそのものの更新と検証に絞ります。
2 どのファイルが何のルールに効くか
実務でよく触るのは次の組み合わせです。GeoIP 向けには geoip.dat や Country.mmdb（および配布形態によっては geoip.metadb など）が使われます。Geosite 向けには geosite.dat が対応します。コアのバージョンとクライアントのパッジング方針によって「デフォルトのファイル名」「検索ディレクトリ」が微妙に異なるため、手元の実行ログに出るパスを一次情報として扱うのが安全です。
geodata モードのイメージ
設定で geodata-mode: true（またはクライアントが同等のモードを有効化）になっている場合、ルール評価は dat／mmdb 系を前提に最適化されることがあります。逆に従来の Country データのみを参照する構成も残っているため、「ファイルを置いたのに読まれていない」ときは、YAML 側のモード指定と実際に置いた拡張子が噛み合っているかを確認してください。
geoip.dat と geosite.dat）と、手動で落としてきたファイル名がずれていると無視されます。リネームして揃えるか、設定で明示パスを指定できる場合はそちらを使います。
3 入手元と整合性
コミュニティで広く使われているのは、MetaCubeX／mihomo エコシステム向けに整備されたルールデータ配布（例：meta-rules-dat のリリース資産）です。ここから geoip.dat と geosite.dat を同一リリースラインで揃えると、GEOIP と GEOSITE の前提が一致しやすく、トラブル時の切り分けもしやすくなります。別プロジェクトのリストを混ぜるとタグ名やカテゴリ定義が一致せず、「リストは新しいのにルールが想定と違う」ことがあります。
ブラウザで GitHub の Release ページを開き、最新の geoip.dat／geosite.dat（必要なら Country.mmdb）を取得する方法がもっとも追いやすいです。企業ネットワークではダウンロードがブロックされることがあるため、その場合は別端末で取得して持ち込むか、社内ポリシーに沿ったミラーを用意してください。チェックサムの確認まで行える環境なら、ファイル破損による「一部ルールだけ壊れる」系の事故を防げます。
なお、ルールの更新頻度と地理データの更新頻度は別物です。購読の Rule Provider だけ最新でも、Geosite が古ければドメイン集合がズレます。逆に Geosite は新しくても、IP 側が古ければ GEOIP 行が誤爆します。定期メンテナンスでは両方を同じサイクルで見ると運用が楽です。
4 配置パス（OS・GUI 別の探し方）
配置先は「コアのカレントディレクトリ」「ホーム配下の設定ディレクトリ」「GUI が指定するルール／データディレクトリ」のいずれかに集約されることが多いです。Windows ではユーザープロファイル配下の .config\mihomo や、Clash 系 GUI が作る profiles 近傍、macOS／Linux では ~/.config/mihomo や ~/.local/share 系に置かれる例がよく報告されます。どれが正しいかは実際に動いているプロセスの作業ディレクトリと、起動時ログで確定するのが確実です。
サーバ常駐で systemd を使う場合は、Linux 向け Mihomo＋systemd の記事で述べているとおり、ユニットファイルの WorkingDirectory とデータ配置を揃えないと、見かけ上は設定が正しくても別の場所の古いファイルを読む、という状況が起き得ます。GUI 利用者は「設定ディレクトリをエクスプローラー／Finder で開く」メニューがあれば、そこからたどるのが早いです。
複数プロファイルがあるとき
プロファイルごとにデータディレクトリが分かれているクライアントでは、いまアクティブなプロファイル側に置き換えファイルを入れてください。別プロファイル用フォルダにだけ新しい geosite.dat があり、日々使う側が古いまま、というミスは意外と起きます。
5 差し替えと再起動の手順
安全な手順は次のとおりです。（1）コアまたは GUI のプロキシ機能を止める、もしくはメンテナンスウィンドウを取る。（2）既存の geoip.dat／geosite.dat／Country.mmdb を、日付入りの名前でバックアップコピー。（3）新ファイルを上書きコピーし、読み取り権限が実行ユーザーに渡っていることを確認。（4）コアを再起動するか、クライアントの「コア再起動」「設定リロード」で読み直す。
Windows ではファイルがロックされて上書きできないことがあります。その場合は Clash 本体を終了してから差し替え、再度起動します。macOS ではアプリがデータディレクトリをサンドボックス内に持つ場合があるため、GUI の「データフォルダを表示」から辿ると安全です。
# Example: backup geo files before replace (adjust paths to your install)
cp geoip.dat "geoip.dat.bak.$(date +%Y%m%d)"
cp geosite.dat "geosite.dat.bak.$(date +%Y%m%d)"geoip だけ新しくして geosite を古いままにする、といった運用は一時しのぎにはなりますが、症状が「ドメイン集合」と「IP 集合」のどちら由来かによっては片方だけでは再現が残ります。可能なら同一ソースラインで揃えてください。
6 反映確認とログの見方
再起動後は、まずログレベルを上げたうえで、問題のドメイン／IP に対する接続を一度発生させます。期待するルール行（例：GEOIP,JP や特定の GEOSITE カテゴリ）がヒットしているか、より手前の広いルールに吸われていないかを確認します。ここで別の行に落ちているなら、地理データ以前にルール順序やセレクタの手動選択を疑ってください。
IP の国判定だけを素早く見たい場合は、公開されている「自分の出口 IP と国」を表示するサイトを用いて、実際の出口が意図したノードかを確認します。ただしブラウザのキャッシュや別プロセスの直結接続が混ざると混乱するため、検証専用のプロファイルに絞ると再現性が上がります。
外部コントローラ（Web パネル）を使っている場合は、外部コントローラと Yacd の記事で触れているとおり、接続一覧からリアルタイムに経路を追いやすくなります。地理データ更新の効果は「同じテストを更新前後で比較」すると判断が早いです。
7 地理庫だけでは直らない場合
データを最新にしても症状が残るときは、典型的には次のどれかです。第一に、HTTPS でドメイン名がルール評価段階で見えていないケースです。TUN や FakeIP と組み合わせた環境では、Sniffer による SNI 復元が DOMAIN／GEOSITE 系の精度に効きます。第二に、DNS の答えがコアの期待とズレているケースです。DoH・FakeIP の実務記事で述べているように、fake-ip-filter やハイジャック範囲を見直すと、見かけの「ルール不成立」が解けることがあります。
第三に、ルールの順序です。広い MATCH や粗い GEOIP が、細かい例外より上にあると、データを更新しても挙動は変わりません。第四に、プロセスがシステムプロキシを無視している／TUN の対象外である場合で、これは地理データとは無関係に別ノードや直結に逃げます。
- Geosite は新しいのにドメインだけズレる： ルール集合にそのサフィックスが含まれているか、Sniffer オフで SNI が見えていないかを確認。
- GEOIP だけおかしい： mmdb／dat の置き場所とファイル名、
geodata-modeの整合を再確認。 - 更新直後だけ不安定： ファイル破損やダウンロード途中の切れを疑い、ハッシュやサイズで再取得。
8 まとめ
Clash Meta（Mihomo）で国・地域ベースの分流が急に壊れたように見えるとき、ローカルの geoip.dat／Country.mmdb 系とgeosite.datの鮮度は第一候補です。信頼できる配布元からセットで取得し、実際にコアが読むディレクトリへ上書きし、再起動またはコアの再読み込みで反映させます。検証は接続ログのルールヒットを軸に、更新前後で同じテストを繰り返すのが確実です。
それでも直らない場合は、地理データ以前にTLS でドメインが見えない問題やDNS の経路、ルールの順序が絡んでいることが多いです。総じて、Mihomo はルール・DNS・地理データ・嗅探を一体で扱えるため、単機能ツールより複合的なトラブルに強い反面、切り分けの軸を持っておくことが安定運用の鍵になります。
ビルドの入手とインストール手順はダウンロードページから自環境に合うものを選べます。GUI でデータフォルダを開けるクライアントであれば、本稿の手順を画面操作だけで完結させやすく、YAML を直接編集しない日々のメンテにも向きます。
