Mihomo で GeoIP／GeoSite ライブラリのパスを把握し手動更新・検証する（2026）

検索クエリになりやすいのは、「Clash Meta（Mihomo）で GEOIP と GEOSITE ルールが動くのに、その裏側の離線データを自分の場所で管理したい」「社内環境だけミラーを用意して自動取得させたい」「古いCountry mmdb のままルール評価がズレている気がするときに手で入れ替えたい」という三類型です。

本稿はルール順の是正ではなく、それ以前レイヤにある地理データ資産の読み込み経路と更新運用にだけ焦点を絞ります。Clash から Mihomo／Meta に移したあとの全体像がまだあいまいな方はそちらを先に、国内向け誤経路だけを直したい場合は並び順中心のGEOIP CN とルール優先順位の記事へ役割を分けてください。mihomo ルール庫更新という言い方は、自動ダウンロードとファイルを手で置換の両方をまとめた呼び方だと読み替えると、この記事との対応が取りやすくなります。

まず押さえる用語：geodata-mode と読み込まれる種別

Mihomo の一般設定にある geodata-mode は、大雑把に言えばGeoIP が MMDB とバイナリ dat のどちらを主に使う設計になるかを切り替えるスイッチです。公式ドキュメントの説明によれば、この値が true に近いときは dat 側の構成が想定され、false（既定側）では mmdb 系 Country ファイルの利用が説明されています。geodata-loader（standard / memconservative）はメモリを惜しむかどうかのバランスで、更新手順そのものよりもルーターや低メモリ端末で詰まったときのチューニング項目として覚えておけば十分です。

一方、GEOSITE 型のルールやルールプロバイダが参照するドメイン束は、多くのテンプレートが geosite.dat のような配布物を前提にしています。GeoSite データベース パスという言葉自体はユーザー向けYAMLにすべてが一行で現れるわけではなく、ダウンロード先URLと実際に展開されたファイル位置の二段構えで理解するのが現場では早いです。

注意：ビルドやクライアントのラッパーによって「作業ディレクトリ」が異なります。Windows のポータブル配置、macOS のアプリバンドル、Linux の ~/.config 配下など、今のプロセスがどのフォルダをホームとみなしているかを一度GUIまたはドキュメントで確定させてからファイルを置きます。

YAMLで触る主なキー：geox-url と自動更新まわり

多くの公開サンプルで示されるgeox-urlは、自動取得や初回フェッチ時に使う取得元URLの束です。Typicalには geoip / geosite / mmdb / asn の各キーがあり、それぞれHTTPSの配布エンドポイントを指します。社内プロキシの外に出せない端末では、これを社内サーバーのミラーURLへ差し替え、初回のみ手で同期する、というパターンがよくあります。

geo-auto-update を false にしておけば、起動ごとにサイレントで上書きされるリスクを下げ、オフライン mmdb をUSBで運び込む運用とも相性がよくなります。逆に常に最新の community rules-dat を追いかけたいなら true にし、geo-update-interval（時間単位）で頻度を抑えます。ここを誤解すると「さきほど手で入れたはずのファイルが、数時間後に別物に変わっている」という現象の原因になります。

YAML# Example — adjust URLs and booleans for your deployment
geodata-mode: false
geo-auto-update: true
geo-update-interval: 48
geox-url:
  geoip: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat"
  geosite: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat"
  mmdb: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb"
  asn: "https://github.com/xishang0128/geoip/releases/download/latest/GeoLite2-ASN.mmdb"

上記は一例です。利用ライセンスや配布元のポリシーは各自で確認してください。ミラーの可用性やTLS検証環境により取得に失敗する場合はログにエラーとして残るため、そのときはgeo-auto-update を切ってローカル配置に絞るほうが切り分けが早いこともあります。

RULE-SET や rule-providers が別ホストにある構成は、このGeoセクションとは独立に更新されます。購読型ルールの取り込み側の別記と混同しないよう、更新対象のアイコンイメージを分けておくと運用見直しが楽です。

手順：オフライン差し替えから検証まで

以下は現場でそのまま読める番号付きの作業順です。クライアントの画面名称は製品ごとに違うため、「設定」や「内核日志」などのラベルは近いものに読み替えてください。

  1. いま動いている設定をバックアップし、YAMLで geodata-mode の真偽を確認します。true に寄せているなら dat 系が主役、false なら mmdb（country） を意識してください。
  2. 運用ポリシーを決めます。完全手動なら geo-auto-update: false を推奨し、更新忘れによる陳腐化と、自動フェッチによる上書きのどちらのリスクを取るかをメモしておきます。
  3. 使用クライアントのデータディレクトリを開き、既存の country.mmdb や geoip.dat、geosite.dat など実ファイル名を列挙します。サイズゼロや極端に古い更新日時があれば、一度正常端末と比較すると安全です。
  4. 信頼できる配布物を取得し、置換は必ずコアを止めてから行います。Windows ではプロセスがファイルハンドルを掴んでいると上書きに失敗します。置換後に属性が読み取り専用になっていないかも確認します。
  5. ミラーを自前で持つ場合は geox-url の各URLをそのミラーへ合わせ、必要なら社内CAを信頼ストアへ入れるなどTLSまわりを整えます。
  6. コアを起動し、ログレベルを一時的に debug 付近へ上げて、Geoデータのロード失敗がないかを見ます。失敗時はパス解決ミスかファイル形式の不一致が大半です。
  7. ルール評価の実測として、衆知のGEOIP行（例：GEOIP,JP,DIRECT など自分のセットに適したもの）に簡単に当てるMATCH締めのテスト構成を用意し、問題ドメインを流したときの想定グループへの着地を確認します。DNS と絡むなら名前解決の出口も同時に見ます。
  8. 問題が収束したらログレベルを戻し、手順とファイルのハッシュまたは更新日をメモしておきます。次回監査や他端末複製時に再利用できます。

