geoip.dat・geosite.datの更新方法｜ルーティングルールの入手先と設定例

1. GeoIPとGeoSiteの照合対象

geosite.datにはタグ別のドメインルールが、geoip.datにはタグ別のIPアドレス範囲が保存されています。どちらもコアが読み込むバイナリデータファイルであり、ノード一覧やDNSサーバーではありません。ファイルを更新すると各セットの内容は変わりますが、ルールの出力先が自動で変わるわけではありません。

接続時に、ドメイン名がコアに渡される場合もあれば、接続先IPだけが渡される場合もあります。ドメインルールの照合にはコアがドメイン名を取得している必要があります。IPルールには接続先アドレスが必要で、ルーティング時にドメイン名を解決する設定が使われる場合もあります。ブラウザーでサイトを開けても、その接続でドメインセットとIPセットの両方が照合されたとは限りません。

たとえば、LANの管理用アドレス 192.168.1.1 への接続は、アドレス範囲を直接使って判定できます。一方、ドメインにアクセスした場合、geosite:cnに含まれていても、名前解決の結果が海外のCDNになることがあります。2種類のデータベースが表す属性は異なるため、相互に置き換えることはできません。

2. ルールファイルの入手先とタグの互換性

主なデータソースには、V2Flyのdomain-list-communityドメインセット、geoipデータプロジェクト、Loyalsoldierなどが提供するルールデータがあります。元のプロジェクトがテキスト形式のリストを公開し、コアが実際に読み込む.datファイルはビルド成果物として配布される場合もあります。ウェブページや元のドメイン一覧をgeosite.datに改名して使わないでください。

ファイル名が同じでも、タグの内容が完全に一致するとは限りません。cnは多くのデータソースにありますが、サービス別分類、広告分類、属性付きセットは一部のソースにしか含まれない場合があります。存在しないタグを設定で参照すると、該当ルールが機能しないだけでなく、コアが設定を読み込めなくなることもあります。

• まず形式を確認：この記事のgeosite:、geoip:とJSONの例は、Xray／V2Flyのルーティング形式を対象としています。他のルール形式にそのまま適用しないでください。
• 次にタグを確認：データソースが公開している分類一覧を確認し、名前だけでタグの存在を判断しないでください。
• 復元用のバックアップを用意：更新前に既存の2ファイルとルーティング設定をバックアップします。データソースを切り替える場合は、ファイルとルールを一組として確認してください。

3. v2rayNでGeoファイルを更新する手順

デスクトップ版では、現在の設定でXrayとV2Flyのどちらのコアを使っているか確認してから、該当するデータファイルを扱います。以下では「Geoファイルを更新」メニューがあるv2rayNの画面を例にします。バージョンや配布形態によってメニューの場所が異なることがあります。画面上の表記が違うだけで、ファイルが破損しているとは限りません。

1. ルーティングをバックアップ

   「設定」→「ルーティング設定」を開き、現在有効なルーティング構成とカスタムルールを控えます。Geoファイルを手動管理している場合は、元のファイルもバックアップ用フォルダーにコピーしてください。

2. データを更新

   メイン画面で「更新を確認」→「Geoファイルを更新」を選択します。処理が完了したら、geoip.datとgeosite.datそれぞれの状態を確認してください。ノードのサブスクリプション更新通知を、ルールデータの更新結果と混同しないようにしましょう。

3. ログを確認

   メイン画面のログまたはメッセージ欄を確認します。ダウンロードに失敗した場合は、ネットワークと取得元のURLを確認してください。タグを読み込めないと表示された場合は、参照名とデータソースを確認し、ルーティング設定を丸ごと削除しないでください。

4. 再読み込み

   クライアントから現在の接続を停止して再起動し、コアにデータを読み込み直させます。更新時にクライアントが再起動した場合も、起動ログにGeoファイルの読み込みエラーがないことを確認してください。

5. ルールを再テスト

   ノード、プロキシモード、DNS設定はそのままにし、データファイルだけを更新して同じ接続先をテストします。そうすることで、データ更新の効果と他の設定変更を切り分けられます。

