本稿でできるようになること
ゴールは、(1) GEOSITE 行で「コミュニティがまとめたドメイン集合」（例：google、netflix、cn など、利用中の geosite.dat に依存）へ一括でポリシーを当て、(2) GEOIP 行で「接続先 IP の登録国」に基づき DIRECT や任意の PROXY グループへ振り分け、(3) そのときに必要な geodata（geoip.dat / geosite.dat） の更新と設定キーを把握し、(4) ルール配列の上から順評価と no-resolve の意味を踏まえて意図しない迂回やループを避けることです。GUI から Rule Provider を足す運用でも、最終的には同じ論理が rules: に展開されます。ACL4SSR と Loyalsoldier の比較記事 は「どのリモート集合を購読するか」の話であり、本稿はその中で GEOIP／GEOSITE 行がどう効くかの文法・順序・データ依存にフォーカスします。
PROCESS-NAME／Sniffer との棲み分け（重複回避）
PROCESS-NAME は「同じドメインを複数アプリが共有しているのに、アプリ単位で出口を変えたい」ときのレイヤです。Sniffer は「TLS・QUIC などで内核がホスト名を取り損ね、DOMAIN 系ルールに届かない」ときの補助です。一方 GEOSITE は「すでに（または Sniffer 後に）ホスト名がルール評価に乗ったとき」に、巨大なドメインリストをカテゴリ名一つで参照するための仕組みです。GEOIP は「最終的に接続が張られる IP」に対し、国コードの照合を行います。したがって、CDN や任意外国アンカーにより「見かけの国」と体感がズレることがあり、ドメイン優先の例外を上に置く設計が安定しやすいです。
前提：geodata とカテゴリ名は「ファイルの中身」に従う
GEOSITE・GEOIP は、内核が読み込んだ geosite.dat / geoip.dat（または設定で指定したパス・自動更新 URL）に含まれるエントリに依存します。カテゴリ名はコミュニティごとに微妙に異なるため、「ネットの古い記事のカテゴリ名」をそのまま写すとヒットゼロや期待と違う集合になりがちです。利用中の Mihomo / Clash Meta のバージョンのドキュメントと、実際にバンドルされているデータの説明を正としてください。クライアントが geodata の自動取得をサポートしている場合は、初回起動後にファイルが置かれたかログで確認します。手動配置する場合は、権限・パス・読み取りエラーがないかを疑います。
整理：ルールが「効かない」とき、まず ルール順で上の行に吸われていないか、次に ホスト名が評価に乗っているか（HTTPS なら Sniffer 要否）、最後に geodata が古い／別系統のファイル になっていないか、の三段で切り分けると早いです。
GEOSITE 行の書き方（スケッチ）
典型的には rules 配列に GEOSITE,<カテゴリ>,<ポリシー名> を並べます。ポリシー名は proxy-groups の name: と完全一致させます。細かい修飾子（サブルールや追加フラグ）の有無はバージョン差があるため、自前のリリースノートで確認してください。運用上は、購読ルールの巨大な RULE-SET の手前か後ろかにローカル例外を置くかで挙動が変わります。国内ドメイン集合を DIRECT に寄せ、残りを広域プロキシへ、というパターンがよく使われます。
# Sketch — category names must exist in your geosite.dat
rules:
- GEOSITE,cn,DIRECT
- GEOSITE,google,PROXY_GROUP
- GEOSITE,netflix,PROXY_GROUP
- MATCH,PROXY_GROUP
GEOIP 行の書き方と no-resolve
GEOIP,<国コード>,<ポリシー>[,no-resolve] の形が一般的です。国コードは ISO 3166-1 alpha-2（例：CN、JP、US）を想定します。no-resolve を付けるかどうかは「このルール評価で内核に DNS 問い合わせを走らせたくない」という文脈で使われ、設定全体の DNS モードや他ルールとの組み合わせで意味が変わります。誤解しやすい点は、GEOIP は接続先 IP を見るため、FakeIP や早期解決の設計と噛み合わないと「国判定が変」に見えることです。その場合は DNS ガイド 側でモードとフィルタを先に整えます。
# Sketch — verify no-resolve semantics in your Mihomo version
rules:
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- GEOIP,JP,DIRECT,no-resolve
- MATCH,PROXY_GROUP
ルール順：DOMAIN 例外 → GEOSITE → GEOIP の典型
Clash 系は rules を上から評価し最初の一致で停止します。したがって、(A) 社内ホストや決済ドメインなど細かい DOMAIN 例外を最上段、(B) 次に GEOSITE でサービス単位の束ね、(C) その後に GEOIP で「残りの IP を国別に処理」、(D) 最後に MATCH、という積み上げが読みやすいです。逆に、広い GEOIP を先に置くと、後段の GEOSITE に到達しないため、意図したサービス別ルールが死にます。購読ルールが一括で先頭に挿入される GUI では、ローカル追記が下に押し出されることに注意し、マージ順序を確認してください。
Rule Provider と GEOSITE／GEOIP の関係
リモートの rule-provider は、ドメイン・IP リストを別ファイルとして取り込み、最終的に rules へ展開されます。一方 GEOSITE はgeosite.dat 内のカテゴリを指します。用途が似ていますが、更新単位とメンテナンス主体が異なります。コミュニティルールをそのまま購読しつつ、ローカルだけ GEOSITE,private,DIRECT のような定番カテゴリを足す、というハイブリッドもよくあります。どちらを選んでも、最終的な並びが同じ競合を起こさないかをダッシュボードのルールヒットで検証します。
典型トラブル：CDN・任意外国 IP・古い geodata
海外サービスでも、エッジ IP が自国または第三国に見えることがあり、GEOIP,JP,DIRECT のような行だけに頼ると意図と逆になります。そのときは GEOSITE や DOMAIN-SUFFIX でサービス名を先に拾う方が確実です。また、GEOIP は「ドメインが国内っぽい」のではなく「IP の登録国」ベースなので、体感とのギャップを説明できるようにしておくと運用が楽です。geodata を長期間更新していないと、新しい ASN 割当が反映されず判定ズレが増えます。自動更新を有効にするか、クライアントの「データ更新」機能を定期実行してください。
動作確認の手順
- Rule モードで、対象サイトへアクセスし接続ログでホスト名と実 IPを確認する。
GEOSITEを足したら、命中ルールがカテゴリ行か、それより上の別行かをダッシュボードで見る。GEOIPを足したら、同じ接続で国コードが想定どおりか、no-resolve有無で挙動が変わらないかを比較する。- HTTPS でホストが空なら、先に Sniffer 記事 の手順を満たす。
- DNS ループや FakeIP フィルタの不足は DNS ガイド で切り分ける。
コンプライアンスの注意
職場・学校・契約ネットワークではプロキシや迂回が禁止されている場合があります。許可された環境でのみ設定し、他人の回線やアカウントに無断で中継しないでください。
注意：本稿の YAML は説明用スケッチです。キーワードやフラグの正式一覧は、利用中の Mihomo リリースのドキュメントで必ず照合してください。
ドキュメントとクライアント入手
用語と GUI の対応は ドキュメント・チュートリアル も活用してください。インストーラの取り違えを防ぐには 公式ダウンロードページ を第一の入手元にすると安全です。ソースや Issue は GitHub が適していますが、配布物の主経路はサイト側に寄せる運用を推奨します。
まとめ
GEOIP と GEOSITE は、IP 国別とドメイン集合カテゴリという二つの軸で分流を宣言するためのルールタイプです。効かせるには geodata の実体、ルール順、DNS／Sniffer との整合がセットになります。PROCESS-NAME や Sniffer が担当するレイヤと混同せず、ログで「ホストが見えているか」「どの行に吸われたか」を確認しながら足し算していくのがもっとも再現性が高いです。
Clash 系はルールをテキストで差分管理しやすいため、カテゴリ名と順序を短い英語コメントで残すと、数か月後の自分が助かります。