geoip.dat・geosite.datの更新方法｜ルーティング用データベースの使い方

GeoIPとGeoSiteの違い：IPアドレスとドメインをそれぞれ判定

geoip.datには、国・地域や特定用途ごとに分類されたIPアドレス範囲が保存されています。geosite.datには、地域・サービス・用途別に整理されたドメインルールが保存されています。どちらもコアが読み込むバイナリデータファイルです。ノード一覧ではなく、テキストエディターで直接編集できるJSON設定ファイルでもありません。

geosite:cnは、現在のドメインデータベースにあるcnカテゴリを参照します。「.cn」で終わるすべてのドメインを意味するわけではありません。同様に、geoip:cnはデータベースに登録されたIPアドレス範囲の集合であり、サイトの言語やサービス提供者を判定するものではありません。日本語のサイトが海外CDNを利用することも、国際的なサービスの接続先が中国本土のIPアドレスになることもあります。

v2rayNはサブスクリプションの管理、設定の生成、コアの起動を行うデスクトップクライアントです。これらのルールを実際に読み込むのはコアです。この記事のDAT形式の記述は、対応するGeoデータの仕組みを使うXrayおよびV2Flyの設定を対象としています。Android版のv2rayNGはXray、v2flyNGはV2Flyを使用しますが、メニューやファイルの保存方法はデスクトップ版の手順をそのまま適用できません。

更新前に確認：サブスクリプション、ルーティングルール、Geoデータの違い

サブスクリプションを更新すると、主にサーバーアドレス、ポート、プロトコルのパラメーター、ノード一覧が更新されます。Geoファイルの更新では分類データが変わり、ルーティングルールの変更では各カテゴリの通信経路が決まります。これらは別々の操作です。サブスクリプションを更新してもgeosite.datが更新されるとは限らず、データベースを置き換えても直結ルールが自動で追加されるわけではありません。

同じgeosite.datを提供するデータメンテナンスプロジェクトでも、含まれるカテゴリは異なる場合があります。あるデータベースでcnを認識できても、ルーティングテンプレートが参照するほかのカテゴリが使えるとは限りません。配布元を変更するときは、「カテゴリが存在するか」と「ファイルをダウンロードできるか」を分けて確認しましょう。

v2rayNでGeoファイルを更新する5つの手順

ここでは、「更新を確認」メニューがあるデスクトップ版v2rayNを例に説明します。バージョンによってメニューの配置が異なる場合があります。画面に「Geoファイルを更新」がない場合は、現在のバージョンでリソース更新機能の場所を確認してください。「サブスクリプションを更新」を代わりに使うことはできません。操作前に現在使える設定を保存し、ノード、DNS、ルーティングを同時に変更しないようにしましょう。

1. 現在の設定を記録する

   現在のノード、使用中のコア、有効なルーティング設定を確認し、独自ルールを記録します。ローカルの待ち受けポートを確認する場合は、「設定」→「パラメーター設定」を開き、ローカル待ち受け関連の項目を確認してください。どの環境でも10808が使われているとは限りません。

2. リソースを更新する

   メイン画面で「更新を確認」→「Geoファイルを更新」を選択します。クライアントのメッセージを確認し、ダウンロードが完了したことを確かめてください。使用中のバージョンでリソースごとに更新状況が表示される場合は、GeoIPとGeoSiteの結果をそれぞれ確認します。

3. ダウンロードに失敗した場合

   タイムアウトが発生したら、まずシステム時刻、リソースURL、現在のノードの接続状態を確認します。更新処理がプロキシを経由するかどうかは、クライアントの実装と設定によって異なります。システムプロキシを有効にしても、すべての更新リクエストがプロキシを経由するとは限りません。

4. 設定を再読み込みする

   更新に成功したらコアを再起動します。画面上の操作がわからない場合は、クライアントを終了して再度起動してください。ファイルが保存されても、実行中のコアが読み直したとは限りません。起動ログにリソース読み込みエラーがないか確認しましょう。

5. ルーティング結果を検証する

   既存のルーティング設定を保ったまま、直結される想定のドメイン、プロキシ経由になる想定のドメイン、LAN内のアドレスをそれぞれテストします。Webページが開くかどうかだけでなく、接続ログに表示される経路ラベルも確認してください。

手動で置き換えた後は、読み取り権限とファイルの内容も確認します。ダウンロード時にエラーページが保存されると、ファイル名がgeoip.datのままでも、コアはデータベースとして解析できません。解析エラーが発生したら、まずバックアップから復元し、リソースを再取得してください。