v2rayNGとv2flyNGでは、サイドメニューの「ルーティング設定」を開き、現在のルールと利用可能なデータ更新方法を確認します。Android版はバージョンによってメニュー構成が異なります。Geo専用の更新項目がない場合は、そのバージョンの説明に従ってファイルのインポートまたはリソース更新機能を使い、デスクトップ版のフォルダー構成をそのまま当てはめないでください。サブスクリプションの更新で主に更新されるのはノード情報です。Geoデータが更新されたかどうかは判断できません。

4. geosite:cn・geoip:privateのルール設定例

以下はXray／V2Flyのroutingオブジェクトの例です。まずプライベートアドレスを直結にし、次にドメインセットを判定し、最後に中国のIPセットを補助的に使います。タグ名はインストール済みのデータファイルに依存します。ルールは上から順に評価され、最初に一致したルールの出力先が使われます。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

通常、同じルール内の異なる条件はすべて満たす必要があります。同じ配列に複数の候補を指定した場合は、そのうちいずれかに一致します。「ドメインがcnに属する、またはIPがcnに属する場合に直結」したいときは、例のようにルールを2つに分けます。1つのルールに両方の項目を入れても、「または」の条件にはなりません。

5. domainStrategyとDNSがルーティングに与える影響

routing.domainStrategyは、ルーティング判定でドメイン名をどのように名前解決するかを指定します。クライアント全体のDNS設定とは別のものです。同名または似た設定を出力先の設定と混同しないようにしてください。ルーティング段階では出力先を決め、出力段階では接続方法を決めます。

• AsIs：ルーティング段階で、IPルールのためにドメイン名を積極的に名前解決しません。接続先IPを取得済みのリクエストはIPルールに一致しますが、すべてのドメインがGeoIP判定されるとは限りません。
• IPIfNonMatch：ドメインがどのルールにも一致しなかった場合、IPアドレスを解決して判定を続けます。先行ルールでドメインが一致した場合、通常はそのルーティング判定のために名前解決する必要はありません。
• IPOnDemand：IP判定が必要なルールに到達すると、名前解決を行います。IPルールを先に置くと、ルーティング段階でドメイン名をDNS検索する機会が増えることがあります。

このため、例ではIPIfNonMatchを使っています。まずドメインセットを判定し、一致しなかった接続先についてIP分類を試します。ただし、DNS検索がどの経路を通るかは、DNSサーバー、検索ルール、接続設定にも左右されます。2つのデータファイルを更新しただけでは、DNSの汚染やタイムアウトは解消できません。

6. 手動での置き換え、動作確認、よくあるエラー

自動更新に失敗した場合は、同じメンテナンス元がビルドした2つのファイルを手動で入手できます。置き換える前にコアを停止し、実際にコアが読み込むリソースフォルダーを特定して、正確なファイル名で保存してから再起動してください。デスクトップのインストール版、ポータブル版、Androidアプリではリソースの場所が異なり、すべてに共通するパスはありません。

1. 読み込み場所を確認：クライアントのフォルダー説明、リソース設定、ログを基準にします。プログラムのフォルダーに同名ファイルがあるだけで、実行中のコアがそのファイルを読み込んでいると判断しないでください。
2. ダウンロードしたファイルを確認：ファイルが空でなく、ログインページ、エラーページ、圧縮ファイルでもないことを確認します。拡張子が非表示の場合は、geosite.dat.datとして保存されないよう注意してください。
3. 起動できることを確認：再起動後、ファイルが見つからない、データを解析できない、セットのタグが見つからないといったエラーがないか確認します。起動に失敗した場合は、変更を重ねる前にバックアップから復元してください。
4. 実際のルーティングを確認：アプリがクライアントのプロキシを使用していることを確認したうえで、LAN上の接続先、直結する想定の接続先、プロキシを使う想定の接続先にそれぞれアクセスします。利用可能なアクセスログで出力タグを確認してください。