ワンポイント：geodata-mode を切り替えた直後に「ルールが急に壊れた」ように見えるのは、期待している拡張子と実ファイルの中身が噛み合っていない典型パターンです。切り替えとファイル群の更新は同一メンテナンス枠でまとめて実施してください。

自己検証：新しい庫が効いているかを疑うべきサイン

静的ファイルの更新は成功しても、挙動が変わらないように見えることがあります。そのとき疑うべきは、(1) 別の作業ディレクトリを別プロセスが参照している、(2) GUIが生成した一時合成YAMLと手で触っているファイルが別物、(3) fake-ip や Sniffer などレイヤが違う問題に見えている、の三つです。(3) についてはSniffer／fake-ip の記事と切り分けます。

具体的なサインとしては、特定国コードの判定が更新前後でブレる、ルールプロバイダが参照するタグと Geo判定の整合が取れない、ログに「データベースを開けない」「形式が想定外」に近い文言が出る、などが挙げられます。GeoIP データベース パスを明示的にYAML一行で固定していない場合でも、実体は必ずどこかのディレクトリに存在するはずなので、プロセスのカレントディレクトリとクライアントのドキュメント記載の既定パスを突き合わせるのが確実です。

著作権とライセンス：MaxMind 系やサードパーティ製の商用データを社内配布する場合は、各ベンダーの利用条件に従ってください。コミュニティビルドのミラーを使う場合も、配布元のメンテナンス状況と整合性検証の方針を決めておくと長期運用で事故が減ります。

ルール設計との接続：パスを直しても順序が狂っていれば意味がない

本稿の作業でデータは新しくなっても、rules: の上からの評価順が悪いと期待したGEOIP行に到達する前に広い RULE-SET に飲まれます。ルール分岐の総まとめで全体の骨格を押さえ、特殊例だけ既存のトラブルシュート記事へ橋渡ししてください。

TUN や DNS のハイジャックを併用している場合は、TUN 記事のチェックリストとあわせると、「庫は新しいのに見かけだけ古い」系の混乱が減ります。

よくある質問

Q. geox-url を全部ローカルの file:// にできますか。
A. 実装世代と実行環境のサンドボックスにより可否が分かれるため、まずログでフェッチ処理がどう解釈されたかを確認するのが安全です。運用上は「ミラーHTTPサーバーを立てる」「完全オフラインなら自動更新を切って実体だけ置換する」のほうが再現しやすいケースも多くあります。

Q. ASN データも同時に更新すべきですか。
A. ルールで GEOSITE や単純な GEOIP だけを使っている限り優先度は下がりますが、BGPまわりの高度なセットを読み込んでいるなら asn の行もセットで揃えるとブレません。

オープンソースと資料

Mihomo とコミュニティの公開テンプレは、ソースとウィキから追跡できます。日々のクライアント入手と説明が揃った一覧はサイトのダウンロード一覧から辿るのが現実的です。

ルールセットの自動更新とは別問題として、本作業は基礎地理データのアセット運用に位置づけられます。mihomo のルール関連データ更新と口語でまとめるなら、(A) アプリケーション内の自動ジョブ、(B) 手でファイルを入れ替える、(C) 社内パッケージで配る、の三本を混ぜずにログで証跡を残してください。

まとめ

GeoSite／GeoIP（mmdb または dat） は、YAMLの数行に見える裏側でサイズの大きいバイナリ資産であり、パス錯覚や自動更新の上書きに弱いレイヤです。geodata-mode、geox-url、geo-auto-update を読み、「どのファイル種別が今の自分の構成で主役か」を言語化してから置換し、ログでロード結果を確認すれば、「ルールYAMLは正しいのに世界が変わらない」迷子から抜け出しやすくなります。

取り換えサイトやコミュニティテンプレだけに頼ると、取得失敗時の切り分けやミラー整合の説明がバラバラになり、再現手順を文章化しづらい弱点があります。ClashSource 側ではビルドの取り違えを減らす導線と、画面付きクライアントとコアの関係を踏まえた説明を重ねており、トラフィックごとの制御を長期運用で安定させたい用途では扱いやすさが増します。セットアップ済みのアプリ一式は無料ダウンロードから揃えられますので、離線データだけ先に自分の運用規律に載せ、そのうえでルール並びを読み直してください。