ルールの書き方：geosite:cnとgeoip:privateの使い分け

以下は説明用のrouting設定例で、単独で起動できる完全な設定ではありません。outboundsにdirectというタグの直結用アウトバウンドがあり、デフォルトの経路はプロキシであることを前提としています。どのルールにも一致しない場合、XrayとV2Flyは通常、先頭のアウトバウンドを使用します。アウトバウンドの順序もあわせて確認してください。

{
  "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"
      }
    ]
  }
}

• 1つ目：geoip:privateは、データベース内のプライベートアドレスの集合に一致します。「すべてのイントラネットドメイン」を指す略称ではなく、特別用途のアドレスがどの配布元にも同じように収録されている保証もありません。
• 2つ目：geosite:cnはドメインの集合に一致します。この照合には、リクエストにドメイン名が含まれているか、適切に設定されたスニッフィング機能によって利用可能なドメイン名が提供される必要があります。
• 3つ目：geoip:cnは宛先IPアドレスで判定します。リクエストにIPアドレスが含まれていればそのまま判定できます。ドメイン名のリクエストを先に名前解決するかどうかは、domainStrategyの設定によります。
• アウトバウンドのタグ：directは単なるタグ名なので、実際のアウトバウンド設定と一致させる必要があります。存在しない名前をタグに指定しても、データベースを更新するだけでは設定を修正できません。

IPIfNonMatchは、ドメイン名が既存ルールに一致しなかった場合に、IPアドレスを解決して照合する設定です。ルールの末尾にTCP・UDPのすべてのリクエストに一致するフォールバックルールを追加すると、ドメインの照合段階ですでに一致し、想定していたIPアドレスによる追加照合に進まないことがあります。この設定を使いながら、すべてのリクエストでGeoIPが確認されると思い込まないようにしてください。

更新してもルーティングが想定どおりにならない場合：4段階で検証

「Webサイトが開く」ことからわかるのは、何らかの接続が確立したということだけです。通信が想定した経路を通った証明にはなりません。Geoデータを検証するときは、ノード、ルーティング設定、テスト対象を固定し、一度に変更する条件を1つに絞りましょう。次の4段階で順番に確認すると、データベースを何度も切り替えるより原因を見つけやすくなります。

1. ファイル：更新日時、実際のリソースパス、起動ログを確認します。ファイルがない、読み込めない、データを解析できない場合は、ルーティングを変更する前にリソースの読み込みを修正してください。
2. ルール：参照先のカテゴリが存在するか、有効なルーティング設定が正しいか、より前のルールが通信に一致していないかを確認します。ルールは上から順に照合され、最初に一致した結果が適用されます。
3. ドメイン：コアがドメイン名とIPアドレスのどちらを受け取っているかを確認します。ブラウザー側での名前解決、アプリによるIPアドレスへの直接接続、TUNによる処理方式の違いによって、照合に利用できる情報が変わることがあります。
4. 経路：接続ログに表示されるアウトバウンドのタグを確認します。現在のログレベルで照合情報が記録されない場合は、一時的にログ設定を変更してください。経路が正しいのに速度が遅い場合は、ノードや回線のトラブル対処に進みます。

ローカルのSOCKSインバウンドが実際に127.0.0.1:10808で待ち受けている場合は、次のコマンドで接続経路をテストできます。socks5hを指定すると、ドメイン名をプロキシ側に渡せるため、ドメインによる照合条件を維持できます。このコマンドで確認できるのはリクエスト経路であり、特定のGeoSiteカテゴリに一致したことを単独で証明するものではありません。

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/

ここでのポート番号は例です。クライアントで実際に待ち受けているポートに合わせてください。接続を拒否された場合は、まず待ち受けポートとコアの起動状態を確認します。リクエストに成功したら、該当時刻のログで経路を確認してください。LAN内の宛先をテストするときは、「ルールが直結を選択したこと」と「宛先サービスにアクセスできること」を区別しましょう。この2つは別の問題です。

よくある質問：カテゴリが見つからない、更新が反映されない、更新頻度

最後に、更新日時、使用した配布元、ルーティングテンプレートの変更有無、再起動後の動作を簡単に記録しておきましょう。Geoデータは分類を提供し、ルールは経路を選びます。DNSとインバウンドの設定は、照合に必要な情報を提供します。この仕組みを分けて考えることで、次に必要なのがファイルの更新、ルールの調整、それともアプリが本当にクライアントを経由しているかの確認なのか判断できます。